On Jul 27, 2016, at 11:22 AM, Xufeng Liu
<[email protected] <mailto:[email protected]>> wrote:
The assumption of “I suspect that all the routing models will be
structured similarly” is not correct. Very few models in routing
area structure this way.
Regards,
- Xufeng
*From:*netmod [mailto:[email protected]]*On Behalf
Of*Robert Wilton
*Sent:*Wednesday, July 27, 2016 1:05 PM
*To:*Kent Watsen <[email protected]
<mailto:[email protected]>>; netmod WG <[email protected]
<mailto:[email protected]>>
*Subject:*Re: [netmod] OpsState Direction Impact on Recommended
IETF YANG Model Structure
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.
- 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.
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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
