Re: [netmod] system configuration sync mechanism

[Andy Bierman <[e-mail]>]

On Fri, Aug 13, 2021 at 2:02 PM Sterne, Jason (Nokia - CA/Ottawa) <
[e-mail]> wrote:

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



It was a different email I think proposing extensions instead of a
datastore.

I actually do not really understand the 4 principles he mentioned:

*P1) “There is a need to validate configuration data against data created
by the system.”*

*P2) We want the running datastore to contain exactly what the operator has
written there*

*P3) the running/intended configuration MAY become invalid if the
system-data changes.*

*P4) rfc8342#section-5.3.4 MUST always be valid*

What does P1 really mean?
Provide a complete example using XML represented datastores (not
proprietary CLI)

P2) Why? What problem does this solve? What if the system creates an
interface list?
How does the client add any child nodes if this interface is not allowed to
be represented
in <running>?  IMO P2 does not even make any sense.

The "origin" attribute identifies the nodes that came from the system.
This is not visible in <running> only because of CLRs in the RFC.
It is visible in <operational>,

P3) not sure what this means. This is not what RFC 8342 says about
<intended>

P4) I agree with-origin must be supported (but it is an optional feature)
It is not possible for <operational> to always be complete and correct,
as discussed in NMDA, 5.3.

The YANG module in this proposal simply adds an identity for a new
datastore.
There are no examples and the guidelines in NMDA, Appendix A are not
followed.

The reason <system> was left out of NMDA seems to be because the system is
completely proprietary and not constrained in any way wrt/ how config and
operational
data nodes are instantiated.




> 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 still have no idea what problem this solves.
Maybe it is to make NMDA as hard to adopt as possible,
by being as different from non-NMDA as possible?



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



Why does the client need to know the origin of the data in <intended>
in order to validate it?  (Again, origin is only restricted to
<operational> because
the RFC forbids anything else).



>
>
>
>
>
>
>
>
>
>
> Jason
>
>
>
>
>
> Andy
>
>
>
>



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