Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

["Acee Lindem (acee)" <[e-mail]>]

On 7/28/16, 10:42 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at
Cisco)" <[e-mail]> wrote:

>
>
>On 28/07/2016 15:20, Ladislav Lhotka wrote:
>>> On 28 Jul 2016, at 15:57, Acee Lindem (acee) <[e-mail]> wrote:
>>>
>>> Hi Lada,
>>>
>>> On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
>>> <[e-mail] on behalf of [e-mail]> wrote:
>>>
>>>> Robert Wilton <[e-mail]> writes:
>>>>
>>>>> On 26/07/2016 21:36, Kent Watsen wrote:
>>>>>> <Rob Wilton writes>
>>>>>>
>>>>>>
>>>>>> So my thinking is that if we can't merge "foo-state" into "foo" then
>>>>>> instead we should have consistent rules that explicitly state that
>>>>>>for
>>>>>> all IETF models "foo" and "foo-state" are separate trees with a
>>>>>> consistent naming convention and structure.  That should hopefully
>>>>>> allow tooling to programmatically relate the two separate trees
>>>>>> together.  It may give a path to allow "foo-state" to be merged into
>>>>>> "foo" in future, but once IETF has standardized 600+ models with
>>>>>> separate sub-trees, I cannot see that they would get merged back
>>>>>> together again.
>>>>>>
>>>>>> What other alternatives are available?  As a WG we need to tell the
>>>>>> other WGs how the IETF YANG models should be structured.
>>>>>>
>>>>>> In short, unfortunately I think that we have probably already missed
>>>>>> the opportunity to merge "foo" and "foo-state" subtrees together ...
>>>>>>
>>>>>> </Rob Wilton>
>>>>>>
>>>>>> Firstly, I’m trying to get a sense of how big a problem this
>>>>>> foo/foo-state thing is.  [Note: by foo-state, I’m only referring to
>>>>>> counters, not opstate].
>>>>>>
>>>>> RW:
>>>>> By counters, I think that we also mean any config false nodes that
>>>>> don't
>>>>> directly represent "applied configuration", right?  E.g. is an
>>>>> interface
>>>>> operationally up or down.
>>>>>
>>>>>>    I know about RFC 7223, which was done out of consideration for
>>>>>> system-generated interfaces, but how many other such models are
>>>>>>there
>>>>>> envisioned to be?
>>>>>>
>>>>> RW:
>>>>> - Any models that augment RFC 7223 and have config false nodes will
>>>>>be
>>>>> impacted.
>>>>> - I thought that quite a lot of other IETF models that are in the
>>>>> process of being standardized have a top level split between "foo"
>>>>>and
>>>>> "foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08)
>>>>>has
>>>>> this split.  I suspect that all the routing models will be structured
>>>>> similarly.
>>>> Correct. One reason is that the core routing model envisions
>>>> system-controlled RIBs.
>>>>
>>>>> - Although it is perhaps worth pointing out that I think that the
>>>>> OpenConfig modules effectively have exactly this same issue (e.g.
>>>>>they
>>>>> have a combined interfaces tree keyed by config true leaves), and
>>>>>they
>>>>> pragmatically just ignore the issue of system created interface
>>>>> entries.
>>>> The NETMOD WG considered this issue quite important in the past.
>>>>
>>>> My impression from the OpState discussion is that we are on the quest
>>>>of
>>>> the philosopher's stone, trying to find a shortcut where none is
>>>> possible in general. The long session in Berlin concentrated on the
>>>> life-cycle of a single parameter that's somehow configured, then
>>>> manipulated, and eventually ends up as operational state. IMO this
>>>> is too simplistic, the relationship between configuration and state
>>>>can
>>>> be much more complex. RIB is one example - it combines contributions
>>>> from configuration (static routes) and derived state (routing
>>>> protocols).
>>> If one were to support the Applied-Config data store, it be comprised
>>>of
>>> only the current state of the configured static routes.  The complete
>>>RIB
>>> would still need to be accessible in separate data nodes.
>> Yes, but I didn't talk about intended-applied. I understand that
>>another goal of OpState is to unify config and (true) state and get rid
>>of the foo and foo-state dichotomy in the data model. I am sceptical
>>about it.
>The goal is/was to unify where the only reason that they were split was
>because the lifetime of the configured containing datanode may differ
>from the operational containing datanode.  E.g. interfaces vs
>interfaces-state was split to allow for system created interfaces that
>were not configured, but other than this reason the split seems quite
>artificial and not particularly helpful.
>
>OpenConfig is modelling interfaces and interfaces-state as a single
>list.  It would be kind of helpful if IETF models and OpenConfig models
>could be consistent in this regard, and I prefer the combined list
>approach used by OpenConfig interfaces (on the assumption that we can
>solve the technical problems associated with this approach - which I
>think that we can).
>
>I've no particular issue with a RIB existing under routing-state. But
>personally, if it was the ISIS specific routing table, I would prefer it
>to be under a single top level ISIS container on the assumption that you
>cannot really have an ISIS routing table if ISIS isn't actually running
>on the device.

