Re: [netmod] system configuration sync mechanism

[Kent Watsen <[e-mail]>]

There was a request for concrete use cases.  This email from before was good:

	https://mailarchive.ietf.org/arch/msg/netmod/v5cNLcC2F_OT8t-407F3Zj6Vws4/ <https://mailarchive.ietf.org/arch/msg/netmod/v5cNLcC2F_OT8t-407F3Zj6Vws4/>


More below:



> On Aug 9, 2021, at 6:23 PM, Andy Bierman <[e-mail]> wrote:
> 
> On Mon, Aug 9, 2021 at 2:51 PM Sterne, Jason (Nokia - CA/Ottawa) <[e-mail] <mailto:[e-mail]>> wrote:
> Hi guys,
> 
>  
> 
> I'm late to the game on this thread but I did read through the entire thing (whew - can't promise I absorbed every nuance though). I am familiar with this issue. I've been dealing with it from the server implementation side (some clients *do* complain if there are references to missing "system config" list entries).
> 
>  
> 
> One of the pretty fundamental issues IMO is whether we want good ol' standard <running> to always be valid (including for an offline client or tool to be able to validate instance data retrieved from a server against the YANG models). Even without this "system config" topic, we already have a looming problem with config templates & expansion.  Servers with YANG models that document a lot of constraints (e.g. leafrefs, mandatory statements, etc) are more likely to hit this issue of an invalid running config (offline).
> 

I think that it is already the case with JUNOS that <running> by itself cannot be validated by a client unaware of how JUNOS templates work…as the templates may supply mandatory nodes and/or values, or some validations only make sense to evaluate when the config is flattened (e.g., ensuring "max-elements" is not exceeded, ensuring ACLs always end with a terminal rules, etc.).


> I'm doubtful that it is easy for a client to know how templates are expanded for all given servers. Unless that expansion is fully standardized (which would be challenging given multiple different shipping implementations in the industry), there can be some subtle corner cases and it can be complex (multiple levels of template application, exclusion rules, etc).
> 
Agreed, not easy but…

Some [smart] clients may never need to grok how device-level templates are expanded.  For instance, the NMS I worked on in a previous life would always onboard a new device by asking the device to provide its config already expanded, and thereafter would never send templated-config to the device (note: the NMS had its own template mechanism).  

On the other end of the client-spectrum, other [dumb] clients may also not need to grok how device-level templates are expanded, as they mostly push simple updates (e.g., open a port) known to pass validation and/or rely on server-side validation.

Of course, there MAY be clients in-between that read/write templated-config and, if they wish to perform off-box validation, most likely will need to grok how templates are expanded.


> I agree there can be dynamically added system config (e.g. create a new qos policy, and some queue list entries are automatically created inside that policy).
> 
I'm unsure how this relates.


> Note that config added by the system could be deletable or non-deletable. For deletable items there were some previous discussions a few years ago that those list entries could be simply a default config that is populated if the startup datastore is empty at boot time.
> 
Yes, but I that’s a different use-case, right?  (see the link to concrete use cases provided at top)


> The system config list entries could also have leafs that are modifiable and leafs that are immutable. For the modifiable objects I think this is basically the system merging the explicit config with the system config (with the explicit taking precedence).

The “modifiable” leafs are in this use-case, assuming “modifiable" is the synonymous as “over-writable".  Some “immutable” leafs are more like those discussed in RFC 8342 Section 5, but others are like what Andy discusses below (note: these immutable nodes are not currently in scope, as I understand it).


> Perhaps a lot of this system config is a legacy hold over from human-driven CLIs. For machine interfaces maybe it's reasonable to have clients explicitly define their config *if* they need offline validation of <running> to succeed (i.e. allow clients to explicitly configure any of the system config policies they are actually using & referencing).  In many cases, users want the "master" view of the config to live up in the client/OSS side and just push it down to the server (without having the server touch the contents of the running, i.e. a read-back should return identically what was sent).
> 
Agree that a read-back of <running> should always return identically what was sent, but that doesn’t mean that there isn’t system config in play.

> It might be good to set up a virtual interim or call of some sort to discuss this one. It is pretty complex.
> 
Good idea, but I’d hope first to get past the “do we understand the requirements” part of the discussion.  Of course, if people prefer, we could schedule an interim to discuss the use-cases also.

> I think Balasz captured the 2 use-cases very well.

The use-cases in his 7/31 message are good, but neither of them are part this work’s scope, as I understand it.  [update: his use-case ‘A’ may be in scope, depending on how we set the scope]


> For implementations that combine the system into <running>, undoing
> this behavior would be quite disruptive and therefore not likely to be done.

I do not support merging <system> into <running> (unless appropriately-annotated in a “with-system” <get-config> response).  I do support merging <system> into <intended>.


> It would help to have some common understanding of the contents of <system>.
> Maybe start with the well-known "interface problem".  The system configures almost empty physical interfaces.  The user is allowed to add, modify, and delete all descendants except the "name" and "type" leaf, which are set by the system.

I agree that concrete use-cases are needed.  The link provided at top provides some, but not all, and definitely not the specific one you just mentioned (which regards into Balazs’s use-case ‘A’ and Jason’s “immutable” config).


> In this case <running> will have the /interfaces/interface nodes in them (or else the client-accessible nodes could not be represented in NETCONF).  So any config=true XPath can point at name or type leafs in <running> or <operational>.

Ack.


> I have heard that <system> is needed because it has nodes in it that do not exist
> in <running> or <operational>, but could exist.  The premise is that the server could have created these nodes but it did not for some reason.  And the client can inspect these nodes and somehow force the server to change the nodes it adds to <running>. (So what is the real use-case then?)

This is what the link provided at the top of this message regards.


> Retrieving the system-created nodes with origin=system is already supported by NMDA.

True, but this “system config” feels different, or at least parts of it does.  We may need to tease apart the “leafref-able system nodes” from the “resource-independent nodes” from the “resource-dependent nodes”.



K.