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

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 10 May 2018 17:27:51 +0000

I thought this had been discussed previously but couldn’t find the email.

IMO  option 1) makes more sense, the key range should be a superset of config and oper since the model applies to both. Don’t know if there’s any mechanism which allows for different range per datastore.

Regards,
Reshad.

From: netmod <[email-masked]> on behalf of "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thursday, May 10, 2018 at 1:07 PM
To: "[email-masked]" <[email-masked]>
Subject: [netmod] NMDA - different valid keys for config vs state

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