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

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 10 May 2018 17:07:23 +0000

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.

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 ?

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

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) ?

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) ?

3) other suggestions ?

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

Rgds,
Jason

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 May 2018 19:23:43 +0200

> 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 fo…

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_' a…

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 May 2018 10:22:39 +0200

> 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

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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