Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

From: Kent Watsen <[email-masked]>
Date: Tue, 2 Feb 2016 17:54:41 +0000

Hi All,

I didn’t receive the usual announcement CC-ed to the netmod list, so I’m replying to this one sent to the id-announce list instead.

Anyway, this morning I posted -01 of this draft and then shortly after -02 to fix some cleanup items I only noticed after -01 was posted  :ooops:

Either way, this update is an overhaul to the original draft posted last September.

Kent

On 2/2/16, 10:30 AM, "[email-masked]" <[email-masked]> wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>        Title           : Operational State Enhancements for YANG, NETCONF, and RESTCONF
>        Authors         : Kent Watsen
>                          Andy Bierman
>                          Martin Bjorklund
>                          Juergen Schoenwaelder
>	Filename        : draft-kwatsen-netmod-opstate-02.txt
>	Pages           : 27
>	Date            : 2016-02-02
>
>Abstract:
>   This document presents enhancements to YANG, NETCONF, and RESTCONF
>   satisfying the requirements set forth in Terminology and Requirements
>   for Enhanced Handling of Operational State.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-kwatsen-netmod-opstate/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-kwatsen-netmod-opstate-02
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>I-D-Announce mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/i-d-announce
>Internet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Robert Wilton <[email-masked]>
Date: Fri, 5 Feb 2016 17:22:03 +0000

Hi Kent, and other authors,

I've taken a quick look through this draft, and hence have a few 
comments/questions below.  Some of these comments are the same that I 
made in reference to the previous version of this draft.

1. Minor nit: I think that the key point of this solution is that it is 
introducing a new applied configuration datastore, but this draft 
doesn't seem to state that anywhere in the introduction or abstract.  
E.g. the first reference to the applied configuration datastore is in 
section 5.1.

2. Personally, for a datastore solution, I would prefer if the new 
datastore was for the intended configuration, and that the applied 
configuration was stored in the same datastore (running?) as all the 
rest of the operational state.

If the logical flows of system information is as follows:
  [candidate] -> intended cfg -> applied cfg -> derived state

Then it seems strange to bundle intended cfg & derived state together in 
one datastore, and to have applied-cfg separate (a bit like an unwanted 
step child).

3. For the related-state statement, I think that this statement would be 
better as related-config and expressed in the reverse direction.

To give a contrived example of problems with related-state based on the 
example in 4.1.1:

Say I defined a new module that augments the ex-interfaces module that 
provides some further operational state for an interface.  In my 
specific example it wants to report the actual L2 MTU/MRU values 
programmed in the hardware.  (This could differ from a configured MTU to 
take into vary 802.1Q VLAN tag overheads or perhaps other slop).

  module ex-controller {
      namespace "http://example.com/controller";
      prefix ctrlr;

      import ex-interface {
        prefix ex-if;
      }

      import ietf-yang-related-state {
        prefix yrs;
      }

      // Standard module definition.
      augment "/ex-if:interfaces/ex-if:interface-state" {
        when "if:type = 'ianaift:ethernetCsmacd'";

        leaf hardware-mru {
          type { uint16; }
          description "Actual MRU programmed in hardware";
        }
        leaf hardware-mtu {
          type { uint16; }
          description "Actual MTU programmed in hardware";
        }
      }

      // Separate augmentation required for each related-state
      // statement.
      augment "/ex-if:interfaces/ex-if:interface/ex-if:mtu" {
        when "if:type = 'ianaift:ethernetCsmacd'";
        yrs:related-state
"/interfaces-state/interface/name=current()/name/hardware-mtu";
      }

      // Separate augmentation required for each related-state
      // statement.
      augment "/ex-if:interfaces/ex-if:interface/ex-if:mtu" {
        when "if:type = 'ianaift:ethernetCsmacd'";
        yrs:related-state
"/interfaces-state/interface/name=current()/name/hardware-mru";
      }
    }

Here you will see that I would need a separate augmentation statement to 
set up every related-state binding.  Further, YANG would need to be 
modified to even allow such an augmentation of a leaf.

