On Wed, Dec 8, 2021 at 2:31 PM Sterne, Jason (Nokia - CA/Ottawa) < jason.ste...@nokia.com> 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 <netmod-boun...@ietf.org> *On Behalf Of *Andy Bierman > *Sent:* Friday, December 3, 2021 6:01 AM > *To:* Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>; Jan > Lindblad <j...@tail-f.com>; Kent Watsen <k...@watsen.net>; maqiufang (A) > <maqiufang1=40huawei....@dmarc.ietf.org>; netmod@ietf.org > *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 < > j.schoenwael...@jacobs-university.de> 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 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
