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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
