Subject: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

From: Lou Berger <[email-masked]>
Date: Mon, 18 Sep 2017 10:33:45 -0400

All,

This is start of a two week poll on making
draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
send email to the list indicating "yes/support" or "no/do not support".
If indicating no, please state your reservations with the document.  If
yes, please also feel free to provide comments you'd like to see
addressed once the document is a WG document.

The poll ends Oct 2.

Thanks,

Lou (and Kent)

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 19 Sep 2017 11:46:57 +0200

Hi,

I support the adoption but I propose two conceptual changes:

1. Introduce a new module name and namespace so that it is not necessary to
carry along the deprecated baggage. If readability is the primary concern, this
is IMO the way to go. Instead of "ietf-ip-2", I'd suggest something like "ietf-
ip-nmda".

2. Avoid obsoleting RFC 7277. I believe the old modules may continue to be used
in areas where NMDA is an overkill, such as open source home routers. NMDA
implementors should be aware of the new modules but there is no need to
eradicate the old data models.

#2 applies also to other modules for which the NMDA version is underway.

Lada

PS. The subject is wrong, it shoud be -rfc7277bis-
 
Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 19 Sep 2017 11:59:15 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> 1. Introduce a new module name and namespace so that it is not
> necessary to carry along the deprecated baggage. If readability is
> the primary concern, this is IMO the way to go. Instead of
> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
> 
> in areas where NMDA is an overkill, such as open source home
> routers.

Why wouldn't NMDA be appropriate in an open source home router?  Note
that the new model really just have a single tree instead of two
trees, so the data that needs to be instrumented is more or less the
same.

In fact, if we claim that the new architecture is not appropriate for
some devices I think we have failed, especially if the conclusion is
that we need to maintain two versions of all modules going forward.

/martin

> NMDA

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Sep 2017 13:40:26 +0200

I believe that starting a new model would cause a real pain since any
model augmentations now need to augment two differnet versions of the
IP model. (Actually any model references may cause extra work.)

I also believe that view that NMDA is for big gear but not for small
gear is not quite right. Differences between operational state and
config state exists in almost all systems I have seen. The /foo and
/foo-state approach came out of long discussions about how to model
interfaces (Lada should recall this) and it was kind of clear even
back then that /foo and /foo-state was just a 'hack', given the
specifications we had to work with. NMDA simplifies models and we
would be failing badly if we now start maintaining multiple versions
of models.

/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: Ladislav Lhotka <[email-masked]>
Date: Tue, 19 Sep 2017 15:37:53 +0200

> trees, so the data that needs to be instrumented is more or less the

It is quite likely that some parts of the data models will be
implemented only as configuration but not state data. In the "old style"
modules it is easy to add a deviation for the node(s) under -state but
in NMDA style this is not possible because we only have one node.

There are subtle differences in the schemas for configuration and state
data that the NMDA concept doesn't address. If you want another example,
ietf-routing-2 has the "router-id" leaf that is conditional via the
"router-id" feature. If this feature is not supported, router-id cannot
be explicitly configured (it is assigned by the system) but in state data
"router-id" needs IMO be present in any case. But the if-feature
isn't able to differentiate between configuration and state data if
there is only one node for both.

> that we need to maintain two versions of all modules going forward.

I am not asking for this but, on the other hand, if NMDA versions used a new
module name and namespace (my item #1, which is what ietf-routing-2
does), then I don't see any pressing need for obsoleting the old style
modules.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Tue, 19 Sep 2017 14:49:09 +0100

Hi Lada,

> in NMDA style this is not possible because we only have one node.
The new YANG library allows different sets of modules to be available 
for <conventional> datastores vs <operational>.   The operational 
datastore can also have different features supported and different 
deviations vs the conventional datastores.

So, the device can make the same deviations to remove the state leaves 
from <operational>.  Or if they don't want to support the module in 
operational at all then a device could just list it as being supported 
in the conventional datastores and not <operational>.

> there is only one node for both.
The new YANG library also supports this:

The "router-id" feature would be disabled for the conventional 
datastores, but enabled for <operational>.

