On 7/28/16, 10:20 AM, "Ladislav Lhotka" <[email protected]> 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. Suffice it to day that in a combined tree there will be state that has not corresponding config. For example, the populated global RIB instances would fall into this category. Thanks, Acee > >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