If you reverse the sense of the binding to "related-config" then I think 
that these problems disappear.

4. For section 5.4, get-state operation, it might be useful to clarify 
that if neither of the applied/derived options are specified then the 
data that is returned covers both the applied configuration and derived 
state (i.e. the data that is returned spans two datastores).

5. Am I correct to presume that this draft doesn't provide any support 
to return intended config, applied config & derived state all in a 
single request?  I appreciate that this isn't included as a formal 
requirement - but part of me wonders whether this might have been an 
oversight in the requirements.

6. I can understand the decision of get-diff to reuse edit-config or 
YANG patch,  but I'm not sure that this makes it particularly easy for 
clients to then process that data.  I might be wrong, but I suspect that 
a solution that returns the values of the intended and applied config 
nodes in an easier to relate way may be preferable (perhaps something 
along the lines of the encoding proposed in 
draft-wilton-netmod-opstate-yang).

Thanks,
Rob

On 02/02/2016 17:54, Kent Watsen wrote:
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Feb 2016 18:34:32 +0100

> rest of the operational state.

The running datastore is a configuration datastore, it does not hold
operational state.

> one datastore, and to have applied-cfg separate (a bit like an unwanted 

This is not what is being proposed. We always had

[candidate] -> [running] -> operational state

(and I mark configuration data stores in []). Both [candidate] and
[running] have the same configuration data model. Now we are asked
to expose that [running] may not be applied synchronously and hence

[candidate] -> [running] -> [applied] -> derived state

seems to make sense.

> oversight in the requirements.

Can be defines easily as another RPC. That said, I heard that some big
vendors even refuse to implement today's get operation that returns
the combination of [running] and operational state.
 
> draft-wilton-netmod-opstate-yang).

A diff is a way to make delta's efficient.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Robert Wilton <[email-masked]>
Date: Mon, 8 Feb 2016 13:30:02 +0000

Hi,

> The running datastore is a configuration datastore, it does not hold
OK.  Thanks for the clarification.  I hadn't realised that the 
definition of datastores only applies to configuration and not to state!

So, am I right in saying that this draft is effectively reclassifying 
that definition somewhat - given that applied configuration is being 
defined as operational state (at least in the diagram in section 3. 
Conceptual model) and datastores don't store state data?

> the combination of [running] and operational state.
OK, but the key question is what does that returned data look like: Are 
the intended and applied config nodes going to be co-located in the same 
structure or is the response going to be two separate trees and for it 
to be up to the client to merge them together?

> A diff is a way to make delta's efficient.
Yes, but often diffs include both the old and the new values to make it 
easier to see what the change is (or certainly they do whenever I review 
code diffs).

I don't think that the YANG patch/edit-config encoding is significantly 
more efficient that the encoding that I suggested, so I don't think that 
efficiency of encoding is a strong argument here.

The strongest argument for edit-config and YANG patch is that it is 
reusing an existing solution rather than inventing a new way of doing 
this.  But I still think that my observation that this doesn't make it 
particularly easy for clients is valid, and other ways of encoding the 
data could make it easier and more useful.

Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Feb 2016 15:38:19 +0100 (CET)

> definition of datastores only applies to configuration and not to

No, this is not correct.  RFC 6241 defines both "datastore" and
"configuration datastore".  However, "running" is a "configuration
datastore".

/martin

> defined as operational state (at least in the diagram in section
> 3. Conceptual model) and datastores don't store state data?
> 
> 
> OK, but the key question is what does that returned data look like:
> Are the intended and applied config nodes going to be co-located in
> the same structure or is the response going to be two separate trees
> and for it to be up to the client to merge them together?
> 
> >   
> Yes, but often diffs include both the old and the new values to make
> it easier to see what the change is (or certainly they do whenever I
> review code diffs).
> 
> I don't think that the YANG patch/edit-config encoding is
> significantly more efficient that the encoding that I suggested, so I
> don't think that efficiency of encoding is a strong argument here.
>

---

