On 7/28/16, 10:42 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <rwil...@cisco.com> wrote:
> > >On 28/07/2016 15:20, Ladislav Lhotka wrote: >>> On 28 Jul 2016, at 15:57, Acee Lindem (acee) <a...@cisco.com> wrote: >>> >>> Hi Lada, >>> >>> On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka" >>> <netmod-boun...@ietf.org on behalf of lho...@nic.cz> wrote: >>> >>>> Robert Wilton <rwil...@cisco.com> 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 >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> . >> > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
