Re: [netmod] NMDA - different valid keys for config vs state

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 10 May 2018 17:23 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 EA5CD12D95E for <netmod@ietfa.amsl.com>; Thu, 10 May 2018 10:23:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 2MD-u51ZinDw for <netmod@ietfa.amsl.com>; Thu, 10 May 2018 10:23:46 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6807D124B17 for <netmod@ietf.org>; Thu, 10 May 2018 10:23:46 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 3A3F66B6; Thu, 10 May 2018 19:23:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id cRymVMiC3207; Thu, 10 May 2018 19:23:44 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 10 May 2018 19:23:45 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 213B520035; Thu, 10 May 2018 19:23:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 66X6veT2QCTm; Thu, 10 May 2018 19:23:44 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B02320031; Thu, 10 May 2018 19:23:44 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 6E77842DF649; Thu, 10 May 2018 19:23:43 +0200 (CEST)
Date: Thu, 10 May 2018 19:23:43 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <20180510172343.2uvlur2o2ypodbmk@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <AM0PR07MB3844939D2446BE899F0B06439B980@AM0PR07MB3844.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AM0PR07MB3844939D2446BE899F0B06439B980@AM0PR07MB3844.eurprd07.prod.outlook.com>
User-Agent: NeoMutt/20171215
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/XyVQyZk9_KE1O8IIniijW-YAfgs>
Subject: Re: [netmod] NMDA - different valid keys for config vs state
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, 10 May 2018 17:23:49 -0000

On Thu, May 10, 2018 at 05:07:23PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote:
> Hi all,
> 
> In the NMDA approach we're trying to combine config & state into the same common tree structure.   i.e. For a given list, model a single list that contains both config & state, vs separate lists for each of config & state.
>

NMDA uses different datastores, only configured leafs appear in the
configuration datastores.

> But what happens when the valid value space for config vs state is different ?   For example -> what if an implementation has internally created interfaces with names that start with '_internal_' and doesn't allow configuration of those interfaces ?

These interfaces will appear in <operational> but not in <running> and
<intended>. They will also have a proper origin tag.
 
> If there were separate config vs state lists then the config list may have a pattern associated with the key that disallows names that start with '_internal_'.

Oh, you are concerned about your implementation not allowing
_internal_ for a configured interface? Well, in that case, I think the
server needs to reject the creation of such an interface.
 
> To keep the spirit of NMDA it would be a shame to split into separate config & state lists for this case.  Any recommendations ?
> 
> 1) make the 'pattern' for the key be a superset (i.e. allow _internal_) and then just reject config requests for _internal_ interfaces (e.g. at commit time) ?

This seems the way to go. The loopback interface is often system
created and it is commonly called 'lo' or something like this. I
assume a server will reject a request to create an interface named
'lo' which is a vlan interface on top of an ethernet interface.
Looking at RFC 7223, I found that the description of
/interfaces/interface/name talks quite a bit about the fact that a
system may put restrictions on the names that are accepted.

> 2) make the 'pattern' more strict to match config, and then return _internal_ interfaces for state queries (that in theory break the pattern for the key) ?

I think the type of key leafs should allow all possible key values.

> 3) other suggestions ?

With the new YANG library, I think one could have a deviation that
narrows down the type for the configuration datastore schemas. But
then people do not like deviations...

> Another example could be an integer key that has a larger range for state than it does for config (i.e. IDs >1000 are for internal entries only, not configurable).

Perhaps concrete text in the description statement is the simplest
solution.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>