From: Gert Grammel <[email-masked]>
Date: Mon, 8 Feb 2016 14:53:57 +0000

On 2016-05-02 18:34, "netmod on behalf of Juergen Schoenwaelder"
<[email-masked] on behalf of

>[candidate] -> [running] -> [applied] -> derived state

The mapping of what is called intended-config onto data stores would
deserve more detailed discussion. It seems the authors of this draft had
in mind to associate intended-cfg with the [running] datastore. With that
mapping, a failure in applying [running] to [applied] will update the
[running] datastore to reflect which part is effectively applied. So a
fair representation of that case would be:
[candidate] -> [running] <--> [applied] -> derived state

In the context of intended configuration however that doesn¹t make sense
to me. A failure in applying intended configuration doesn¹t change the
intention and the delta between intended and applied-config is the key
value. A server that would "clean-up² intended-cfg in presence of a
failure to apply would look picture perfect instead of exposing the
problem clearly. Hence the sequence should more look like:
[candidate] -> [intended] ‹> [running==applied] -> derived state

Whatever we choose, I believe we need to spell out what¹s the data in a
failure case. It¹s probably a bit late to update the requirements draft,
but we can probably find a suitable place.

---

From: Robert Wilton <[email-masked]>
Date: Mon, 8 Feb 2016 15:43:12 +0000

Hi Martin,

> "configuration datastore".  However, "running" is a "configuration
OK.  RFC 6241 defines terminology for "datastore", but the body of the 
text only ever seems to ever use the term datastore in the context of a 
"configuration datastore".

Hence please can you clarify, does the operational state live in a non 
configuration datastore, and if so which one?  Otherwise, are there any 
other uses of non-configuration datastores by NETCONF?

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Feb 2016 17:31:23 +0100

> Conceptual model) and datastores don't store state data?

Not sure what 'that definition' refers to. This WG has had lenghty
discussions how we look at operational state has. Some of it is
briefly mentioned in RFC 6244 and there were quite a few presentations
at IETF meetings before 'the operators' started contributing ideas.
 
> efficiency of encoding is a strong argument here.

So if in my 1 million XML elements one has not been applied, how do I
find out efficiently in your encoding?

> data could make it easier and more useful.

We are on a very slippery slope here - what may be easy for one client
may not be easy for another client. Difficult for taking good
engineering decisions.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Feb 2016 17:38:21 +0100

> >[candidate] -> [running] -> [applied] -> derived state

Why would that be the case? If I configure an interface that is not
currently present today in running this is just find and running is
not expected to change arbitrarily.
 
> [candidate] -> [running] <--> [applied] -> derived state

What is 'this draft'? I thought the whole point of having an applied
config is to be able to see the difference between intended (oops
running) and applied. I am confused now.
 
> but we can probably find a suitable place.

There is apparently much less agreement on what the problem is, what
the terms mean, and how they related to existing technology than I
thought.

/js

---

From: Robert Wilton <[email-masked]>
Date: Mon, 8 Feb 2016 16:59:42 +0000

> at IETF meetings before 'the operators' started contributing ideas.
I was referring to the definition of Configuration Datastore in RFC-6241.

I had mistakenly thought that the running datastore contained both the 
running configuration and operational state.

You corrected me that the running datastore only contains config, 
although it is still slightly unclear to me whether the operational 
state lives in a datastore or not.

> find out efficiently in your encoding?
By using 'diff-cfg-only' option of the <with-config-state> parameter, 
you would get 3 or 4 leaves per mismatching node: (intended value, 
applied value, status, and optionally error reason).  Only nodes with 
differences would be returned.

A more complete example is in 
https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02, "A.2.  
NETCONF get-config request using with-config-state with diff-cfg-only 
option", about page 16.

Yes, this data would be larger than the patch, but it also contains more 
information (i.e. reason why they differ, and error string).

The client is also able to process this data straight away.  With the 
patch, they may need to generate the before and after values to make it 
easier to process.