Don’t confuse a global RIB instance with an IS-IS local RIB instance.
These are separate tables (although the former may contain active entries
from the latter) and both would be interesting from an operational
perspective. 

Thanks,
Acee



>
>Cheers,
>Rob
>
>>
>> Lada
>>
>>> Thanks,
>>> Acee
>>>
>>>
>>>
>>>> After all, most real devices have some configuration mode and "show"
>>>> commands. They are separate even though there is certainly some
>>>> relationship between their data.
>>>>
>>>> Lada
>>>>
>>>>>> Is this issue currently blocking models from progressing, or are we
>>>>>> getting ourselves wrapped around a hypothetical?
>>>>>>
>>>>> RW:
>>>>> I think that it is blocking models from progressing.
>>>>>
>>>>> The current guidance for "intended vs applied" is clear.  I.e. there
>>>>> must not be "config false" leaves in the IETF YANG data models to
>>>>> represent "applied config".
>>>>>
>>>>> But there is no clear guidance for the rest of operational state that
>>>>> isn't applied config.  The other WGs need clear guidance (effectively
>>>>> now) to ensure that they can start publishing models as RFCs.
>>>>>
>>>>>
>>>>>>   If RFC 7223 is an outlier, then we can address it as a special
>>>>>>case
>>>>>> (perhaps via the related-state/related-config YANG annotations).
>>>>>>What
>>>>>> do you think?
>>>>>>
>>>>> RW:
>>>>> Personally, I would like one common convention that applies to all
>>>>>IETF
>>>>> YANG models.
>>>>>
>>>>> Idealistically I would like foo and foo-state to be merged because I
>>>>> think that will make the models easier to use and maintain in the
>>>>>long
>>>>> term, but I don't know if we are just too late to go in that
>>>>>direction.
>>>>>
>>>>> It seems to me that the NETMOD WG really should try to come to a
>>>>> decision quite quickly on this, but I don't know how to encourage
>>>>>that.
>>>>>
>>>>> A virtual interim on just this topic perhaps?
>>>>>
>>>>>> Next, regarding paths forward (assuming 7223 is not an outlier), I’m
>>>>>> thinking the opposite.  I’m quite sure that we would never merge the
>>>>>> 600+ models with separate subtrees back together again.  So I’m
>>>>>> thinking we immediately merge foo and foo-state in all active YANG
>>>>>> models (so that the YANG “conceptual” models are stable and good)
>>>>>> *and* then we use your idea to programmatically generate the
>>>>>> “foo-state” tree, presumably only when needed.  This foo-state tree
>>>>>> could be generated offline by tools and provided as a second YANG
>>>>>> module in drafts.  In this way, servers (opstate aware or not) can
>>>>>> advertise if clients can access the foo-state tree (an opstate-aware
>>>>>> server may still advertise it for business reasons, and it can
>>>>>> ‘deprecate’ the tree when no longer needed).   We could do the same
>>>>>> without tools today by just using a feature statement on, for
>>>>>> instance, the interfaces-state container, but I like pushing for
>>>>>> tooling upfront so that we’re guaranteed mergeability later.
>>>>>>Thoughts?
>>>>>>
>>>>> RW:
>>>>> So the generated "foo-state" tree would contain a copy of all config
>>>>> false nodes in the YANG schema and a "config false copy" of any
>>>>>config
>>>>> true nodes in the YANG schema that are required to provide parental
>>>>> structure for the descendant config false nodes.
>>>>> - The Xpath expressions would also need to be adjusted, and possibly
>>>>> some of those might break (or need to be fixed by hand).
>>>>> - Groupings might be a problem, but potentially they could be
>>>>>expanded.
>>>>>
>>>>> Technically this solution might work, but is it possible to get
>>>>> everyone
>>>>> to agree that this is the right direction to go in before we spend
>>>>>time
>>>>> on this?
>>>>>
>>>>> Thanks,
>>>>> Rob
>>>>>
>>>>>
>>>>>> Kent // as a contributor
>>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> -- 
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netmod
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> .
>>
>