Re: [netmod] OpsState and Schema-Mount

[Ladislav Lhotka <[e-mail]>]

> On 09 Aug 2016, at 15:38, 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.

I would also add that some aspects of YANG (config true/false dichotomy, validation rules) make everything else difficult. 

> 
> 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.

Right. We have tried hard to find something more elegant, and some attempts (for example [1]) were quite similar to the current OpState proposals, but we eventually realised that our shortcuts only work in simple examples and break down in more complex situations.

That said, I don't claim that a more elegant solution is impossible (and Randy Presuhn would probably note that it was already available 25 years ago:-) but IMO it is not a low-hanging fruit given what we currently have (YANG and the protocols).

Lada

[1] https://tools.ietf.org/html/draft-bjorklund-netmod-operational-00

> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C