> may not be easy for another client. Difficult for taking good
Yes, but a diff that provides the old and new values can be used more 
flexibly then a diff that only provides the new values.  I.e. the client 
can always ignore the extra information if they don't need it.

Rob

---

From: Gert Grammel <[email-masked]>
Date: Mon, 8 Feb 2016 17:50:00 +0000

Hi Juergen,

I think the indentation in  our emails play havoc which is confusing me
too. The key point I am making is:

The mapping of what is called intended-config onto data stores would
deserve more detailed discussion. It seems the authors of
draft-kwatsen-netmod-opstate-02.txt had in mind to associate intended-cfg
with the [running] datastore. In my understanding, a failure in applying
[running] to [applied] will update the [running] datastore to reflect
which part is effectively applied. So a fair representation of that case
would be:
[candidate] -> [running] <--> [applied] -> derived state

In the context of intended-configuration however that doesn’t make sense
to me. A failure in applying intended configuration doesn¹t change the
intention and the delta between intended and applied-config is the key
value. A server that would "clean-up" intended-cfg in presence of a
failure to apply would look picture perfect instead of exposing the
problem clearly. Hence the sequence should more look like:
[candidate] -> [intended] ‹-> [running==applied] -> derived state

———

I am also wondring if we have the same understanding related to the
following statement:
	I thought the whole point of having an applied config is to be able to
see the difference between intended (oops running) and applied.

The current draft-kwatsen-netmod-opstate-02.txt says:
"Any rollback that may occur will restore both the intended and the
applied configurations to their previous states."

The challenge I have is the term “(oops running)” in the first sentence in
combination with the citation. I reckon that any difference between
intended-config and applied-config shall be visible whereby the
intended-config is provided by the client and never altered by the server.
Applied-config on the other hand represents the state of the server. If a
failure happens in the application phase, it shall be treated accordingly
(rollback-, stop-, continue-on-error). As a result the difference between
intended and applied configuration shall be maintained.
So does this square with the notion "intended=running" and “applied”
config?

- Gert

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Feb 2016 20:43:16 +0100 (CET)

Robert Wilton <[email-masked]> wrote:
> text only ever seems to ever use the term datastore in the context of
> a "configuration datastore".
> 
> configuration datastore, and if so which one?

Yes, but unfortunately it doesn't have a name, and the only way to get
it with current NETCONF is to do a <get>, which also returns the
running configuration.

> Otherwise, are there
> any other uses of non-configuration datastores by NETCONF?

No, not currently.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Feb 2016 13:42:47 +0100

> information (i.e. reason why they differ, and error string).

OK. Next question: How do I get the diff between <startup/> and
<running/>? How do I get the diff between <candidate/> and <running/>?
We can try to build generic primitives or we can choose to create many
point solutions.

> patch, they may need to generate the before and after values to make it 

I fail to get the message, what is easier to process for a client is
largely subjective or a function of the particular client environment
or what I want to do with the data.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Feb 2016 13:51:29 +0100

> [candidate] -> [running] <--> [applied] -> derived state

This is not how I understood that state of the discussions. I do not
think that the NETCONF <running/> configuration datastore changes in
existing implementations dynamically. Does it on Junos?

> applied configurations to their previous states."

This rollback requirement is in my view broken (I assume people will
figure this out when they try to implement solutions for it). Anyway,
NETCONF today commits <candidate/> to <running/> and I do not think we
should mess around with that.
 
> So does this square with the notion "intended=running" and “applied”

Yes (with the caveat that the rollback requirement text is kind of
broken).

/js

---

From: Robert Wilton <[email-masked]>
Date: Wed, 10 Feb 2016 13:51:54 +0000

> We can try to build generic primitives or we can choose to create many
I think that this is effectively the same question that I asked Martin, i.e.

"Can you please suggest an approach of how to return a single tree that 
contains the data from two separate datastores (where the leaf paths may 
overlap)?  I think that the approach would need to work both for get 
requests and also notification data. "

> or what I want to do with the data.
What is easier to read:
  - a diff that only gives you the new value and the context, or
  - a diff that gives you both the old and new values?

