Hi Andy, I'm not sure I understand Kent's alternative that you're referencing here. Are you talking about something like JUNOS active/inactive configuration annotation ?
Is the "enable" some configurable metadata against data nodes ? When you say the "full set of nodes in running" are you talking about Jan's option #1 below (but perhaps without the explicit <system> datastore) ? i.e. all the system config is actually returning from a <get-config> of running ? Jason From: Andy Bierman <[email protected]> Sent: Wednesday, December 8, 2021 5:50 PM To: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]> Cc: Juergen Schoenwaelder <[email protected]>; Jan Lindblad <[email protected]>; Kent Watsen <[email protected]>; maqiufang (A) <[email protected]>; [email protected] Subject: Re: [netmod] Must offline-validation of <running> alone be valid? On Wed, Dec 8, 2021 at 2:31 PM Sterne, Jason (Nokia - CA/Ottawa) <[email protected]<mailto:[email protected]>> wrote: Hi guys, Andy - about use cases. Here is a problem we're trying to address: There are at least several major router implementations that have this concept of "hidden config" (i.e. list entries that can be referenced in a leafref by explicit user config, but those list entries are not returned in a <get-config>). Clearly not in compliance with RFC 7950. IMO the "enable flag" approach to the general problem, presented by Kent a couple years ago, is a much simpler and better solution than a new <system> datastore. The full set of nodes is in <running>. A generalized "enable" mechanism causes the resource to be used or not, where it shows up in <intended> and <operational> if enabled=true. IMO this fits the original intent of NMDA and does so in a way that requires the least disruption to current compliant implementations. Andy The server accepts these configurations (i.e. a validate or commit succeeds), but if you actually validate (e.g. with yangLint) the running datastore contents (e.g. fetched using <get-config>) to the YANG model it is not valid. That is against several RFCs referenced in the discussions below. IMO there isn't any "offline" vs" online" validation that is different. The contents of the running must be valid against the YANG model. A <get-config> returns the contents of the running. The server can validate it, or some other entity can validate it, but it must be valid. In Jan's option #1 the running config could be polluted with 100s or 1000s of lines of unreferenced/unused config. A <get-config> of a system without much config would instead return 100s/1000s of lines. I think that would be very annoying from a usability perspective. I'm in favor of this aspect of Jan's option #2: " + Clients unaware of the system datastore would have to include (copy) information from the system datastore to running in order to reference them." -> Only the list keys of referenced system objects would have to be copied (configured) into the running DS (to resolve leafrefs). We wouldn't need to copy all the descendant elements inside the referenced object. -> This copying would only need to be done by operators with a workflow that requires offline validation Some of this approach is already described in draft-ma-netmod-with-system-01: " In all cases, the clients should have control over the configurations ,i.e., read-back of <running> should contain only what was explicitly set by clients." "4.3. Explicit declaration of system configuration In addition to modifying system configuration, and adding nodes to lists in system configuration as described above, a client can also explicitly declare system configuration nodes in <running> with the same values as in <system>. When a client configures a node (list entry, leaf, etc) in <running> that matches the same node & value in <system>, then that node becomes part of <running>. A read of <running> returns those explicitly configured nodes. This explicit configuration of system configuration in <running> can be useful, for example, when an operator's workflow requires a client or offline tool to see the <running> configuration as valid. The client can explicitly declare (i.e. configure in <running>) the list entries (with at least the keys) for any system configuration list entries that are referenced elsewhere in <running>. The client does not necessarily need to declare all the contents of the list entry (i.e. the descendant nodes) - only the parts that are required to make the <running> appear valid offline. " I'm not a fan of option #3. It doesn't allow a mode of operating where a client/OSS has full control over the contents of the <running>. Some operators will want the master config to be owned up in their client/OSS and push it down. The server should just accept it and the client should be able to do a "read-back" and see exactly what was sent previously. I think we have a potential solution for this system config that keeps the running valid. But I'm far more worried about configuration templates. I don't see how we can possibly keep <running> valid with config templates. That seems like a major problem to me. But if we ever declare that <running> doesn't have to be valid, and only <intended> has to be valid, then offline tools can never validate (ahead of time) the config they actually download to the server. Jason From: netmod <[email protected]<mailto:[email protected]>> On Behalf Of Andy Bierman Sent: Friday, December 3, 2021 6:01 AM To: Juergen Schoenwaelder <[email protected]<mailto:[email protected]>>; Jan Lindblad <[email protected]<mailto:[email protected]>>; Kent Watsen <[email protected]<mailto:[email protected]>>; maqiufang (A) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [netmod] Must offline-validation of <running> alone be valid? On Fri, Dec 3, 2021 at 2:26 AM Jürgen Schönwälder <[email protected]<mailto:[email protected]>> wrote: On Fri, Dec 03, 2021 at 10:59:12AM +0100, Jan Lindblad wrote: > I made some proposals earlier, both on the interim and privately to the draft > authors, along these lines: > > Option #1 > + We could have a new system datastore that technically is a part of running. > Everything in system would show up in running to clients unaware of the > system datastore. Every time the system datastore changes for whatever > reason, the running datastore transaction ids (if we manage to get that > concept defined), are updated > + Clients interested to see pure view of the system datastore without > anything else in running could issue a get-data towards the system datastore > + Clients interested to see a pure view of running without any system > datastore elements could issue a get-data towards running with an extra flag > called 'without-system' > + Since all system elements are already part of running, clients have no need > to copy data between the two datastores > > Option #2 > + We could have a system datastore that technically is a part of operational. > Everything in system would show up in operational to clients unaware of the > system datastore. The running datastore always maintains referential > integrity, i.e. cannot reference the system datastore. > + Clients interested to see pure view of the system datastore could issue a > get-data towards the system datastore > + Since the system datastore is not part of running, clients can already see > a pure view of running without any system datastore elements using a simple > get-data. > + Clients that are aware of the system datastore and are interested to > configure references from running to system elements would issue an edit-data > rpc with the additional flag 'resolve-system-references'. This will make the > server copy any system elements referenced into running without the client > doing so explicitly. > + Clients unaware of the system datastore would have to include (copy) > information from the system datastore to running in order to reference them. > Option #3 There is a client on the system that makes changes to running just like any other remote clients can make changes to running. System generate config that is not editable explicit config in running goes straight into the applied config in operational. This does not require a system datastore (in fact something like a system datastore may exist as the _logic_ of the system client, the good old example we had is allocting an unused uid for an account that, once allocated, is maintained in running). +1 to option 3. Consider an implementation that moves all the "hidden system logic" off-box to a controller, such that the initial config is literally supplied by an external client. I have yet to hear a single use-case for creating a <system> datastore. "The client might want" is not a use-case for standardization. I do not understand the "pure view". Seems like if this was a real problem to solve, then NMDA would have included a system datastore from the start. /js Andy -- 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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
