[netmod] Combined config/state trees [was Re: Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits]

[Robert Wilton <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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 <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         Ladislav Lhotka <[e-mail] <mailto:[e-mail]>> wrote:
>>         >
>>         > > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder
>>         > > <[e-mail]
>>         <mailto:[e-mail]>> 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 <
>>         > >> [e-mail]
>>         <mailto:[e-mail]>> 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
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/netmod
>>         <https://www.ietf.org/mailman/listinfo/netmod>
>>
>>
>>
>>
>>     _______________________________________________
>>     netmod mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/netmod
>>     <https://www.ietf.org/mailman/listinfo/netmod>
>