Here is a hypothetical C example:

1) A diff with just the new context:

***************
*** 3112,3118 ****
       caps_vft->caps_unbuilder_func = dot1q_unbuilder;
       caps_vft->caps_control_func   = dot1q_control;
!     caps_vft->caps_upgrade_func   = dot1q_upgrade;
!     caps_vft->caps_terminate_func = dot1q_terminate;

2) The same diff with both old and new context:

***************
*** 3112,3118 ****
       caps_vft->caps_unbuilder_func = dot1q_unbuilder;
       caps_vft->caps_control_func   = dot1q_control;
!     caps_vft->caps_upgrade_func   = dot1q_terminate;
!     caps_vft->caps_terminate_func = dot1q_upgrade;

--- 3115,3121 ----
       caps_vft->caps_unbuilder_func = dot1q_unbuilder;
       caps_vft->caps_control_func   = dot1q_control;
!     caps_vft->caps_upgrade_func   = dot1q_upgrade;
!     caps_vft->caps_terminate_func = dot1q_terminate;

In the latter case, it is easy to see what the change is.  In the former 
case you would need to understand what the code was previously to 
understand the change.
In the latter case, if you don't care what the old value was, then that 
is fine it can just be ignored.

So the point that I'm trying to make is that the YANG Patch format is 
broadly equivalent to the former example.  Yes, it strictly meets the 
requirement draft to return a comparison between the two datasets, but 
in a way that I perceive is not as easy or flexible for the client as if 
both the old and new values had been provided.

If there was a way that YANG patch (or equivalent) were able to return 
both old and new values (in the same tree) then I think that would be 
better.  I don't think that such as solution would be specific to the 
opstate requirements and may be useful more generally.

Rob

---

From: Kent Watsen <[email-masked]>
Date: Wed, 10 Feb 2016 15:46:38 +0000

>opstate requirements and may be useful more generally.

Already the <get-diff> RPC accepts an enumeration specifying the response format.  It seems that all that is needed is to define another enumeration for something like “yang-diff” that can do all you say.   We don’t have yang-diff today, but someone can write a draft to define it and then it can be added or used instead.  

Alternatively, the <get-diff> RPC could be moved into a diff-draft that defines both the RPC and the format together.  Something like this might make sense as <get-diff> is generally useful outside of this opstate application. 

Kent  // contributor

---

From: Robert Wilton <[email-masked]>
Date: Wed, 10 Feb 2016 17:31:18 +0000

> Alternatively, the <get-diff> RPC could be moved into a diff-draft that defines both the RPC and the format together.  Something like this might make sense as <get-diff> is generally useful outside…
Yes, OK.

I can easily see how a <get-diff> RPC message could provide two separate 
trees, i.e. one with the values before, and a separate tree with the 
values after, but I'm not sure that such a message format would really 
be any better than the current YANG patch format.

However, the bit that I'm stuck on is that I can't see how is it 
possible to provide the data in a single tree unless you end up with an 
encoding that is broadly similar to what I have suggested in my draft, 
and several folks have strong views against any such encoding.  AFAIK, 
no alternatives have been proposed.

Rob

---

From: Robert Wilton <[email-masked]>
Date: Wed, 10 Feb 2016 17:45:10 +0000

> existing implementations dynamically. Does it on Junos?
On Cisco's IOS XR, for a normal configuration commit (i.e. rollback on 
error semantics) then if applying the configuration for any config nodes 
fails then the whole config commit is undone.  I.e. the system ends in 
the same state as if the configuration commit never happened - standard 
transaction commit semantics.

> figure this out when they try to implement solutions for it).
This was meant to be consistent with the existing rollback-on-error 
semantics supported by NETCONF (specified in rfc6241).

As above, my understanding is that Cisco IOS XR already supports these 
semantics.

Please can you clarify how/why the requirement is broken?

Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Feb 2016 10:29:03 +0100

> transaction commit semantics.

This is how it should be.

> Please can you clarify how/why the requirement is broken?

