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

[Andy Bierman <[e-mail]>]

Hi,

*Re: - Any models that augment RFC 7223 and have config false nodes will be
impacted.*

There are many such vendor modules already.
They augment the /interfaces container with config
and the /interfaces-state container with non-config.
Nobody is complaining this is broken, AFAIK.
If you tell them to throw it out and start over, the request
is likely to be ignored.


Andy


On Wed, Jul 27, 2016 at 1:09 PM, Kent Watsen <[e-mail]> wrote:

> >> 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.
>
> KW:  Yes, the term “counters” is a misnomer.  We are indeed talking about
> regular old config false nodes, whether they be used for counters, gauges,
> or whatever.   It is what the opstate-reqs draft refers to as derived state.
>
>
>
>
>
>
>
> >> 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.
>
>
>
> KW: I also notice that draft-ietf-netmod-routing-cfg does this and, to
> your point, you know the ietf-routing module is intended to be augmented by
> many other modules.  This issue is not easily isolated.
>
>
>
> RW:
> 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.
>
> KW: indeed.
>
>
>
>
>
> 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?
>
> KW: I was going to suggest the same - will discuss with Lou.
>
>
>
>
>
> >> 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.
>
>
>
> KW: all good points.
>
> 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?
>
> KW: it was just an idea.   I’m trying to strike a balance between having
> the YANG models we want, and what is possible today (while waiting for the
> opstate solution to roll out).
>
>
>
>
>
>
>
> To flesh this idea out just a bit more, let’s say we have module
> “ietf-foo” as follows:
>
>
>
> module ietf-foo {
>
>   namespace “foo-namespace”;
>
>   container foo {
>
>     list bar {
>
>       key a;
>
>       leaf a {
>
>         type string;
>
>       }
>
>       leaf b {
>
>          type int8;
>
>          config false;
>
>       }
>
>    }
>
>   }
>
> }
>
>
>
> whereby it’s possible that the system may generate some bars as well.  To
> address this, the module is run through a TBD-tool to generate second
> module foo-state as follows:
>
>
>
> module ietf-foo-state {
>
>   namespace “foo-state-namespace”;
>
>   container foo-state {
>
>     list bar {
>
>       config false;    <-- everything below is config false
>
>       key a;
>
>       leaf a {    <-- this config true node kept only because it’s the key
>
>         type string;
>
>       }
>
>       leaf b {
>
>          type int8;
>
>          config false;
>
>       }
>
>    }
>
>   }
>
> }
>
>
>
> Now, here are the choices:
>
>
>
> 1) an opstate-unaware server might only support “ietf-foo”, as it is
> deemed unnecessary to provide the operational state for system-generated
> bars.
>
>
>
> 2) an opstate-unaware server might support both “ietf-foo” and
> “ietf-foo-state” as follows:
>
>
>
>        <get-config>
>
>          <source>
>
>            <running/>
>
>          </source>
>
>          <filter type="subtree">
>
>            <foo xmlns="foo-namespace"/>
>
>          </filter>
>
>        </get-config>
>
>
>
> returns the derived state for just configured bars, while:
>
>
>
>        <get-config>
>
>          <source>
>
>            <running/>
>
>          </source>
>
>          <filter type="subtree">
>
>            <foo-state xmlns="foo-state-namespace"/>
>
>          </filter>
>
>        </get-config>
>
>
>
> returns the derived state for both configured and system-generated bars.
>
>
>
> 3) an opstate-aware server only support “ietf-foo”, as it is expected that
> the derived state for system-generated bars can be obtained another way
> (e.g., via the “operational” datastore).
>
>
>
> 4) an opstate-aware server supports both “ietf-foo” and “ietf-foo-state”,
> most likely for backwards compatibility reasons.   The examples provided
> under (2) above continue to work and, later in time, the vendor can
> deprecate support for ietf-foo-state.
>
>
>
>
>
> Kent  // as a contributor
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>
>