> On 17 Nov 2016, at 14:07, Andy Bierman <a...@yumaworks.com> wrote: > > > > On Wed, Nov 16, 2016 at 7:52 PM, Ladislav Lhotka <lho...@nic.cz> wrote: > Martin Bjorklund <m...@tail-f.com> writes: > > > Ladislav Lhotka <lho...@nic.cz> 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>. > > > > 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? > > 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. > > > > 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.
I didn't mention validation of <running> at all. > > The intended datastore should always be YANG-valid. > 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>? > > 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). According to the picture, control plane protocols affect operational state, so it is OK. > > The applied datastore should be valid independent of intended. > 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 > 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 > > > > > > > >> >> >> 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. > > It isn't, but you could base the classification on where each > contribution comes in instead of using fuzzy terms like dynamic > configuration protocol. > > > > >> 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>. > > 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 > > > > > > > > > /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 > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
