Hi,
On 13/01/2017 18:17, Andy Bierman wrote:
Hi,
IMO the YANG data model constraints are too domain-specific to generalize.
If the designer is adding a constraint (must, when. min-elements --
makes no difference)
then if must matter to that specific data model. It is not a SHOULD,
but a MUST.
Otherwise YANG has no value to data model designers.
Seems to me that your proposal combines 'applied' and 'operational'
incorrectly.
The only type of object that should be de-duplicated is the clone of
config-foo
for the sake of providing the oper-foo value (which could be supplied by
the get-oper RPC instead).
Yes, it is only the leaves in the "state tree" that duplicate the
corresponding configuration leaves that are de-duplicated. All other
config false leaves in the "-state" containers are just moved to the
merged config/state tree to avoid needing to maintain separate config
and state trees.
It is the 'applied' datastore that is not subject to validation, not
the operational datastore.
The "applied" datastore is a subset of the content in the operational
state datatstore.
But I don't think that either would necessarily be validated by a
device. I think that it would just report what the operational state is.
Combining trees doesn't work if the 'normal' config=false nodes are
placed under
a list or P-container. There is no way to instantiate these nodes
unless the ancestor
config nodes also exist.
There is no problem here because the operational state datastore allows
for these parent config nodes to exist for other reasons even if they
haven't been configured in running configuration.
They would have the meta-data annotation 'system' or 'dynamic'
The openconfig design pattern is getting phased out.
Phased out by whom? Do you mean for the IETF models (e.g BGP)?
I've not heard from the OpenConfig folks that they are intending change
the structural convention of their models.
This never involved 2 trees anyway
grouping config-X { .... }
uses config-X {
augment . {
container oper {
config false;
uses config-X;
}
}
}
I don't see how combining the ancestor top-level node with another one
makes any difference to the solution.
I think that a combined tree has various benefits:
- it makes the model more concise and consistent, with less manual
repetition between config and state, and without requiring the use of
groupings that can reduce readability.
- it provides a well defined way to report the actual applied
configuration that is in use by the device (allowing for time delays,
dynamic, and system controlled overrides).
- it provides a consistent path for where corresponding state for a
configuration node will be found.
For some existing IETF models, the config and state trees seem to have
diverged. This will make life harder for implementors since they will
need to hard code the relationship between the the config and state
tree. Having a single tree avoids this problem because it automatically
forces the config and state to be consistently co-located.
Rob
Andy
On Fri, Jan 13, 2017 at 8:21 AM, Robert Wilton <[email protected]
<mailto:[email protected]>> wrote:
[keeping netmod, bcc netconf]
On 12/01/2017 22:05, Andy Bierman wrote:
On Thu, Jan 12, 2017 at 1:59 PM, Martin Bjorklund <[email protected]
<mailto:[email protected]>> wrote:
Ladislav Lhotka <[email protected] <mailto:[email protected]>> wrote:
>
> > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder
> > <[email protected]
<mailto:[email protected]>> wrote:
> >
> > On Thu, Jan 12, 2017 at 09:38:46AM -0800, Andy Bierman wrote:
> >> On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder <
> >> [email protected]
<mailto:[email protected]>> wrote:
> >>
> >>> On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman
wrote:
> >>>>
> >>>> YANG statements:
> >>>> - It is not possible to define these statements so
they are different
> >>>> for config and oper
> >>>> - must
> >>>> - when
> >>>> - unique
> >>>> - key
> >>>> - min-elements
> >>>> - max-elements
> >>>> - leafref (path)
> >>>> - if-feature
> >>>> - deviation
> >>>> - type (or any sub-statements of type-stmt)
> >>>> - status
> >>>> - description
> >>>> - reference
> >>>
> >>> Considering statements that constraint 'values', it is
not entirely
> >>> clear to me what they mean for state nodes. If a server has
> >>> operational state that violates a must or range or ...
constraint in
> >>> the YANG model, what is the server expected to do?
> >>>
> >>
> >> The client uses the YANG validation to check on what the
server is
> >> sending.
> >> The server is buggy if it is sending data that violates YANG
> >> constraints.
> >> If any of these statements need to be different for
config and oper
> >> then the old style YANG has to be used instead.
> >>
> >
> > OK. So the client does the validation. What does the
client do if the
> > operational state it got is not valid according to the YANG
> > constraints?
>
> Don't forget that data models also provide guidelines to server
> implementors.
Yes, and that it is all that can be done currently. I don't
think any
implemention that receives a <get> request today freezes the
system in
order to get a guaranteed consistent snapshot. Instead, the
different
subsystems will be queried, sequentially or in parallell, and
the end
result is shipped to the client. The result may or may not be
consistent.
So this thread is questioning why YANG allows constraints on
config=false data nodes.
From the generic toolbuilder POV, it allows the YANG engine to
report issues to
the operator without custom programming for each little issue.
Who knows why the
foo-table requires 3 entries to be valid min-elements 3).
The tool can report to the operator "foo-table does not have
enough entries"
and let the operator decide what to do about it.
The constraint checking that you describe sounds more like a
"should" statement than a "must" statement.
I can't see that a server would want to validate must constraints
on config false nodes when it is the source of that data, for
several reasons:
- it is unclear what, if anything, it could do if one of the
constraints fails.
- it wouldn't want the extra validation processing overhead.
- there would be an assumption that the data generated should
conform to the model anyway.
Further, a client cannot reject a pushed notification or GET
response from a server even if it doesn't conform with the
constraints. I agree that the checking that you describe above
could be useful to flag problems, although I'm not sure how easily
an automated client would be able to deal with them anyway.
One of the strong stated desired from the OpenConfig operators is
that a device should accurately report what is is actually doing.
The question I have is what should a device do if it wants to
return a value outside of the allowable range. E.g. consider a
schema that defines the maximum allowed value for leaf foo as 2,
but due to some unexpected internal error, when the value is read
from hardware it reports that the value is 3 instead. Another
case would be if the server wanted to return a value outside the
specified range for a given type.
In these cases, depending on the encoding used, it may not be
possible to return a value at all. If this is a GET request then
the server can return a error for the particular leaf path. Does
an equivalent solution for notifications also exist?
Rob
/martin
Andy
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
