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

[Ladislav Lhotka <[e-mail]>]

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. 

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