Re: [netmod] system configuration sync mechanism

[Andy Bierman <[e-mail]>]

On Mon, Aug 9, 2021 at 2:51 PM Sterne, Jason (Nokia - CA/Ottawa) <
[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'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.
>
>

I think Balasz captured the 2 use-cases very well.
For implementations that combine the system into <running>, undoing
this behavior would be quite disruptive and therefore not likely to be done.

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.

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

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

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






>
>
> Jason
>


Andy


>
>
>
>
> *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]> 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]
> > 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/>
>
>