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

[Martin Bjorklund <[e-mail]>]

Ladislav Lhotka <[e-mail]> wrote:
> 
> > 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>?

system-controlled entries are not part of intended.

If you have some template that adds this entry you're good.  Otherwise
the user has to provide it, in order to meet the constraint.



/martin


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