>> 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]
https://www.ietf.org/mailman/listinfo/netmod
