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

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Nov 2016 11:23:04 +0900

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?

2. What is the distinction between dynamic configuration protocols and
   control-plane protocols?

3. Shared <candidate> has known problems. Maybe it's time to part with
   it in this new datastore model?

4. Templates are briefly mentioned in several places, it would be useful
   to explain this concept in more detail.

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.

Lada

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Nov 2016 10:42:10 +0100

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

> 2. What is the distinction between dynamic configuration protocols and

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.

>    it in this new datastore model?

This clearly was not the focus of this work.

>    to explain this concept in more detail.

I agree.

>    routes should appear in RIBs, so having them separately in operational

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.

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

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 14 Nov 2016 14:39:50 -0500

Juergen and Lada: 

#2 - is interesting to me.  Is dynamic configuration protocol = I2RS? Or
control-plane protocols = I2RS? 
On #5 - how do you merge I2RS RIB static routes  + routing-configuration rib
routes?  Can you see the difference in the applied configuration? 

Thanks, 

Sue 

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Juergen
Schoenwaelder
Sent: Monday, November 14, 2016 4:42 AM
To: Ladislav Lhotka
Cc: [email-masked]
Subject: Re: [netmod] comments on revised-datastores-00

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

Yes. The whole idea is to expose these potential differences instead of
hiding them behind a curtain.

I agree.

>    routes should appear in RIBs, so having them separately in operational

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.

/js

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 14 Nov 2016 22:10:32 +0100 (CET)

Hi,

> control-plane protocols = I2RS? 

Details tbd, but this architecture allows for a new kind of datastore
("control-plane datastore") which could be defined for i2rs.

> routes?

That is not covered by this architecture.  It has to be defined in i2rs.

> Can you see the difference in the applied configuration? 

You can see the result in the applied configuration, and you can see
the statically configured routes in <intended> and the i2rs-defined
routes in the-new-i2rs-datastore.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Nov 2016 13:42:18 -0800

Hi,

How do the YANG validation rules for datastores apply to this new framework?
The YANG RFC just refers to a 'valid' datastore. Is validation ever done
on the 'intended' datastore, or just 'running' (what we have now).

The framework you propose seems reasonable but the real issues show
up in the protocol interaction model(s) that are out of scope for this
draft.

Each datastore (running, intended, applied) can all be different, they can
all be YANG-valid, but I;m not sure that buys anything.  It seems
complicated
to determine that my specific edit is applied yet, while there are many
writers to the data subtrees.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Nov 2016 23:19:30 +0100

> on the 'intended' datastore, or just 'running' (what we have now).

Note that running == intended as long as you do not support inactive
node (commented out notes) or template expansion. If you do support
either of these extensions, that what you validate is actually
intended and not running. For example, inactive (comment out) nodes do
not matter for the validation.
 
> up in the protocol interaction model(s) that are out of scope for this

Yes, the protocol interaction do of course matter.

> all be YANG-valid, but I;m not sure that buys anything.

The current YANG valication rules apply to running/intended. The applied
configuration datastore includes dynamic elements hence validation (if
does exist for applied) likely has to have different semantics.

> It seems complicated to determine that my specific edit is applied
> yet, while there are many writers to the data subtrees.

Yes, since applied and operational-state are in general constantly
changing, it is not really possible to have well-defined
synchronization points at which things can be checked to be valid.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 14 Nov 2016 17:31:26 -0500

Martin: 

Thank you.  As usual, your answer is clear and enables me to work on the
next steps of coding and standardization.   

I'd love to talk off-list on how I've merged to I2RS RIB ephemeral control
protocol data store and Netconf intended datastore in a prototype in the
CONFD code. 

Sue 

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Monday, November 14, 2016 4:11 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [netmod] comments on revised-datastores-00

Hi,

"Susan Hares" <[email-masked]> wrote:
> Juergen and Lada: 
> 
> #2 - is interesting to me.  Is dynamic configuration protocol = I2RS? 
> Or control-plane protocols = I2RS?

> On #5 - how do you merge I2RS RIB static routes  + 
> routing-configuration rib routes?

