Re: [netmod] AD review: draft-ietf-netmod-revised-datastores-08
Vladimir Vassilev <vladimir@transpacket.com> Wed, 20 December 2017 21:44 UTC
Return-Path: <vladimir@transpacket.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 19CE31200C5 for <netmod@ietfa.amsl.com>; Wed, 20 Dec 2017 13:44:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4U4rebaFD-pj for <netmod@ietfa.amsl.com>; Wed, 20 Dec 2017 13:44:35 -0800 (PST)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA26127867 for <netmod@ietf.org>; Wed, 20 Dec 2017 13:44:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id E2BFF33E06E9; Wed, 20 Dec 2017 22:44:32 +0100 (CET)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id LJnOFS8_VpGI; Wed, 20 Dec 2017 22:44:32 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id B7F7A33E06EA; Wed, 20 Dec 2017 22:44:32 +0100 (CET)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uml9hnUSaA0H; Wed, 20 Dec 2017 22:44:32 +0100 (CET)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 86D7F33E06E4; Wed, 20 Dec 2017 22:44:32 +0100 (CET)
To: Benoit Claise <bclaise@cisco.com>, NETMOD Working Group <netmod@ietf.org>
References: <e2fd599f-7547-d2f7-d450-f67a3f409ae1@cisco.com> <fe856e5c-5760-9bb9-ace3-cec0cfb39278@cisco.com>
From: Vladimir Vassilev <vladimir@transpacket.com>
Message-ID: <79d1baae-397d-883e-3bc0-e1c5f71fc4f8@transpacket.com>
Date: Wed, 20 Dec 2017 22:44:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <fe856e5c-5760-9bb9-ace3-cec0cfb39278@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/lkbOcIJvxLt9t-0lOQiRVi3_jmQ>
Subject: Re: [netmod] AD review: draft-ietf-netmod-revised-datastores-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 20 Dec 2017 21:44:38 -0000
Hello, On 12/20/2017 05:40 PM, Benoit Claise wrote: > Dear all, > > In order not to be the bottleneck in the process and assuming that the > document will be in "publication requested" pretty soon, here is my AD > review of draft-ietf-netmod-revised-datastores-08 > > - > > > 5.3.2. Missing Resources > > Configuration in <intended> can refer to resources that are not > available or otherwise not physically present. In these situations, > these parts of <intended> are not applied. The data appears in > <intended> but does not appear in <operational>. I have some concerns with this section. Systems implementing this are expected to remove config true; nodes while figuring the necessary changes to ensure the remaining set of config true; nodes in operational validates against the operational datastore model. The implementation of this is not a trivial task at all. In order to remove configuration nodes considered inactive on the fly one needs to remove all references to those nodes in mandatory leafrefs in the best case and a potentially long and complex dependency chain of YANG constrain-statements (Xpath etc.) have to be resolved in a worse case. It is difficult to automate this. It requires significant effort to track and remove/fix all those dependencies just to come up with valid configuration that represents the configuration without the "inactive" nodes which in many usecases is completely unjustified implementation effort. In addition in many cases it is not desirable to remove config true; nodes that depended on a removed resource. For example: 1. A configuration instance of a filter with mandatory interface-ref ingress and egress ports has to be removed from the operational datastore if the egress port is removed as a physical resource. This in effect removes the config false; statistics that might be still of interest counting the matched traffic while the filter does not have physical egress port to send the packets. 2. Alarm that is configured with mandatory reference to the missing resource containing a counter of the elapsed time since the resource went missing etc. I do not find any text in the draft addressing the concerns above. I do not propose a change yet but I hope to hear what others think about that. Vladimir > I understand what you want to say. > Let me take an example. I have a router with a Line Card configured > and working well. if I remove the LC, the configuration should still > be in the <running> and <intended> but not in <operational>. > However, based on figure below, the notion of "inactive" nodes might > be misleading. Indeed, people might read that the LC is inactive, so > the LC configuration should not be in <intended> > +-------------+ +-----------+ > | <candidate> | | <startup> | > | (ct, rw) |<---+ +--->| (ct, rw) | > +-------------+ | | +-----------+ > | | | | > | +-----------+ | > +-------->| <running> |<--------+ > | (ct, rw) | > +-----------+ > | > | // configuration transformations, > | // e.g., removal of "inactive" > | // nodes, expansion of templates > v > +------------+ > | <intended> | // subject to validation > | (ct, ro) | > +------------+ > I understand that "inactive nodes" has a different meaning. > > Proposal: > OLD: removal of "inactive" nodes > NEW: removal of the nodes marked as "inactive" > > - In the C.1 example, > <system > xmlns="urn:example:system" > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> > > <hostname or:origin="or:dynamic">bar</hostname> > > <interface or:origin="or:intended"> > <name>eth0</name> > <auto-negotiation> > <enabled or:origin="or:default">true</enabled> > <speed>1000</speed> > </auto-negotiation> > <speed>100</speed> > <address> > <ip>2001:db8::10</ip> > <prefix-length>64</prefix-length> > </address> > <address or:origin="or:dynamic"> > <ip>2001:db8::1:100</ip> > <prefix-length>64</prefix-length> > </address> > </interface> > I guess it "or:dynamic" should be replaced by "or:learned" > > Justification: > > identity learned { > base origin; > description > "Denotes configuration learned from protocol interactions with > other devices, instead of via either the intended > configuration datastore or any dynamic configuration > datastore. > > Examples of protocols that provide learned configuration > include link-layer negotiations, routing protocols,_and DHCP._"; > > _Editorial:_ > > - number the figures > > - section 8.2 > This document registers two YANG modules in the YANG Module Names > registry [RFC6020 <https://tools.ietf.org/html/rfc6020>]. Following the format in [RFC6020 <https://tools.ietf.org/html/rfc6020>], the the > following registrations are requested: > > duplicated "the the" > > Regards, Benoit (OPS AD) > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod
- [netmod] AD review: draft-ietf-netmod-revised-dat… Benoit Claise
- Re: [netmod] AD review: draft-ietf-netmod-revised… Martin Bjorklund
- Re: [netmod] AD review: draft-ietf-netmod-revised… Vladimir Vassilev
- Re: [netmod] AD review: draft-ietf-netmod-revised… Lou Berger
- Re: [netmod] AD review: draft-ietf-netmod-revised… Robert Wilton
- Re: [netmod] AD review: draft-ietf-netmod-revised… Vladimir Vassilev
- Re: [netmod] AD review: draft-ietf-netmod-revised… Juergen Schoenwaelder
- Re: [netmod] AD review: draft-ietf-netmod-revised… Robert Wilton
- Re: [netmod] AD review: draft-ietf-netmod-revised… Vladimir Vassilev
- Re: [netmod] AD review: draft-ietf-netmod-revised… Juergen Schoenwaelder
- Re: [netmod] AD review: draft-ietf-netmod-revised… Andy Bierman
- Re: [netmod] AD review: draft-ietf-netmod-revised… Robert Wilton
- Re: [netmod] AD review: draft-ietf-netmod-revised… Andy Bierman
- Re: [netmod] AD review: draft-ietf-netmod-revised… Robert Wilton
- Re: [netmod] AD review: draft-ietf-netmod-revised… Martin Bjorklund
- Re: [netmod] AD review: draft-ietf-netmod-revised… Robert Wilton
- Re: [netmod] AD review: draft-ietf-netmod-revised… Andy Bierman