> On Nov 30, 2021, at 3:00 AM, Jürgen Schönwälder > <[email protected]> wrote: > > On Tue, Nov 30, 2021 at 02:24:52AM +0000, Kent Watsen wrote: >> Hi Juergen, >> >> >>> On Nov 29, 2021, at 6:49 PM, Jürgen Schönwälder >>> <[email protected]> wrote: >>> >>> On Mon, Nov 29, 2021 at 03:14:06PM -0800, Andy Bierman wrote: >>>> >>>> IMO the least disruptive solution possible should be used. >>>> There is a use-case for adding "origin" support to the <running> datastore >>>> in the <get-data> operation. >>>> This allows an NMDA client to identify system config that is not being used >>>> in <operational>. >>>> >>> >>> Looking at Figure 2 of RFC 8342, I wonder how system config gets into >>> running - other than a client writing it into running, at which point >>> the config becomes explicit config subject to the usual update rules >>> of <running>. Conceptually, you can have a system daemon acting as a >>> client updating <running> (perhaps even controllable by NACM). The >>> "origin" was not designed to track from which application config data >>> in <running> is originating, that's to be solved by other mechanisms. >> >> This idea is to mimic RFC6243’s “default” annotation and the "with-defaults" >> RPC. Just like with the “explicit” mode server, if a client writes to >> <running> and default value w/o the annotation, the server assumes it is >> explicit config (not the default anymore). Same here, if the client writes >> a “system” node w/o the annotation, the server assumes it is explicit config >> (not the <system>-defined node). In both cases, if the client includes the >> appropriate annotation, and the value/node matches the default/system value, >> then the server assumes that it’s actually the default/system value/node. >> >> FWIW, about 5 months ago (June 29), I offered this modified version of >> Figure 2 (Note the <system> box on the left). The “underlay” comment is >> meant to imply that <running> always overrides <system> when they’re merged: >> >> >> +-------------+ +-----------+ >> | <candidate> | | <startup> | >> | (ct, rw) |<---+ +--->| (ct, rw) | >> +-------------+ | | +-----------+ >> | | | | >> | +-----------+ | >> +-------->| <running> |<--------+ >> | (ct, rw) | >> +-----------+ >> | >> +----------+ | // configuration transformations, >> | <system> |-------------->| // e.g., removal of nodes marked as >> | (ct, ro) | // underlay | // "inactive", expansion of >> +----------+ | // templates >> v >> +------------+ >> | <intended> | // subject to validation >> | (ct, ro) | >> +------------+ >> | // changes applied, subject to >> | // local factors, e.g., missing >> | // resources, delays >> | >> dynamic | +-------- learned configuration >> configuration | +-------- system configuration >> datastores -----+ | +-------- default configuration >> | | | >> v v v >> +---------------+ >> | <operational> | <-- system state >> | (ct + cf, ro) | >> +---------------+ >> > > Your first paragraph does not match the figure. In your figure, system > config does not go into <running> instead it goes into a magic merge > box which is not shown (there is just an arror pointing to an arrow) > and then the result goes into intended.
The diagram is fine (to me) and consistent with the first paragraph. The goal of that diagram was to minimally-edit the RFC 8342 diagram. But. more importantly, do you now understand the with-system/default-annotation relation? If not, why not? If so, does it make sense now? K.
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
