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