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

Ladislav Lhotka <lhotka@nic.cz> Fri, 11 May 2018 08:22 UTC

Return-Path: <lhotka@nic.cz>
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 A0D0512E87B for <netmod@ietfa.amsl.com>; Fri, 11 May 2018 01:22:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 vHSrFZlLA7UU for <netmod@ietfa.amsl.com>; Fri, 11 May 2018 01:22:31 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 54FBE12E874 for <netmod@ietf.org>; Fri, 11 May 2018 01:22:31 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id B1372182015D; Fri, 11 May 2018 10:28:05 +0200 (CEST)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 85E251820157; Fri, 11 May 2018 10:28:02 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Sterne\, Jason \(Nokia - CA\/Ottawa\)" <jason.sterne@nokia.com>
Cc: "netmod\@ietf.org" <netmod@ietf.org>
In-Reply-To: <20180510172343.2uvlur2o2ypodbmk@elstar.local>
References: <AM0PR07MB3844939D2446BE899F0B06439B980@AM0PR07MB3844.eurprd07.prod.outlook.com> <20180510172343.2uvlur2o2ypodbmk@elstar.local>
Mail-Followup-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Sterne\, Jason \(Nokia - CA\/Ottawa\)" <jason.sterne@nokia.com>, "netmod\@ietf.org" <netmod@ietf.org>
Date: Fri, 11 May 2018 10:22:39 +0200
Message-ID: <87zi16ob3k.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Pev_aHJGt6R5hJCQUd_pv2h6rs4>
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: Fri, 11 May 2018 08:22:35 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:

> 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...

I thought the idea was (as the examples in 7895bis show) to have one
module-set that is shared in schemas for both config datastores and
<operational>. But then deviations cannot be used to differentiate
between those schemas because deviations are specified per module-set.

Lada

>
>> 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/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67