Re: [netmod] Comments on NMDA-04

Robert Wilton <rwilton@cisco.com> Fri, 15 September 2017 11:07 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 65382133020 for <netmod@ietfa.amsl.com>; Fri, 15 Sep 2017 04:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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, 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 PAA3u7nsSHCG for <netmod@ietfa.amsl.com>; Fri, 15 Sep 2017 04:07:25 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6A21330B0 for <netmod@ietf.org>; Fri, 15 Sep 2017 04:07:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4964; q=dns/txt; s=iport; t=1505473644; x=1506683244; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=rKDpZk3dBUYfxUaqKHY3e+wCuRCpk2lWlEhxOhHvI+g=; b=Z/IXLBwE2Ke05XZ0hFqmHvJj4Wdef9ZgDN8JSLupi7e+7zpwBm40CB+U nYZw7UGW7xzaEfAB2fRyllYlXufqlKTWwezlh3R/TdK9WuabQorIERWM1 4S3129gPA+qRp0t23SqxJO2VwTnS1X4dnkduj5XrsLvJ0u0G3fumgGIxG Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BNAgBWs7tZ/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhSyEHIsUkEorljWCBAqFPAKEbRUBAgEBAQEBAQFrKIUYAQEBAQIBIw8?= =?us-ascii?q?BBVEJAhIGAgIRFQICSQ4GAQwIAQGKJwiNZp1mgieLMgEBAQEBAQEDAQEBAQEBI?= =?us-ascii?q?oEOgh2DUoFjKwuCcoQzLQJVglSCYAWhBJRVghOFaoNahyGNXYdVgTk1IoENMiE?= =?us-ascii?q?IHBWHZj+HCCuCFAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,396,1500940800"; d="scan'208";a="655662662"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 11:07:22 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8FB7M3i027295; Fri, 15 Sep 2017 11:07:22 GMT
To: Balazs Lengyel <balazs.lengyel@ericsson.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <53c34593-7749-a257-b7ea-1fce99acf844@cisco.com>
Date: Fri, 15 Sep 2017 12:07:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.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/Ms7DuKUFIcFaKJWEBAhT7OTAaBU>
Subject: Re: [netmod] Comments on NMDA-04
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: Fri, 15 Sep 2017 11:07:26 -0000

Hi Balazs,

I also wanted to comment on validation.  Please see inline below ...

On 14/09/2017 15:04, Balazs Lengyel wrote:
> Hello,
>
> Reading the draft-ietf-netmod-revised-datastores-04 some comments:
>
> General) The system often adds data to the <running> or <intended> 
> datastore already not just to <operational>: e.g.
>
> UC1: I have a server configured in running. I need to bind it to an 
> ip-address. The ip-address might be the local loopback address, 
> however if that is only added to the <operational>, validation will 
> fail indicating that the server is bound to a non-existent address. 
> How to handle this?
>
> UC2: I have a set of capabilities set by the system e.g. 
> supported-reporting-intervals. I need to configure a job that MUST use 
> one of these intervals. If the supported-reporting-intervals are only 
> added to <operational> I can not validate the selected-interval in my 
> configured job.
>
> My proposal is to allow the system to add data to running as well. 
> Actually I think that is a more relevant case then adding 
> configuration just to <operation>.
>
> CH 4.4.)  "Validation is performed on  the contents of <intended>." 
> This to me means that default data is not considered at validation 
> which would be a backwards incompatible change. Also if validation 
> does not consider system configured data that would allow cases like 
> multiple interfaces named lo0. One from <intended> one from system 
> configuration. IMHO while it is OK to violate uniqueness because of 
> remnant data, the above violation of uniqueness seems a bad idea.
When we have been previously discussed this as part of the design team, 
we wanted the invariant that <running>/<intended> should not be able to 
become invalid due to an external change in the system (e.g. a linecard 
is removed or changed, or the device has run out of some resource).  I 
think that the corollary to this is that when the existing NETCONF 
validation is performed, the validation must not take into account 
anything specific to the device that could change due to some external 
event (e.g. linecard is changed etc).  So this means that a valid 
configuration just represents what could be applied to the device, if 
enough resources were available, and the correct types of linecards had 
been populated and were working, etc.

But often, clients want more than this.  They don't want to just know 
whether the configuration could theoretically work, but actually want to 
know whether the device anticipates that it will be able to enact the 
configuration successfully.  So, I think that NETCONF actually also 
needs a separate "should apply ok" extension RPC.  This "should apply 
ok" RPC would do everything that validate does today, but can also do 
many more checks to try and ensure that the configuration change is 
likely to be successful applied to <operational> (e.g. check that the 
necessary hardware is present and working, licenses have been enabled, 
resources are available, etc).  Obviously, this "should apply ok" 
invariant would not necessarily always hold for the configuration 
datastores.  An engineer may pull out a linecard that means that 
configuration currently in <running>/<intended> is valid (as is required 
in RFC 7950), but would not be applied successfully due to the missing 
hardware.

But I also think that this is beyond the scope of the current NMDA 
architecture, but perhaps something that could be specified by a 
separate draft, if others also think that this would be useful to 
standardize?

Thanks,
Rob


>
> Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it 
> should not be.
>
> Ch 5.1) IMHO actions and rpcs should be allowed to include other 
> datastores in their XPath evaluation. My suggestion is that they need 
> to specify it somehow. (Yang extension?)
>
> UC1) I want to define a convinience action that allows me to do a big 
> modification in <running> in one step. I wan't to validate what it is 
> doing based on the current contents of running. E.g. configure the OAM 
> settings for the system including SNMP/Netconf/FTP in one step, but 
> for each step I need to check that I am putting the relevant server on 
> an existing interface.
> If specifying the datastore is an overkill, I would still rather chose 
> runing as the accessible datastore. XPath is mostly use for checks. 
> Checks are done against configuration.
>
> Appendix B)
>
> "4. How applied     : automatic"    This is definitely not enough to 
> understand what happens even as an example. I propose:
> Changes are automatically propagated to <operational>
>
> C.1)  During the example the
>     <ip>2001:db8::10</ip>
>      <prefix-length>32</prefix-length>
> is changed to 64 its. Is that intentional? It is not mentioned in the 
> text.
>
> regards Balazs
>
>