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

[Juergen Schoenwaelder <[e-mail]>]

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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>