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