Robert mentions IS-IS, and if I look at OSPF, I see a clear separation of rw and ro nodes.
> On Jul 27, 2016, at 11:22 AM, Xufeng Liu <[email protected]> wrote: > > The assumption of “I suspect that all the routing models will be structured > similarly” is not correct. Very few models in routing area structure this way. > > Regards, > > - Xufeng > > From: netmod [mailto:[email protected]] On Behalf Of Robert Wilton > Sent: Wednesday, July 27, 2016 1:05 PM > To: Kent Watsen <[email protected]>; netmod WG <[email protected]> > Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG > Model Structure > > > > > 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. > - 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. > > >> 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 Mahesh Jethanandani [email protected]
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
