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

[Ladislav Lhotka <[e-mail]>]

> On 17 Nov 2016, at 14:07, Andy Bierman <[e-mail]> wrote:
> 
> 
> 
> On Wed, Nov 16, 2016 at 7:52 PM, Ladislav Lhotka <[e-mail]> wrote:
> Martin Bjorklund <[e-mail]> writes:
> 
> > Ladislav Lhotka <[e-mail]> wrote:
> >> Juergen Schoenwaelder <[e-mail]> writes:
> >>
> >> > On Tue, Nov 15, 2016 at 09:48:35AM +0900, Ladislav Lhotka wrote:
> >> >> Juergen Schoenwaelder <[e-mail]> 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.
> 
> 
> 
> IMO this is not correct.
> 
> The running config cannot really be safely validated under this new model,
> because unexpanded templates and inactive nodes should not part of the
> validation.

I didn't mention validation of <running> at all.

> 
> The intended datastore should always be YANG-valid.
> It is disjoint from the applied datastore.

So let's say we have a list with min-elements = 1 (such as the list of RIBs), and there is already one entry provided by the system. what has to be done in order to make <intended> valid? Should the system-controlled entry permeate up to <intended>?

> 
> Using your example of case A and case B -- it is OK for a control plane
> protocol to override intended config (e.g., select case B causing case A
> to be deleted from applied).  The intended is not altered (case A still exists
> in intended).

According to the picture, control plane protocols affect operational state, so it is OK. 

> 
> The applied datastore should be valid independent of intended.
> You cannot merge them (e.g. case A and B not allowed to both exist).

I can merge them and report they the submitted <intended> would make <applied> invalid, i.e. the edit would be rejected.

Lada

> You can only compare them to find out that intended was overridden
> by a control protocol (e.g. case B is being used, not case A)
> 
> If the control protocol changes get removed then applied should reflect
> the intended (e.g. case A reappears in applied)
> 
> 
> Andy
> 
> 
> 
> 
> >
> >> >> >> 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. 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> >> > Fax:   [phone]         <http://www.jacobs-university.de/>
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

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