On Tue, Aug 9, 2016 at 6:38 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
