On Thu, Dec 9, 2021 at 7:19 AM Sterne, Jason (Nokia - CA/Ottawa) < [email protected]> wrote:
> 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 ? > > > I am not proposing a solution here. I am referring to RFC 8342 use of the term "inactive", e.g: https://datatracker.ietf.org/doc/html/rfc8342#section-5 Any solution that overrides MUST requirements in YANG 1.1 requires a new YANG version. IMO it is unwise to send the industry the message that YANG 1.1 and NMDA need to be replaced and NMDA is an unstable experiment that is not ready for production networks. NMDA allows for inactive nodes in <running>. It is trivial to design a data model in such a way that it is inactive until a client uses it somehow. Where in RFC 8342 does it say that <running> config MUST or even SHOULD contain only nodes explicitly created by an external client? > 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 ? > I am not interested in a new datastore for NMDA. It has enough already. <running> can have active and inactive nodes in it. There is no need to create a new datastore and rewrite YANG to use a new datastore. > > Jason > Andy > > > *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]> 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]> *On Behalf Of *Andy Bierman > *Sent:* Friday, December 3, 2021 6:01 AM > *To:* 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 Fri, Dec 3, 2021 at 2:26 AM Jürgen Schönwälder < > [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] > https://www.ietf.org/mailman/listinfo/netmod > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