We are discussing this text:

       D.  The configuration protocol MUST specify how configuration
           errors are handled.  Errors SHOULD be handled by semantics
           similar to NETCONF's error-options for the <edit-config>
           operation (stop-on-error, continue-on-error, rollback-on-
           error), as described in Section 7.2 in [RFC6241], but
           extended to incorporate both the intended and applied
           configurations.  Support for "rollback on error" semantics
           SHOULD be provided.

First, let me observe that it is underspecified what a 'configuration
error' is in the context of this requirement statement. Is the
configuration of an interface that is currently not present a
configuration error? If not, does it become a configuration error if a
line card is inserted to which the configuration can not be applied?
Note that NETCONF together with YANG provides a rather clear
definition what validation of a configuration datastore means. When we
talk about applied config and the difference between intended and
applied config, the notion of what is a configuration error is not
clear cut anymore.

Second, in order to rollback, there needs to be a configuration that
can be safely rolled back into. The only robust way I can imagine to
implement this rollback requirement is to use locks until the whole
new config has been applied, thereby turning an asynchronous system
into a synchronous system. Otherwise, I fail to see how I can ensure
that I have a configuration that can be safely rolled back into.

/js

---

From: Robert Wilton <[email-masked]>
Date: Thu, 11 Feb 2016 14:52:27 +0000

On 11/02/2016 09:29, Juergen Schoenwaelder wrote:
> configuration error?
My opinion is yes, this is an error and hence would cause configuration 
to fail and rollback if "rollback-on-error" semantics had been requested.

If the request had used continue-on-error semantics then I would expect 
that you would see this configuration in intended, but not applied.

>   If not, does it become a configuration error if a
As above, this question doesn't directly apply.

But a similar question might be: what would happen if the configuration 
had previously been accepted and then a linecard removed?  In this case 
the the affected interface configuration would stay in intended but be 
removed from applied by the system.

> applied config, the notion of what is a configuration error is not
Personally, I agree that having tighter semantics are a good thing here 
(and should be covered by the solution draft).

> that I have a configuration that can be safely rolled back into.
Locks are the simplest way of implementing this, but I agree that they 
defeat the point of async configuration updates.

I don't think that locking is the only way to solve this.  I would have 
thought that one of the optimistic transactional locking approaches 
could be used to process multiple requests concurrently.

Hence, I think that the decision as to whether or not to use a global 
lock should probably be specified during the client operation (if at 
all), and the solution draft shouldn't enforce always using a server 
side lock.  Instead it should specify the exact semantics that a client 
can expect when interacting with the server during configuration 
requests.  This is to allow for flexibility in server implementations - 
i.e. to trade off complexity for performance.

Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Feb 2016 09:19:28 +0100

> removed from applied by the system.

Looks like the semantics you describe are somewhat inconsistent. BTW,
I have been told that 'some operators' do provision configuration for
hardware not yet present. RFC 7223 has been designed to allow this to
happen. Anyway, this is an example. The point is that it is not clear
cut whether something that can't be immediately applied really is an
error.
 
> (and should be covered by the solution draft).

Then I note that the requirement is at least not well defined.

> could be used to process multiple requests concurrently.

As long as it is clear to which configuration to roll back to. Once
you process multiple requests concurrently, this is not at all clear,
at least not to me.

> i.e. to trade off complexity for performance.

If it is unclear from the specification what the result of a rollback
is, then I believe this serves little value. And see the previous
examples; what can be applied at time t in general depends on the
overall state of the system at time t. YANG does not allow config true
nodes to depend on config false nodes and the reason is that
configuration validity must not depend on the time varying operational
state of a device.

/js

---

From: Robert Wilton <[email-masked]>
Date: Fri, 12 Feb 2016 14:06:15 +0000

On 12/02/2016 08:19, Juergen Schoenwaelder wrote:
> Looks like the semantics you describe are somewhat inconsistent.
OK, they were not meant to be inconsistent at all:

- The intended configuration is what the operator wants, and can only be 
changed by the operator.
- The applied configuration is what state the system is in, and should 
be continuously kept up to date with the current system state.

