On Wed, Nov 16, 2016 at 12:34:36PM +0900, Ladislav Lhotka wrote: > Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes: > > > On Tue, Nov 15, 2016 at 09:48:35AM +0900, Ladislav Lhotka wrote: > >> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> 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>.
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. > >> >> 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. 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 -- 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/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
