Agreed. I’m not saying it isn’t possible to have a combined config/state tree. My previous point is that it represents a major shift and would be hard to reach consensus in the desired time frame.
Thanks, Acee On 7/28/16, 10:57 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email protected]> wrote: > > >On 28/07/2016 15:48, Acee Lindem (acee) wrote: >> >> On 7/28/16, 10:42 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at >> Cisco)" <[email protected]> wrote: >> >>> >>> On 28/07/2016 15:20, Ladislav Lhotka wrote: >>>>> On 28 Jul 2016, at 15:57, Acee Lindem (acee) <[email protected]> wrote: >>>>> >>>>> Hi Lada, >>>>> >>>>> On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka" >>>>> <[email protected] on behalf of [email protected]> wrote: >>>>> >>>>>> Robert Wilton <[email protected]> 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. >Sorry, I wasn't trying to - I should have written "a global RIB" >instead of "a RIB" ;-) > >I am suggesting that a global RIB could reasonably go under a path like >"routing-state/rib" (because it is not tidied to a particular protocol), >but that the IS-IS specific RIB instance could go under >"routing/isis/rib" (because it can surely only exist if IS-IS is >running*). > >*Note that I explicitly mean "running" here, as opposed to "configured", >since both "opstate drafts" allow the operational state datastore to >contain config true datanodes for things that are running but not >explicitly configured. > >Cheers, >Rob > >> >> 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 >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>> -- >>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>> PGP Key ID: E74E8C0C >>>>>> >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>>> . >>>> > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