> does), then I don't see any pressing need for obsoleting the old style
I think that creating a "-2" versions of these models at this time might 
be a mistake.  I actually think that the "deprecate state leaves" -> 
"obsolete state leaves" -> "delete state leaves" path is a better choice.

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 19 Sep 2017 16:07:25 +0200

> deviations vs the conventional datastores.

OK, I missed the 7895bis draft, sorry. Then there could be differences in
mandatory/optional (e.g. a node is optional in configuration but mandatory in
state data) or the data type of a leaf can differ. How can these be handled?

Lada

---

From: Robert Wilton <[email-masked]>
Date: Tue, 19 Sep 2017 15:25:57 +0100

> state data) or the data type of a leaf can differ. How can these be handled?
If the data type of the leaf can differ, then normally this should be 
modeled as two separate leaves.  Do you have a concrete example of this?

If some data is mandatory in config, but not necessarily mandatory in 
<operational> then normally it can be marked as mandatory true, since 
optional is allowed to violate this constraint if necessary, but 
implementations would generally be expected to conform to the constraint 
if possible.

For the reverse case, we can't express that.  I think that you would 
have to leave out the "mandatory: true" constraint.  Again, can you 
provide a concrete example of this please?  That makes it a bit easier 
to reason about.

Thanks,
Rob

---

From: "t.petch" <[email-masked]>
Date: Wed, 20 Sep 2017 11:18:44 +0100

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
Sent: Tuesday, September 19, 2017 2:37 PM

> >> 2. Avoid obsoleting RFC 7277. I believe the old modules may
continue
> >> to be used

So add a second node!  I think that the idea that NMDA eliminates all
duplication of config and state is a myth; there will still be
duplication where the life cycle of the data diverges, ie it is not
really duplication! I think too that the twin trees approach, while
clumsy, was easy to create; the NMDA approach is more subtle, more
complex, easier to get wrong.

I recall that in the initial stages of discussion of this issue there
was a proposal for an object to have potentially eight different
characteristics so what NMDA gives us at present is limited and will not
solve all the issues of needing more than one node.

Tom Petch

---

From: Robert Wilton <[email-masked]>
Date: Wed, 20 Sep 2017 12:04:54 +0100

On 20/09/2017 11:18, t.petch wrote:
> clumsy, was easy to create;
Easy to create, but just as easy to get wrong.  Alas, with the twin 
trees approach, the config and state trees can (and do) diverge. 
Different WGs within IETF were already starting to model the state 
information with different tree structures.  Some WG models includes the 
applied config value, others didn't.  We seemed to be loosing 
consistency between the model.  My opinion is that the end outcome of 
this would effectively require all clients to write custom code to 
correlate equivalent information between the config and its related 
state, which doesn't seem great.

>   the NMDA approach is more subtle, more
Yes, I agree the NMDA approach is a bit more subtle. And there are 
definitely some concepts that probably should be modeled slightly 
differently:

A case in point might be "interface MTU" that can be automatically 
assigned (the default behaviour) or statically configured.

(1) A pre-NMDA split config/state model might have:
- a config true interfaces/mtu leaf that is either "auto" or a specific 
value,
- a config false interfaces-state/mtu leaf holding the actual 
operational value,
- [potentially also a config false interfaces-state/cfgd-mtu leaf 
indicating the applied config value.]

(2) One way of modelling this in NMDA would be to split whether mtu was 
auto vs manually configured separately from the mtu value.  So this 
could be modeled as:
- one config true leaf that represents with MTU is automatic or manually 
configured.
--one config true leaf that represents the manually configured and 
operational MTU value.  Allow with an appropriate constraint so that 
both leaves are not configured.

(3) Alternatively, in both pre NMDA or post NMDA, the model could assume 
"automatic" as the implicit default MTU behaviour.  In this case you 
only need to have a single leaf in the NMDA model (or 2 leaves in the 
split model).
  - one config true leaf that represents the operational MTU of the 
interface, which may be configured if a specific value is to be enforced.

For MTU, it is the third approach that I prefer.

