Re: [netmod] OpsState and Schema-Mount

[Kent Watsen <[e-mail]>]

Juergen, Andy,

I think that my proposed text for 6087bis clearly articulates what protocols can do today and tomorrow, while making a *very subtle* recommendation for today’s model designers to future-proof their models.

Please focus on the proposal, consistent with the Lou’s chair-request (https://mailarchive.ietf.org/arch/msg/netmod/NK864oXvIfeAYoCUTK40wn2Kw-8).

Kent // as a contributor


From: Andy Bierman <[e-mail]>
Date: Tuesday, August 9, 2016 at 5:01 PM
To: Juergen Schoenwaelder <[e-mail]>, Robert Wilton <[e-mail]>, Andy Bierman <[e-mail]>, Kent Watsen <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [netmod] OpsState and Schema-Mount



On Tue, Aug 9, 2016 at 6:38 AM, Juergen Schoenwaelder <[e-mail]<mailto:[e-mail]>> wrote:
On Tue, Aug 09, 2016 at 02:12:01PM +0100, Robert Wilton wrote:
>
> In particular, I think that the guideline would be along the lines:
> If a given module "foo" only contains state and no configuration, then
> having a single top-level "foo" config false node is fine, but if a given
> module contains both config and state then the recommendation is to put that
> under a config=true "foo" top-level node.  Refining that slightly, If the
> state data is relevant even if "foo" hasn't been enabled then make the top
> level "foo" an NP container.  If "foo" has to be enabled on the system for
> the state data to be relevant then make "foo" a P container (or give it a
> separate foo/enable leaf).  In summary, I would suggest that the foo state
> data should be pushed as far down the combined config/state tree as
> possible.  It should be sited below (or adjacent to) whichever config node
> is required to make that state data relevant.
>
> If config and state are in the same tree then it is easy to return all the
> data in one RPC, or have separate RPC operations that just return
> configuration (e.g. <get-config>), or just return "state + containing
> hieararchy" (e.g. a newly defined <get-state>, or equivalent).
>
> Having separate foo vs foo-state trees at the top level is always going to
> make it harder to return and manage a combined view of the config and state
> data.

I think it is crucial to separate (a) what protocols do today and (b)
what protocols might do at some time in the future.

The current protocol reality, that is (a), paired with the reality of
network interfaces has lead to the (/interfaces, /interfaces-state)
design pattern and until we have (b) in place I do not think we have
really an alternative for the (/interfaces, /interfaces-state)
design pattern.

If you have config and state are in the same tree, you simply can't
represent certain things that exist in reality. A single tree may look
'simpler' but in several cases also simply 'unusable'. We did not
particularly like the (/interfaces, /interfaces-state) design but it
was the only solution that seemed to work for all cases given the
protocol reality we were in.

+1

IMO the suggestion of using YANG extensions to associate data from different subtrees
was the most practical approach so far.  Moving objects and overloading object location
semantics will have a big impact on existing code.  Adding metadata and RPC operations
will not be disruptive, and it allows more complex associations to be expressed.

If the config needs to exist in order for the opstate and statistics to be relevant,
then of course put them in the config subtree.  But if they can be relevant without config,
then the config data model has to be more complex to distinguish bogus entries from real ones.
The YANG validation has to know the difference as well, adding hacks to that code.
The access model needs to account for creation of bogus entries vs. real ones,
adding an operational cost to this solution approach.

The YANG to use depends on the requirements.
The /foo-state tree can be considered "always on".
If this is not desired then a better design is to use a P-container:

   container foo {
     presence "Indicates foo counters are being collected";
     container foo-stats {
        config false;
        /...
     }
   }

This combination of config and state has a use-case.
I don't see a use-case for NP-container though.






/js


Andy


--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>