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
