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

[Robert Wilton <[e-mail]>]

Hi Andy,

I think that it would be fair to say that the authors of 
draft-openconfig-netmod-opstate-01 think that it broken (e.g. sections 
6.1, 8.1.2), particularly given that they have decided that it is better 
to have their own OpenConfig version of interfaces rather than augment 
RFC 7223.  I might be mistaken, but my understanding is that the reason 
that they have done this is to avoid the interfaces vs interfaces-state 
split.

My impression from conversations in Berlin is that other individuals at 
IETF also don't particularly like the foo vs foo-state split, 
particularly for interfaces.

Regarding not breaking existing users, yes, I agree with you.  But this 
could still allow a new version of RFC 7223 to be published that marks 
the existing interfaces-state tree nodes as deprecated and adds new 
config false leaves to be under /interfaces.

Thanks,
Rob


On 27/07/2016 21:29, Andy Bierman wrote:
> 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] 
> <mailto:[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] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/netmod
>
>