Another similar example is Ethernet auto-negotiation, where (2) looks 
like the best approach post NMDA with an explicit leaf to control 
whether the auto-negotiation protocol is enabled (rather than attempting 
to merge it with the speed, duplex, and flow-control leaves).  But in 
the end, (2) also has the added benefit that it actually more closely 
marries up to how the auto-negotiation protocol is defined, and what 
functionality is actually allowed.

I think that building up a set of these examples (probably on an FAQ), 
of how particular abstract concepts can be effectively modeled may make 
it a bit easier when folks are trying to figure out the best way of 
modeling something in the post NMDA world.

> solve all the issues of needing more than one node.
I think that I missed those early discussions.  Perhaps that was a good 
thing :-)

Thanks,
Rob

---

From: "t.petch" <[email-masked]>
Date: Wed, 20 Sep 2017 13:06:30 +0100

----- Original Message -----
From: "Robert Wilton" <[email-masked]>
Sent: Wednesday, September 20, 2017 12:04 PM

> >> be explicitly configured (it is assigned by the system) but in
state
> > data

Yes, although I would make it an RFC,  guidelines on how to use NMDA.

The examples you give above are spot on, and we have had many such over
the past few years.

Tom Petch

> >> I am not asking for this but, on the other hand, if NMDA versions
used
> > a new

<snip>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Sep 2017 10:38:07 +0100

On 20/09/2017 15:33, Ladislav Lhotka wrote:
> Robert Wilton <[email-masked]> writes:
>
> So, for example, duplex and duplex-state? And <operational> will
> have both as siblings?
Here I presume you are thinking that the configurable value for duplex 
is "full/half/auto", but the operational value is "full/half"?

The solution here is really to model auto-negotiation on/off as a 
separate leaf (which also more closely reflects the actual behaviour of 
the auto-negotiation protocol).  Then for duplex both the space for both 
the configured and operational leaves are the same, i.e. both taking 
"full/half", and hence only a single leaf is required to model both the 
optional configured value and the operational value.

A concrete example of the Ethernet interface YANG structured this way is @
https://github.com/8023YangDesignTeam/EthernetYang/blob/nmda/standard/ieee/802.3/draft/ieee802-ethernet-interface.yang

> This should be quite typical: a config leaf is optional and if it is not
> configured, the system sets it to some value (as in the case of
> router-id). But in state data it is mandatory so that the client can see
> what the system chose.
Yes, I agree that this scenario is very likely, but I think that the 
solution here is just to not mark the leaf as mandatory.

It is interesting to consider what "mandatory" exactly means in the 
<operational> datastore.  Given that the mandatory constraint may be 
violated in <operational>, then my interpretation is that it means that 
a correct implementation SHOULD always return a mandatory node (if it is 
in scope).  But a client has no way to force a device return this data 
(except perhaps shouting at the vendor :-), and so it seems that a 
robust client would need to be able to cope with the fact that the 
device is not behaving nicely and isn't returning the data regardless of 
any mandatory keyword specified in the schema.

To further expand on this, a device is required to ensure that 
configuration datastores are valid, and hence all mandatory constraints 
are enforced, or a config change would be rejected, but I don't think 
that many devices are going to validate operational. They will just 
return the current state of the system back to the client, and let the 
client deal with any unexpected inconsistencies.

Also, what about all the regular config false nodes in the schema that 
are not marked as mandatory?  Is a device always required to return 
those leaves (if they are in scope)?  If a device is never going to 
return those leaves then it should use a deviation to remove them, but 
is that actually required?

Is seems that possibly the most useful use of mandatory in the context 
of operational is for something like an IP address/prefix length 
pairing, i.e. to indicate that the data really doesn't make any sense 
unless both address and prefix are provided.

When the next version of YANG is specified, perhaps we should consider 
allowing an extra options to mandatory to that it only applies to the 
state datastores?  if so, we could add this to the YANG.Next issue tracker?

So, in conclusion, I think that the NMDA modelling advice for mandatory 
on config true nodes might be to only use it when the node is mandatory 
in configuration datastores.

