Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Robert Wilton <[e-mail]>]

Hi Eric,


On 31/01/2018 16:53, Eric Voit (evoit) wrote:
>
> I have read and support these two drafts going forward.
>
> I do have one additional thought below on 
> draft-ietf-netmod-revised-datastores section 5.3 default handling 
> process.  See in-line...
>
> *From:*Robert Wilton -X, January 31, 2018 6:31 AM
>
> Hi Andy,
>
> On 31/01/2018 09:22, Andy Bierman wrote:
>
>     On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder
>     <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>         On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
>         > Hi,
>         >
>         > I have some questions about these drafts.
>         >
>         > 1) what if datastore set to "conventional"?
>         >     There are many places where a datastore-ref type is used.
>         >     However, "conventional" is valid for base "datastore",
>         even though
>         >     it is ambiguous as a datastore selector.
>
>         We can add explicit text that an identity that does not
>         resolve to a
>         datastore implemented by the server results in an invalid
>         value error.
>
>     OK
>
>         > 2) origin filter is limited to 1 source
>         >    This filtering seems rather limited.  A client must retrieve
>         > <with-origin> and check
>         >     all the values in use, then make repeated requests for
>         each source as a
>         > different
>         >     <origin-filter> leaf
>
>         If the client does <with-origin>, then it has all origin
>         information
>         and it can filter locally. That said, we could make
>         origin-filter a
>         leaf-list which is logically ORed so that one can retrieve
>         origin-filter=or:system or origin-filter=or:learned in one
>         request.
>
>     OK
>
>         > 3) with-defaults broken
>         >     The operational datastore does not support with-defaults.
>         >      Instead, the client must use origin-filter=or:default
>         or with-origin
>         >      and check all the origin attributes. Since a client
>         needs to use
>         >      with-defaults for other datastores, this special
>         handling of
>         > <operational>
>         >      seems unhelpful.
>
>         I think the with-defaults semantics for conventional configuration
>         datastores are much more complicated than necessary for the
>         operational state datastore. Note that that the operational state
>         datastore reports in-use values not really defaults:
>
>           <leaf or:origin='default'>foo</leaf>
>
>         This reports that the value 'foo' is in use and that it originates
>         from a default value. Note that this could also be
>
>           <leaf or:origin='intended'>foo</leaf>
>
>         in case the intended configuration datastore configured the value
>         'foo' (despite this value matching the default). The with-defaults
>         solution is pretty complex because it tries to handle how
>         different
>         systems deal with configuration defaults. The idea is to not carry
>         this complexity over to in-use values in the operational state
>         datastore.
>
>     Before NMDA, the client could decide if it wanted to retrieve
>     default nodes or not.
>
>     This client-choice has been removed from NMDA, which is a problem.
>
> We tried to reach a sensible compromise on the data returned from 
> operational (defined in section 5.3 of the NMDA architecture):
>  - it should return explicit values for everything that is affecting 
> the actual running state of the device (regardless of whether the 
> operational value matches a schema default value).
>  - it does not need to, and should not, return operational values for 
> stuff that isn't actually in use, i.e. don't return needless and 
> unwanted data.
>
> In particular, if no value is returned from a particular data node in 
> <operational> then, barring mgmt protocol errors, a client can assume 
> that any functionality associated with that data node is off (i.e. not 
> in use).
>
> Some examples to illustrate the behavior:
>
> (i) If a protocol, e.g. OSPF,  is not enabled/running then 
> <operational> does not need to return any data for it.  It would be 
> reasonable to return a flag to indicate that OSPF is not enabled/running.
>
> (ii) If you have some funky widget on an interface that defaults to 
> being off and isn't being used then <operational> don't need to return 
> any data for it.
>
> (iii) But, if you have some funky widget on an interface that defaults 
> to being on, then the server should return data for it.  If it is 
> actually enabled, then it would indicate that it is on and return any 
> associated values with its operational state, or if it is disabled 
> then it should explicitly report that it is off.
>
> (iv) I would regard that all applied configuration is "in use" by the 
> system, even if it matches the default value, and hence it should be 
> reported.
>
>
> This behavior for <operational> is obviously slightly different from 
> the existing with-default handling that is supported for configuration 
> datastores.  As I recall, there were a couple of reasons that we 
> decided to have a different behavior for <operational>:
> (a) to have consistent semantics for all servers, rather than 
> different servers supporting different with-defaults behaviors (which 
> makes life harder for clients because they must cope with all variants).
> (b) to remove any potential ambiguity if data isn't returned.  I.e. 
> with the existing with-defaults semantics it is not clear to me that 
> servers will always return an explicit value to indicate that a 
> particular widget is off if the schema defines that the default it 
> that is enabled. If the server doesn't support a given widget at all, 
> it is quite plausible that it will just return no data for it.  In 
> theory features/deviations should handle this, but those don't work so 
> well if different linecards have different capabilities.  Hence being 
> explicit about stuff that is in use seems more robust.
>
> <eric> These are good examples.  It would be great if section 5.3 
> could be tweaked to make clearer the relationship between running 
> datastore defaults and other operational datastore defaults for the 
> same tree.
>
I think that the boat has probably sailed on changing 5.3 in the NMDA 
architecture, unless it is done as an erratum.  I'm not sure that this 
is required.  I actually think that FAQs are a good place for these 
sorts of examples, and extra explanatory text.

> For example, let’s say I create a configured subscription, and the 
> default transport protocol is NETCONF.  NETCONF will be used for that 
> subscription even though the node might not be populated.  In this 
> case, the object would not appear in the running datastore, but MUST* 
> appear in the operational datastore with the default origin (as it is 
> in-use).
>
Yes, that is the intended interpretation, although I think that we say 
SHOULD rather than MUST, and give the implementation a bit of leeway in 
choosing what is "in use".

Also, the NMDA definition of the "default" origin is wider than the YANG 
default statement, or "with-defaults" definition.  The NMDA definition 
of the "default" origin is:

          "Denotes configuration that does not have an configured or
           learned value, but has a default value in use.  Covers both
           values defined in a 'default' statement, and values defined
           via an explanation in a 'description' statement.";


The aim of this text is to allow more complex defaults, such as a 
hierarchical default behavior that cannot be expressed using a simple 
"default" statement.

Thanks,
Rob


> This to me is the desired behavior as it doesn’t incorrectly add 
> information to the running datastore, but shows what is in-use within 
> operational.   I suspect other such relationships for other 
> operational tree defaults could be asserted, perhaps based on the origin.
>
> (* Maybe ‘MUST eventually’, as obviously there is a temporal 
> relationship between the two datastores.)
>
> Eric
>
> Thanks,
> Rob
>
>
>
>         /js
>
>     Andy
>
>         --
>         Juergen Schoenwaelder      Jacobs University Bremen gGmbH
>         Phone: [phone]      Campus Ring 1 | 28759 Bremen |
>         Germany
>         Fax:   [phone]      <https://www.jacobs-university.de/>
>
>
>
>
>     _______________________________________________
>
>     netmod mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/netmod
>