Re: [netmod] system configuration sync mechanism

["Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]>]

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

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

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.

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

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

It might be good to set up a virtual interim or call of some sort to discuss this one. It is pretty complex.

Jason


From: netmod <[e-mail]> On Behalf Of Andy Bierman
Sent: Wednesday, August 4, 2021 9:59 AM
To: Juergen Schoenwaelder <[e-mail]>; Kent Watsen <[e-mail]>; Andy Bierman <[e-mail]>; NetMod WG <[e-mail]>
Subject: Re: [netmod] system configuration sync mechanism



On Wed, Aug 4, 2021 at 6:39 AM Jürgen Schönwälder <[e-mail]<mailto:[e-mail]>> wrote:
The figure in RFC 8342 section 5 documents what was agreed upon
before. System configuration flows into <operational> but not upwards
into <running>. Over the years, we discussed several corner cases
(including things like configuring a new user and the system
automatically assigns an unused uid, which afterwards needs to be kept
stable). While there are for sure tricky corner cases, I am not
convinced that the model defined in RFC 8342 for the general cases is
wrong and that merging a new system datastore into <running> is the
right approach. If people want to change the model documented in RFC
8342, then they should make an explicit statement about this and
provide strong reasons that the model is flawed or incomplete.

Note that the model does allow having a system client merging config
into <running> (ideally controlled by an ACM so that such a client can
be turned off if it leads to surprises).


This is a solved problem in proprietary ways.  It is simple to treat system config
as an access control issue.

I am quite concerned that NMDA is getting extended in ways that lead to
confusion and poor interoperability.  Adding a new datastore is very serious.
IMO ANY new datastore (even factory default) should be standardized in
a new version of NMDA (replacing RFC 8342).

A datastore has a lot of baggage
   - YANG library
   - YANG XPath evaluation
   - subtree and XPath filtered retrieval
   - usage in RPC operations (ds:datastore data type parameter)

Every time a datastore is added, all the existing RPC operations that use
datastores need to be clarified wrt/ support for the new datastore.
(Of course this is never done, leading to lots of interoperability issues)

I am quite confused by the XPath discussions because XPath can only
access existing nodes (i.e. the "accessible tree")
https://datatracker.ietf.org/doc/html/rfc7950#section-6.4.1

So what does it mean for the system datastore to contain possible values that
cannot be represented in <operational>? The accessible tree cannot include
these values, so XPath-based validation cannot use them.



/js


Andy


On Wed, Aug 04, 2021 at 12:34:45PM +0000, Kent Watsen wrote:
>
> I am confused by the confusion  ;)
>
> You all know that JUNOS implemented this concept before YANG was even a thing, right?
>
> Admittedly, it’s not a “datastore“, but flexing the NMDA is where we can do better.
>
> A “with-system” mechanism could also work.  The only downside is the inability for a client to get only the system configuration, without the rest of <running>.
>
> Please stop stating/suggesting “config true” nodes are referencing “config false” nodes,  or that config is referencing operational state.  There is no intention to break either of these tenants here.
>
> I think that some folks just joined the conversation and may have missed out when we covered all this before.
>
> The draft needs to be updated to more clearly identify the goals.
>
> K.
>
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netmod

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>