Hi, You said "automated code". Write some YANG extensions for your tools to manually assign the mapping. This has already been suggested several times. This approach can also address N:M mappings. Supporting 1:1 mappings and ignoring everything else doesn't really help.
Andy On Fri, Jul 29, 2016 at 8:35 AM, Robert Wilton <rwil...@cisco.com> wrote: > Hi Andy, > > The main problem that I'm currently trying to solve, and get agreement on, > is "where does the operator's automated code look to find the state nodes > associated with a particular config node". > > E.g. for feature /foo, do they look for the config false nodes under /foo, > or do the look somewhere in /foo-state. The current answer appears to be, > that the config false nodes could appear in either place in the IETF > modules without any requirement for a consistent approach. Is that right? > > Separately, the OpenConfig folks have said that it would be better if they > could get (or register for notification of) all of the data associated with > "foo" with a single request rather than having to make multiple requests in > different trees. Personally, I prefer their model where they have merged > interface-state into interfaces. Mainly because I think that it should > make the YANG modules easier to read with less duplication of structure, > and I think that it is a better long term direction to go in. However, I > appreciate Acee's comments that we may just be too late to change this now, > and we must just accept the status quo (whatever that is). > > I would like to know what should the common approach for IETF standard > models be? E.g. is it one of the following: > > 1) All config false leaves for foo must go under /foo-state. > 2) All config false leaves for foo must go under /foo > 3) All config false leaves go under /foo where possible, or /foo-state > otherwise (e.g. for restconf-monitoring). > 4) Config false leaves go wherever the model writer decides is appropriate. > > I've put further comments inline below ... > > > On 29/07/2016 15:39, Andy Bierman wrote: > > Hi, > > I am somewhat confused about this discussion. > Apparently it is a hyge problem to put foo-counters under > foo-state? > > RW: > This isn't just about counters, it is all config false nodes that are not > present solely to represent "applied configuration". > > Configuration must be used (and setup by the operator?) > in order for foo-counters to exist? > > RW: > No, this is not being proposed. > > draft-schoenw and draft-wilton propose that the config true nodes are > allowed to exist in an "operational state datastore" to parent child config > false nodes, even though they haven't been configured. I also proposed > that metadata annotations could be used to indicate that the containing > config=true nodes in the operational state datastore exist only in the > system (and not in the configuration). > > Further I would propose that NETCONF/RESTCONF servers could support an > "operational state datastore" without any requirement to distinguish > applied configuration separately from intended configuration. > > > So what problem does this solve? > > RW: > I see that it potentially allows modules to avoid an arbitrary foo vs > foo-state split. > > > The opstate solution proposal requires a config path-expr to be altered > to generate the corresponding path-expr under the 'state' container. > > RW: > Are you referring to the OpenConfig model solution here or draft-schoenw, > or draft-wilton? > > It does not seem to be a problem that a new path-expr needs to be > constructed. > Is that what you are trying to solve? Even though counters never have > a corresponding configuration node with the same name? > > > So what happens to modules like ietf-restconf-monitoring? > > RW: > Either it stays exactly as it is now, or alternatively it could just be > named "restconf" rather than "restconf-state", even if it just contains > config false nodes. > > It is no longer allowed to write monitoring modules? > > RW: > It is still allowed to write monitoring modules, no change here. > > They all have to contained within some configuration nodes? > > RW: > No, not necessarily: > - it they are just state then either call them "foo" or "foo-state" as > per above. > - if they are mix of config and state then they would go under "foo", > which would be a config true node (but not necessarily configured, as per > my comments on the operational state datastore above). > > Again, what problem is this trying to solve? > > RW: > Hopefully this one has already been answered above. > > Thanks, > Rob > > > > > Andy > > > On Fri, Jul 29, 2016 at 7:15 AM, Ladislav Lhotka <lho...@nic.cz> wrote: > >> Robert Wilton <rwil...@cisco.com> writes: >> >> > 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). >> >> If we agree that there may be state data that have no direct >> counterpart in configuration, and these will be in foo-state, then the >> likely outcome is that in order to collect all state data, one will have >> to query both foo and foo-state, which doesn't seem ideal. >> >> Lada >> >> > >> > 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. >> > >> > 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 >> >> >> >> >> >> >> >> >> >> . >> >> >> > >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
