Re: [netmod] AD review: draft-ietf-netmod-revised-datastores-08
Robert Wilton <rwilton@cisco.com> Thu, 21 December 2017 10:34 UTC
Return-Path: <rwilton@cisco.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 CA35712D77B for <netmod@ietfa.amsl.com>; Thu, 21 Dec 2017 02:34:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 DBImEMdbNpbB for <netmod@ietfa.amsl.com>; Thu, 21 Dec 2017 02:34:33 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A921200C1 for <netmod@ietf.org>; Thu, 21 Dec 2017 02:34:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9181; q=dns/txt; s=iport; t=1513852473; x=1515062073; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ShwN1fhCmXOcFwXVeUR8OEbfvW2O9H4YqZB7vR99ymA=; b=MNxpcGBzLB69KfbnDZJKZCFZjmGAcr5oWdn5C5gK8XVmW+K3sECIETuC a04ys0U/rhGecDyq5rCIiDCa5/GSbfprbAKKiO5NHGGQrGmgkW0N2kWvn pftwyu//h81U8gjJCMzAYR2+dYQwa8wZ0zvn/Je+cYQ007ZSTerKiX4/t Y=;
X-IronPort-AV: E=Sophos;i="5.45,435,1508803200"; d="scan'208";a="1010535"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Dec 2017 10:34:31 +0000
Received: from [10.63.23.84] (dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com [10.63.23.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vBLAYUpD002825; Thu, 21 Dec 2017 10:34:31 GMT
To: Vladimir Vassilev <vladimir@transpacket.com>, NETMOD Working Group <netmod@ietf.org>
References: <e2fd599f-7547-d2f7-d450-f67a3f409ae1@cisco.com> <fe856e5c-5760-9bb9-ace3-cec0cfb39278@cisco.com> <79d1baae-397d-883e-3bc0-e1c5f71fc4f8@transpacket.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <64f59023-e000-18c4-8830-29ba6e9be7e9@cisco.com>
Date: Thu, 21 Dec 2017 10:34:30 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <79d1baae-397d-883e-3bc0-e1c5f71fc4f8@transpacket.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/FJKIEo_qMg5obvwtZTl5L8QDH_Y>
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: Thu, 21 Dec 2017 10:34:36 -0000
Hi Vladimir, First point of clarification is that this is not about running/intended at all. The contents of running/intended do not change in anyway depending on whether hardware is present or absent. The section is only concerned with how the configuration is applied in operational, and basically says that you cannot apply configuration for resources that are missing (which seems reasonable). E.g. I cannot configure an IP address on a physical interface that isn't there. Or if the physical interface gets removed then the configuration associated with that interface is also removed from operational. Operational isn't validated and data model constraints are allowed to be broken (ideally transiently). But I agree that there could be configuration that is referencing those missing resources, and depending on implementation then that configuration may need to become not applied as well. Or perhaps the failure is reported in a different way (e.g. IGP neighbor is down). I also agree that this is non trivial, but the systems that I am familiar with have always had to deal with this issue. At the data model level I don't think that this is any more complex than the existing 'when' statement processing that has exactly the same issues if a "when" statement becomes invalid during a config change and requires the associated configuration to be deleted (which again can recursively require configuration to be removed). Alternative solutions are: - mandate that nobody physically removes a linecard if there is still configuration referencing it, but it is hard to enforce this in software :-) - freeze the config from any further changes if a linecard is removed that makes the config invalid, but this doesn't seem like a robust solution ... I think that the existing solution is the best approach. A couple of further comments inline below as well ... On 20/12/2017 21:44, Vladimir Vassilev wrote: > 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. This isn't necessarily true. The architecture does not require that the filter object is removed because operational is allowed to violate the constraints. Ultimately I think that the behaviour here will depend on implementation. > > 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. Again, the draft does not require that the alarm becomes not applied. This also depends on the implementation. Thanks, Rob > > 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 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