Hi Lada,
On 26/07/2017 11:46, Ladislav Lhotka wrote:
"Sterne, Jason (Nokia - CA/Ottawa)" <[email protected]> writes:
OK – so the same leaf (in the schema) has the same value space in the
conventional datastores and in the operational datastore. That probably makes
sense since a single schema describes the model for that leaf whether it is
accessed in conventional DSes or the operational DS.
But I think that also means that *if* you need slightly different
value spaces for an item, then you’ll need to split it into multiple
leafs in the schema.
This is easier said than done: will there be "foo" and "foo-state" as
sibling leaves, both present in <operational>, as sec. 4.7 indicates?
Apart from value space mismatch, there are other potential issues like
the one that I mentioned in Prague: "if-feature" applies to
configuration but not to state data. An example is in ietf-routing: in
config, "router-id" leaf is only present if "router-id" feature is
advertised (other servers derive router-id by other means), but in state
data "router-id" does not depend on the feature.
It is perhaps worth noting that the proposed NMDA YANG library allows
for different features to be expressed in different datastores. Not
that I am actually suggesting that this would be a good solution here.
The assumption made in NMDA that config and state data schemas can be
unified is IMO simply broken. YANG, being basically a document-oriented
schema language, is not designed to support such tricks.
I agree that you cannot align config and state schema values in all
cases. However, I think that in the vast majority of cases there is
close alignment between the configured value, and what the system is
using. Optimizing for this common case should make management systems
simpler for the mainline cases. There will always be some exceptions,
but that is OK too.
For the router-id, I think that my preferred solution would be to:
Define the "configurable-router-id" feature, have a single router-id
leaf, then put in the description that it is only configurable if the
"configurable-router-id" feature is enabled.
Possibly, in future, we could extend the YANG language to allow
if-feature to be conditionally applied to only config true or config
false elements.
An alternative solution, that works today, is to just have 2 separate,
but co-located, leaves:
1) cfg-router-id, config true, conditional on if-feature.
2) router-id, config false, operational.
- In the future, we could define a YANG extension to bind the config and
state leaves together in the model (e.g. a related-config statement).
But I think that we should see how often this issue turns up in practice
before we jump to doing this.
Thanks,
Rob
Lada
Jason
From: Kent Watsen [mailto:[email protected]]
Sent: Monday, July 24, 2017 20:53
To: Acee Lindem (acee) <[email protected]>; Sterne, Jason (Nokia - CA/Ottawa)
<[email protected]>; [email protected]
Subject: Re: [netmod] nmda-guidelines-01: value space for config vs state
Related, revised-datastores-03#section-4.7 says:
As a result of remnant configuration, the semantic constraints
defined in the data model cannot be relied upon for <operational>,
since the system may have remnant configuration whose constraints
were valid with the previous configuration and that are not valid
with the current configuration. Since constraints on "config false"
nodes may refer to "config true" nodes, remnant configuration may
force the violation of those constraints. The constraints that may
not hold include "when", "must", "min-elements", and "max-elements".
Note that syntactic constraints cannot be violated, including
hierarchical organization, identifiers, and type-based constraints.
The last sentence implies that the value-space must be the same between
nodes in <operational> and the conventional datastores.
Kent // contributor
On 7/24/17, 4:35 PM, "netmod on behalf of Acee Lindem (acee)"
<[email protected]<mailto:[email protected]> on behalf of
[email protected]<mailto:[email protected]>> wrote:
Hi Jason,
From: "Sterne, Jason (Nokia - CA/Ottawa)"
<[email protected]<mailto:[email protected]>>
Date: Monday, July 24, 2017 at 4:32 PM
To: Acee Lindem <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: RE: [netmod] nmda-guidelines-01: value space for config vs state
Hi Acee,
OK – maybe this example isn’t the best. But in the general case my concern
about using a super-set would be that it implies all those values are valid
input values for an edit-config in the candidate/running. I can’t immediately
see a clean way to indicate that some of the values aren’t valid for writing.
Another possible approach we could use is that if the value space is different,
then it means we should have separate leafs. The model designer could have 1
typedef for the common values (i.e. for applied/intended config), and then use
a union with additional values for the state/operational leaf that supports the
extra values.
Right – if there additional values that the leaf can take, then it is probably
pure operational state as opposed to applied config.
Thanks,
Acee
Jason
From: Acee Lindem (acee) [mailto:[email protected]]
Sent: Monday, July 24, 2017 16:22
To: Sterne, Jason (Nokia - CA/Ottawa)
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Subject: Re: [netmod] nmda-guidelines-01: value space for config vs state
Hi Jason,
From: netmod <[email protected]<mailto:[email protected]>> on behalf of "Sterne,
Jason (Nokia - CA/Ottawa)" <[email protected]<mailto:[email protected]>>
Date: Monday, July 17, 2017 at 6:22 AM
To: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: [netmod] nmda-guidelines-01: value space for config vs state
Hi all,
A note in Rob Wilton’s presentation today in rtgwg mentioned something about
consistency in the value space for config vs state leafs. The NMDA approach results in
the same leaf for both config & state in many cases (at least for the cases where
the separate config & state leafs were only there to represent intended vs applied
config).
But aren’t there some cases where the value space for state will be different than
the value space for config ? I’m thinking of the basic admin/oper state for
interfaces for example where config may allow enable/disable but state may have
additional values like ‘testing’. If the config & state value spaces aren’t
100% the same, are module designers recommended to create a separate state leaf ?
In this particular example, the leaf you are describing would be read-only
system state as opposed to applied state. If there were such a leaf that could
take on a wider range of values of applied state values than the intended
state, I’d expect the value space would need to be the superset.
Thanks,
Acee
Rgds,
Jason
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