If the WG isn't opposed, then I would suggested adding this to the NMDA FAQ.

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 20 Sep 2017 16:33:24 +0200

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Sep 2017 17:10:52 +0200

> optional configured value and the operational value.

Yes, this sounds reasonable. Here also the config value should then be optional
while the state value mandatory.

> solution here is just to not mark the leaf as mandatory.

But this makes the schema weaker, and implementors may think it needn't be
implemented.

> <operational> datastore.  Given that the mandatory constraint may be

Yes, the semantics in the context of NM protocols is different from that of
configuration datastores. But in the context of document (data tree) validation
it is the same: the instance has to be present for a data tree to be valid. 

> any mandatory keyword specified in the schema.

I don't really share this view, it is IMO not much different from the situation
when a vendor fails to implement a config node. Either way, the implementation
doesn't conform to the data model.

One of the benefits of a data model is that an application can offload
validation to an external tool, such as a generic YANG library, and then can
rely on data being valid so that the application's code needn't be cluttered
with all kinds of sanity checks.

I can imagine a tool collecting data from a number of devices that fails if a
mandatory state data are absent.  

> client deal with any unexpected inconsistencies.

I could likewise expect the server to be prepared to deal with unexpected
inconsistencies in config data. The data model is a contract, so it should be
binding for both parties.

> those leaves (if they are in scope)?  If a device is never going to 

In terms of YANG, no.

> state datastores?  if so, we could add this to the YANG.Next issue tracker?

I believe the fundamental problem is that YANG was designed basically as a
document-oriented schema language, and NMDA tries to make the same schema work
for multiple different data trees. I am concerned this means a lot of complexity
 and CLRs that will render the next version unusable.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Sep 2017 16:59:09 +0100

> while the state value mandatory.
I think that this would mean that lots of "config false" leaves should 
be marked mandatory.  But looking at the YANG models going through IETF 
standardization that doesn't seem to be the case.

Perhaps a very simple device doesn't have the capability to report 
duplexity because it is always full duplex, hence mandatory seems less 
useful.  Or a device might be able to report duplexicty but not at that 
instant in time (e.g. perhaps the optics module is missing)?  It seems 
more natural for operational to say that if you don't know something 
then don't return it.

So, I wouldn't support marking this field as being mandatory in 
<operational> regardless of model structure.

> But this makes the schema weaker, and implementors may think it needn't be
I think that implementations SHOULD implement everything in the schema 
and use deviations if they don't.

> it is the same: the instance has to be present for a data tree to be valid.
Yes, the NMDA architecture states that the <operational> tree may not be 
valid.  There are several reasons why <operational> might not be valid, 
a few that I can think of are:
(1) The system is constant changing, and the device isn't able to 
provide a consistent snapshot across the entire device (e.g. on a 
distribute platform the FIBs on the LC may lag behind the RIB on the RP).
(2) The system might be in the middle of a config change at the time 
that <operational> is read meaning that either the device would have to 
prevent <operational> from being read until the config change had 
completed, or alternatively accept that it may provide an inconsistent view.
(3) There may be bugs or errors in the implementation.  They may have 
been a failure to program the hardware that means the state between 
different parts of the system is not consistent.

> doesn't conform to the data model.
The difference is that a device can reject an invalid config.  A client 
cannot reject an inconsistent state tree.  Perhaps it could choose to 
ignore it, but I'm not sure that helps.  I think that the client 
probably just has to cope with what is there.

> with all kinds of sanity checks.
Yes, if there is data missing then I think that such a tool might need 
to prune the operational tree provided to the application code, or 
perhaps annotate the tree with additional metadata flags the 
inconsistencies.

> mandatory state data are absent.
I think that the tool needs a plan B.  E.g. perhaps if the interface is 
admin-down then it doesn't matter whether or not the duplex setting has 
been provided by the device.

> binding for both parties.
But the server is allowed to just reject the change with an error. It 
isn't possible to reject the response to a <get> request.

>> those leaves (if they are in scope)?  If a device is never going to
So, should a device deviate config false leaves that it will never return?

