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

[Ladislav Lhotka <[e-mail]>]

Juergen Schoenwaelder <[e-mail]> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

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