Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote: > 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? > > > >> 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. > > > >> 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? > 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.
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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
