Ladislav Lhotka <[email protected]> wrote: > Juergen Schoenwaelder <[email protected]> writes: > > > On Tue, Nov 15, 2016 at 09:48:35AM +0900, Ladislav Lhotka wrote: > >> Juergen Schoenwaelder <[email protected]> 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? > >> >> 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. > 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>. /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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
