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

[Ladislav Lhotka <[e-mail]>]

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

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