Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Andy Bierman <[e-mail]>]

Hi,

I am somewhat confused about this discussion.
Apparently it is a hyge problem to put foo-counters under
foo-state?  Configuration must be used (and setup by the operator?)
in order for foo-counters to exist?

So what problem does this solve?

The opstate solution proposal requires a config path-expr to be altered
to generate the corresponding path-expr under the 'state' container.
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?
It is no longer allowed to write monitoring modules?
They all have to contained within some configuration nodes?
Again, what problem is this trying to solve?


Andy


On Fri, Jul 29, 2016 at 7:15 AM, Ladislav Lhotka <[e-mail]> wrote:

> Robert Wilton <[e-mail]> writes:
>
> > On 28/07/2016 15:20, Ladislav Lhotka wrote:
> >>> On 28 Jul 2016, at 15:57, Acee Lindem (acee) <[e-mail]> wrote:
> >>>
> >>> Hi Lada,
> >>>
> >>> On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
> >>> <[e-mail] on behalf of [e-mail]> wrote:
> >>>
> >>>> Robert Wilton <[e-mail]> 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
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/netmod
> >>>> --
> >>>> Ladislav Lhotka, CZ.NIC Labs
> >>>> PGP Key ID: E74E8C0C
> >>>>
> >>>> _______________________________________________
> >>>> netmod mailing list
> >>>> [e-mail]
> >>>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>