> Can you see the difference in the applied configuration? 

You can see the result in the applied configuration, and you can see the
statically configured routes in <intended> and the i2rs-defined routes in
the-new-i2rs-datastore.

/martin

> The question I think really is whether a control-plane protocol 
> interacts with the configuration management component or not.
> 
routing.
> Yes, there can be redundancy but there can also be semantic 
> actually doing, looking at the <operational-state> datastore is probably a
good idea.

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 15 Nov 2016 09:48:35 +0900

> of hiding them behind a curtain.

That's fine but it doesn't answer my question.

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

> This clearly was not the focus of this work.

Then I would suggest to remove it entirely as a protocol-specific thing.

> actually doing, looking at the <operational-state> datastore is

But could this part of operational state be possibly different from
what's already in <applied>?

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 15 Nov 2016 07:14:50 +0100

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

> any more dynamic than NETCONF/RESTCONF is.

Yes, we know that 'dynamic' is potentially misleading.

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

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 16 Nov 2016 12:34:36 +0900

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

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

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

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Nov 2016 08:21:12 +0100

> - a leafref refers to a leaf that exists in <intended> but not in

It could be that <intended> just did not get applied yet. It may also
be that some mechanism simply overruled what <intended> wanted to
have. The whole reason we talk about these different datastores is to
be able to expose differences that may exist.

> they are dynamic configuration protocols.

Talking about 'control-plane protocols' is difficult since there is
not precise definition people agree on. That said, it is an
implementation decision how things work. I can implement a
control-plane mechanism that it either modifies operational-state
directly or that it goes through a configuration management component
to coordinate changes. But yes, the Linux "ip" command talks to the
kernel an directly modifies operational state. (And this is true for
pretty much all open source control plane daemon implementations I
have seen on Linux.)

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 16 Nov 2016 09:20:56 +0100 (CET)

> having differences between applied and operational state.

Note that in the draft, <applied> is defined in terms of being a
subset of <operational-state>.  Specifially, <applied> is the subset
of <operational-state> where origin is 'static' or 'dynamic' (or
derived from them).

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 16 Nov 2016 09:26:57 +0100 (CET)

> - a leafref refers to a leaf that exists in <intended> but not in

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?

> is implementation-dependent.

Yes it probably is.  But I'm not sure it is actually a problem.

> For example, if I use standard Linux
> 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>.

/martin

> Whether

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 17 Nov 2016 12:52:37 +0900

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

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

> 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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Nov 2016 21:07:57 -0800

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

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

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

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

>> >> > The question I think really is whether a control-plane protocol
interacts

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 17 Nov 2016 14:39:07 +0900

> On 17 Nov 2016, at 14:07, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

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

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

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

> 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

---

From: Phil Shafer <[email-masked]>
Date: Thu, 17 Nov 2016 03:03:56 -0500

Ladislav Lhotka writes:
>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 <inten
>ded> valid? Should the system-controlled entry permeate up to <intended>?

We should update the draft to make it clear to allow system-controlled
data to appear as part of the template/expansion activity so that
such data can be referred to from the running config.  For example,
a static route could have a next-hop of a system-defined lo0.  Not
that this is a good idea, but...

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 17 Nov 2016 17:17:25 +0900

> On 17 Nov 2016, at 17:03, Phil Shafer <[email-masked]> wrote:
> 
> Ladislav Lhotka writes:

I agree, this is often needed for system-controlled instances (default RIB is another use case), and so far the only option was to put a dummy entry into the configuration manually.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 17 Nov 2016 10:23:42 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> 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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 17 Nov 2016 10:24:41 +0100 (CET)

I agree.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 17 Nov 2016 10:27:51 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> 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

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 17 Nov 2016 10:29:28 +0100 (CET)

Phil Shafer <[email-masked]> wrote:
> such data can be referred to from the running config.

Ok, but I wouldn't call this data system-controlled.  It is added by
the template expansion algorithm and thus part of intended and thus
marked with an origin 'static'.

/martin

> For example,