Re: [netmod] OpsState and Schema-Mount

[Andy Bierman <[e-mail]>]

Hi,

I do not see any justification to RECOMMEND a combined tree.
I do not think 6087bis should give guidelines based on speculation
about a new holistic architecture in the future,

I agree with Juergen that the pros and cons of different approaches
should be discussed, and designers can decide which trade-offs
work best for them.


Andy


On Tue, Aug 9, 2016 at 2:31 PM, Kent Watsen <[e-mail]> wrote:

> 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]> 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/>
>
>
>