Re: [netmod] comments on revised-datastores-00
Martin Bjorklund <mbj@tail-f.com> Thu, 17 November 2016 09:25 UTC
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0F11294D4 for <netmod@ietfa.amsl.com>; Thu, 17 Nov 2016 01:25:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level:
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FxY-7qHKxAE for <netmod@ietfa.amsl.com>; Thu, 17 Nov 2016 01:25:49 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6F15D129632 for <netmod@ietf.org>; Thu, 17 Nov 2016 01:25:49 -0800 (PST)
Received: from localhost (unknown [173.38.220.42]) by mail.tail-f.com (Postfix) with ESMTPSA id 875D21AE00B6; Thu, 17 Nov 2016 10:25:48 +0100 (CET)
Date: Thu, 17 Nov 2016 10:24:41 +0100
Message-Id: <20161117.102441.667832925270467105.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHRUEmwytt8nt7Wm5X=9HTERUt++j843BN_sEyq5Rko7Aw@mail.gmail.com>
References: <20161116.092657.1863684993696157894.mbj@tail-f.com> <m2r36an4oq.fsf@dhcp-8ee8.meeting.ietf.org> <CABCOCHRUEmwytt8nt7Wm5X=9HTERUt++j843BN_sEyq5Rko7Aw@mail.gmail.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/XBCNmfGXOMHRuTYlciy389UmO1A>
Cc: netmod@ietf.org
Subject: Re: [netmod] comments on revised-datastores-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2016 09:25:52 -0000
Andy Bierman <andy@yumaworks.com> wrote: > On Wed, Nov 16, 2016 at 7:52 PM, Ladislav Lhotka <lhotka@nic.cz> wrote: > > > Martin Bjorklund <mbj@tail-f.com> writes: > > > > > Ladislav Lhotka <lhotka@nic.cz> wrote: > > >> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes: > > >> > > >> > On Tue, Nov 15, 2016 at 09:48:35AM +0900, Ladislav Lhotka wrote: > > >> >> Juergen Schoenwaelder <j.schoenwaelder@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. > > 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) I agree. /martin > > > 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
- [netmod] comments on revised-datastores-00 Ladislav Lhotka
- Re: [netmod] comments on revised-datastores-00 Juergen Schoenwaelder
- Re: [netmod] comments on revised-datastores-00 Susan Hares
- Re: [netmod] comments on revised-datastores-00 Martin Bjorklund
- Re: [netmod] comments on revised-datastores-00 Andy Bierman
- Re: [netmod] comments on revised-datastores-00 Juergen Schoenwaelder
- Re: [netmod] comments on revised-datastores-00 Susan Hares
- Re: [netmod] comments on revised-datastores-00 Ladislav Lhotka
- Re: [netmod] comments on revised-datastores-00 Juergen Schoenwaelder
- Re: [netmod] comments on revised-datastores-00 Ladislav Lhotka
- Re: [netmod] comments on revised-datastores-00 Juergen Schoenwaelder
- Re: [netmod] comments on revised-datastores-00 Martin Bjorklund
- Re: [netmod] comments on revised-datastores-00 Martin Bjorklund
- Re: [netmod] comments on revised-datastores-00 Ladislav Lhotka
- Re: [netmod] comments on revised-datastores-00 Andy Bierman
- Re: [netmod] comments on revised-datastores-00 Ladislav Lhotka
- Re: [netmod] comments on revised-datastores-00 Phil Shafer
- Re: [netmod] comments on revised-datastores-00 Ladislav Lhotka
- Re: [netmod] comments on revised-datastores-00 Martin Bjorklund
- Re: [netmod] comments on revised-datastores-00 Martin Bjorklund
- Re: [netmod] comments on revised-datastores-00 Martin Bjorklund
- Re: [netmod] comments on revised-datastores-00 Martin Bjorklund