Re: [netmod] comments on revised-datastores-00

Ladislav Lhotka <lhotka@nic.cz> wrote:
> Martin Bjorklund <mbj@tail-f.com> writes:
> 
> > Ladislav Lhotka <lhotka@nic.cz> wrote:
> >> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:
> >> 
> >> > On Tue, Nov 15, 2016 at 09:48:35AM +0900, Ladislav Lhotka wrote:
> >> >> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:
> >> >> 
> >> >> > On Mon, Nov 14, 2016 at 11:23:04AM +0900, Ladislav Lhotka wrote:
> >> >> >> Hi,
> >> >> >> 
> >> >> >> I've read the revised-datastores-00 document, in general I like it, here
> >> >> >> are my initial comments and questions:
> >> >> >> 
> >> >> >> 1. Even if <intended> is valid, it can still be in conflict with the
> >> >> >>    actual content of <applied> that may come from e.g. dynamic
> >> >> >>    configuration protocols. How are such cases supposed to be resolved?
> >> >> >
> >> >> > Yes. The whole idea is to expose these potential differences instead
> >> >> > of hiding them behind a curtain.
> >> >> 
> >> >> That's fine but it doesn't answer my question.
> >> >>
> >> >
> >> > Then I do not understand the question. What does it mean for a
> >> > datastore to be in conflict with a different datastore?
> >> 
> >> For example:
> >> 
> >> - the data model has a choice with caseA and caseB. A NC/RC client
> >>   configures caseA, <intended> is valid, but <applied> already contains
> >>   caseB configured by a "dynamic configuration protocol"; or
> >> 
> >> - a leafref refers to a leaf that exists in <intended> but not in
> >>   <applied>.
> >
> > An open issue is what to do with semantic constrains.  For now, let's
> > assume they do not have to be valid.  This implies that you can have
> > leafrefs in <applied> that refer to non-existing leafs.
> >
> > However, for choices, I don't think two cases can exist at the same
> > time even in operational state.  If we allow this, where do we draw
> > the line - can a container or leaf exist in multiple instances?  can
> > a leaf of type int32 contain a string?
> 
> Certainly not. Rather than validate <intended>, it may be better to
> first merge <intended> with current content of <applied> to get the tentative
> future content of <applied>, and apply validation on it. 
> 
> >
> >> >> >> 2. What is the distinction between dynamic configuration protocols and
> >> >> >>    control-plane protocols?
> >> >> >
> >> >> > Good question. I believe this to be at the end implementation specific.
> >> >> > The question I think really is whether a control-plane protocol interacts
> >> >> > with the configuration management component or not.
> >> >> 
> >> >> OK, perhaps it can be said that dynamic configuration protocols modify
> >> >> "config true" data. Maybe a term like "configuration interface" may be
> >> >> better because it needn't be a communication protocol, and it needn't be
> >> >> any more dynamic than NETCONF/RESTCONF is.
> >> >
> >> > Yes, we know that 'dynamic' is potentially misleading.
> >> 
> >> My take from yesterday's discussion is that in fact the classification
> >> is implementation-dependent.
> >
> > Yes it probably is.  But I'm not sure it is actually a problem.
> 
> It isn't, but you could base the classification on where each
> contribution comes in instead of using fuzzy terms like dynamic
> configuration protocol.
> 
> >
> >> For example, if I use standard Linux
> >> command-line tools such as "ip", their result can be seen only in
> >> operational state, so they are like control-plane protocols. However, if
> >> an implementation patches these tools so as to write to <applied>, then
> >> they are dynamic configuration protocols.
> >> 
> >> >
> >> >> >> 5. Is it necessary that "<operational-state> datastore contains all
> >> >> >>    configuration data actually used by the system"? For example, static
> >> >> >>    routes should appear in RIBs, so having them separately in operational
> >> >> >>    state seems redundant.
> >> >> >
> >> >> > I do not understand your question. Is the RIB exposed or not? Anyway,
> >> >> > we need a general model and not a model for specific aspects such as
> >> >> > routing. Yes, there can be redundancy but there can also be semantic
> >> >> > differences. The <operational-state> datastore tells me what is
> >> >> > actually used (regardless of what has happened with the statically
> >> >> > configured values). In other words, if I want to debug what my box is
> >> >> > actually doing, looking at the <operational-state> datastore is
> >> >> > probably a good idea.
> >> >> 
> >> >> But could this part of operational state be possibly different from
> >> >> what's already in <applied>?
> >> >
> >> > This is subtle since we are not really able to define precisely what
> >> > the boundaries of a datastore are. Is something applied if the
> >> > responsible daemon accepted information? Or is it applied if the
> >> > daemon communicated information to the kernel? Or is it applied if the
> >> > linecard accepted the information from the kernel? Or is it applied if
> >> > the specific registers of the linecard have been programmed?
> >> 
> >> In my view, at some point the configuration system hands over the data
> >> to the backend that's responsible for performing the changes, and the
> >> data passed to the backend should be the content of <applied>.
> >
> > The data passed to the backends is <intended>.  The backend then tries
> > to apply it, and the result is <applied>/<operational-state>.
> 
> Hmm, but dynamic configuration protocols contribute to <applied>, and
> their contributions also have to be passed to the backend, right?
> 
> It would make more sense to me if <applied> contained the data (from all sources)
> that the configuration system considers valid and passes it to the
> backend.

The exact mechanism for doing this is of course implementation
dependent.  But if the system receives some data from DHCP and decides
to use it, it will be part of <operational-state>, and in th best of
worlds it will be tagged w/ origin = dynamic, and thus also part of
<applied>. 

/martin

> Whether or not (and when) the system makes the data effective
> then wouldn't be an issue.
> 
> Lada
> 
> >
> >
> >
> > /martin
> >
> >> Whether
> >> the changes take effect in the system or not may be discovered from
> >> operational state data but the configuration processing should be
> >> already over.  
> >> 
> >> > Similarily, how is operational state obtained? It is likely that an
> >> > implementation does not read linecard registers on every operational
> >> > state request. As a consequence, we might have systems where applied
> >> > really is just a subset of operational state and this may be true for
> >> > a large number of systems but I would not rule out the possibility of
> >> > having differences between applied and operational state.
> >> 
> >> We don't currently have static routes in routing-state, despite all
> >> criticism about duplication of config and state values, so it seems
> >> rather backwards to duplicate it in the new datastore model. What's
> >> important for an operator is to see whether a static route appears in a
> >> RIB or not.
> >> 
> >> Lada
> >> 
> >> >
> >> > /js
> >> >
> >> > -- 
> >> > 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/>
> >> 
> >> -- 
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >> 
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >> 
> 
> -- 
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 