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

[Robert Wilton <[e-mail]>]

On 20/09/2017 11:18, t.petch wrote:
> ----- Original Message -----
> From: "Ladislav Lhotka" <[e-mail]>
> Sent: Tuesday, September 19, 2017 2:37 PM
>
>> Martin Bjorklund <[e-mail]> writes:
>>
>>> Ladislav Lhotka <[e-mail]> wrote:
>>>> 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.
>>> 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.
>> 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.
> 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;
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
> complex, easier to get wrong.
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.

>
> 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.
I think that I missed those early discussions.  Perhaps that was a good 
thing :-)

Thanks,
Rob

>
> Tom Petch
>
>
>
>
>
>
>
>
>>> 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.
>> 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
>>
>>>
>>> /martin
>>>
>>>
>>>
>>>
>>>
>>>
>>>> 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:
>>>>> 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)
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> --
>>>> Ladislav Lhotka
>>>> Head, CZ.NIC Labs
>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netmod
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod