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

["Acee Lindem (acee)" <[e-mail]>]

From: netmod <[e-mail]<mailto:[e-mail]>> on behalf of Kent Watsen <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, July 26, 2016 at 10:36 PM
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[e-mail]<mailto:[e-mail]>>, netmod WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure


<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].   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?  Is this issue currently blocking models from progressing, or are we getting ourselves wrapped around a hypothetical?  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?

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?

There are a number of issues here. The first is that you are now depending on the separate applied state data store being implemented on every network device if you are going to eliminate the duplication of actual values in the OpState. The second is that OpsState is MUCH more than just counters. For example, for routing protocols will many times include a local RIB. The third is that it is a big change for these draft models and, if you have been following the discussion on the list, you should know that this option is not universally accepted (reference the E-mail thread I started with options before IETF 96).

Acee







Kent // as a contributor