Re: [netmod] system configuration sync mechanism

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

Hi Andy,
Pls see inline.
Jason

From: Andy Bierman <[e-mail]>
Sent: Monday, August 9, 2021 6:23 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>
Cc: Juergen Schoenwaelder <[e-mail]>; Kent Watsen <[e-mail]>; NetMod WG <[e-mail]>
Subject: Re: [netmod] system configuration sync mechanism



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'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.
[>>JTS: ] I looked back at Balasz' email and I don't see clear use cases. Do you mean his P1, etc principles ?

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

[>>JTS: ] I'm not necessarily advocating for the existence of a <system> DS, but there are various implementations for this problem space and some don't put these system objects (list entries) into <running>. I'm doubtful about automatically putting system config into <running>. That means the client no longer really owns/controls <running>. Readback won't return what was sent. The definitive <running> would then have to sit on the server (i.e. can't have the client as the definitive view/ownership of running).

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>.
[>>JTS: ] An alternative is that these interfaces are *not* added to <running> unless a client explicitly adds them. The server could potentially consider leafrefs to them valid even if they aren't explicitly added. But if a user has a workflow that does offline validation, then they could explicitly add the interfaces into <running>

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.
[>>JTS: ] I don't think reading these nodes from <operational> addresses the issue. Clients do a <get-config> from <running> (or maybe <intended>) and want to be able to validate that config against the YANG model (without having to do additional reads from operational).






Jason


Andy



From: netmod <[e-mail]<mailto:[e-mail]>> On Behalf Of Andy Bierman
Sent: Wednesday, August 4, 2021 9:59 AM
To: Juergen Schoenwaelder <[e-mail]<mailto:[e-mail]>>; Kent Watsen <[e-mail]<mailto:[e-mail]>>; Andy Bierman <[e-mail]<mailto:[e-mail]>>; NetMod WG <[e-mail]<mailto:[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/>