- If a config change completes without any errors that means that for 
every node in the changeset, the applied config node matches the 
intended config node.
- This is why I would say that the cleanest semantics are that 
attempting to configure an interface that doesn't exist should be 
regarded as a config apply error.  (If the operator wants to push this 
config in then I think that they should be using the continue-on-error 
option - or perhaps something similar).

>   BTW,
Yes.  I'm not opposed to this on principal, but if a choice of semantics 
are supported then it should be down the operators request to choose the 
semantics.  Having rules that give flexibility in how a device is 
allowed to behave just makes them more difficult for the operator to manage.

> Then I note that the requirement is at least not well defined.
Perhaps, but we had already spent a long time discussing the 
requirements draft, hence personally I think that it is OK to 
specify/agree the precise semantics/behaviour in a solution draft.

> you process multiple requests concurrently, this is not at all clear,
Logically, the system must revert to a state where the failed 
configuration request was never applied.  I think this is the only 
guarantee that is being made to the client.

One way to achieve this would be rollback the configuration (intended 
and applied) back to exactly the point before that failed request (or 
any other request) was processed.

Any concurrent configuration requests that were previously in progress 
would then need to be re-applied one by one (in the same order).  Each 
of these could fail in a similar way.

It may be possible to optimize this behavior, but I'm not sure whether 
that would be particularly useful - the working assumption here is that 
in the mainline case you would expect that the vast majority of 
configuration updates shouldn't fail.

> is, then I believe this serves little value. And see the previous
The specification of the result after rollback does need to be specified 
and included in the solution draft.

> configuration validity must not depend on the time varying operational

Yes, I agree with that.

But I think that there is a clear separation between whether a 
configuration is semantically valid and whether it can be successfully 
applied:

Whether the configuration is semantically valid must only rely on the 
configuration.

But whether or not the configuration is able to be applied can and does 
depend on the operational state of the device (memory, what LCs are 
present, correct functioning of the code, etc).

Rob

---

From: Kent Watsen <[email-masked]>
Date: Fri, 12 Feb 2016 16:51:17 +0000

[As a contributor]

>option - or perhaps something similar).

I disagree.  JUNOS specifically allows for preconfiguration for hardware that does not exists yet.  It’s a well-regarded feature.  It is not an error, but may be reported as a warning.  This is why we defined leaf "apply-warning” in this draft (see subject line).  That said, I do agree that the applied configuration would not have the config for the missing hardware, as would be evident in a diff between it and the intended configuration.  

>allowed to behave just makes them more difficult for the operator to manage.

I think that this doesn’t scale.  By this token, servers should support everything the IETF defines.  But that’s not how it works, instead we have features and capabilities that enable devices to advertise what they support.  This ability is important when a brown-field device is moving to support NETCONF/RESTCONF but can’t break compatibility with its legacy APIs.

>specify/agree the precise semantics/behaviour in a solution draft.

Not just that, but it was the decision we made as a WG, and why the requirements say "The configuration protocol MUST specify how configuration errors are handled.” - right?

>configuration updates shouldn't fail.

Agreed, and that is why this draft (see subject) says:

  In order to implement the rollback behavior, for <edit-config> or
  <commit>, it is necessary for the server to maintain a global lock
  until the processing is complete.  That is, either a 'sync' request
  returns or an 'async' request's 'sync-complete' notification has been
  sent.  Any attempts to read or write either intended or applied
  configuration will be blocked until the request completes.

Perhaps “global lock” is overreaching, if the system supports partial-locks, then just the locks over the impacted config would be needed.  Are we mixing up supporting Asynchronous Configuration Operation with parallel processing?

>present, correct functioning of the code, etc).

FWIW, when working on solution #2, we originally defined a secondary error-option called “applied-error-option” that could control the behavior for the “apply” phase of processing a config request.  This became difficult to specify, so we backed off and decided to simply leverage the existing error-option parameter, by extending it to also cover the apply phase, with what we felt was an intuitive interpretation of the error-option values.

Kent