Hi Andy, Pls see inline. Jason From: Andy Bierman <[email protected]> Sent: Monday, August 9, 2021 6:23 PM To: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]> Cc: Juergen Schoenwaelder <[email protected]>; Kent Watsen <[email protected]>; NetMod WG <[email protected]> Subject: Re: [netmod] system configuration sync mechanism
On Mon, Aug 9, 2021 at 2:51 PM Sterne, Jason (Nokia - CA/Ottawa) <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> On Behalf Of Andy Bierman Sent: Wednesday, August 4, 2021 9:59 AM To: Juergen Schoenwaelder <[email protected]<mailto:[email protected]>>; Kent Watsen <[email protected]<mailto:[email protected]>>; Andy Bierman <[email protected]<mailto:[email protected]>>; NetMod WG <[email protected]<mailto:[email protected]>> Subject: Re: [netmod] system configuration sync mechanism On Wed, Aug 4, 2021 at 6:39 AM Jürgen Schönwälder <[email protected]<mailto:[email protected]>> 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 > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