>   and CLRs that will render the next version unusable.
OK.

But I'm not convinced that this is really much of an issue in practice.  
I've looked at converting quite a few YANG models either from an OC like 
structure, or IETF split structure to a combined NMDA tree (* list 
below).  In most cases, the models between config and state have been 
very closely aligned such that the config and state nodes are trivially 
identical.  In the cases that they differ (e.g. boolean vs empty), or a 
slight structure change, they have been pretty straight forward to 
resolve.  When the operational structure really differs from the 
configured structure then this can be represented using addition config 
false nodes (when doing the conversion on the models below, I don't 
recall having to add any extra config false leaves).

* By a few YANG modules I mean IETF draft/standard YANG modules for: 
interfaces, ip, routing, vrrp, rip, bgp, network, network-topology, te, 
te-topology, mpls, mpls-ldp, mpls-static, rsvp, rsvp-te, te-device, 
sr-topology, te-mpls, te-path-computation, te-service, transport services.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Sep 2017 19:59:35 +0200

> mandatory state data are absent.  

This is not a very robust tool. There are other reasons why a leaf may
be absert, e.g., an access control rule. In general, there is no
requirement that state data is reported as consistent snapshots, so
robust tools will have to be somewhat tolerant anyway.

> binding for both parties.

The server is prepared; it fails the commit if configuration data is
unexpectedly inconsistent.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Sep 2017 14:01:46 +0200

> standardization that doesn't seem to be the case.

Many of them have defaults that effectively mean that the leaves have to
be implemented. Otherwise the guarantees provided by the data model are
really weaker - there is no way to tell whether a given server will send
a parameter or not.

> duplexity because it is always full duplex, hence mandatory seems less

Then we have features and/or deviations to account for this.

> more natural for operational to say that if you don't know something 

Of course, transient effects need to be considered, and perhaps
statistics are also a bit special. But, for example, if an NM
application isn't able to learn actual router-id, it may be stuck.

> and use deviations if they don't.

This is not what YANG says - the state data tree is valid without a parameter
that is optional.

> been provided by the device.

Of course, but this is business as usual. The problem I am talking about
is an interface that is up and running but the server fails to provide
important data.

> isn't possible to reject the response to a <get> request.

Either way, the NM application may fail, which defeats the purpose of
standardizing data models.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Sep 2017 11:57:45 +0200 (CEST)

> Robert Wilton píše v Čt 21. 09. 2017 v 10:38 +0100:

[...]

> But this makes the schema weaker, and implementors may think it needn't be

Whether the "mandatory" statement is present or not on a node has
nothing to do with what a device must implement.  "mandatory" does not
affect conformance.

As long as we don't have a more elaborate conformance mechanism, all
nodes in a module (modulo if-feature) must be implemented in order to
claim conformance to the module.  This said, there can be cases where
"implement" in reality translates to "never return", b/c the
conditions that would make the device instantiate the node are never
fulfilled.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Sep 2017 13:09:48 +0200

> claim conformance to the module.  This said, there can be cases where

Section 5.6 in RFC 7950 describes conformance but I think it neither states nor
implies what you are saying. Specifically (in 5.6.5):

   A server implements a module if it implements the module's data
   nodes, RPCs, actions, notifications, and deviations.

But what does "implements the module's data nodes" exactly mean? My
interpretation is that if a node is optional, then it may or may not be
implemented.

> conditions that would make the device instantiate the node are never

Right, if a node is optional (with no default) then it may not exist in the data
tree (hence is never returned), and the client isn't able to tell whether it is
internally implemented or not.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Sep 2017 13:19:59 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> But what does "implements the module's data nodes" exactly mean?

It means that the device must implement whatever the defintion of that
node says, either with formal statements or in the description
statement.

> My

Which text supports this interpretation?  7950 doesn't use the term
"optional node", so I don't know what that is.  The text about the
"mandatory" statement in 7.6.5 says:

   The "mandatory" statement [...] puts a constraint on valid data.

It does not say "... means that a server MUST implement this node".

> internally implemented or not.

Correct.

/martin