Hi Martin, I think that the proposal is that <system> should feed into <intended> rather than directly into <operational>. The reasoning for this is to allow configuration to depend on system defined configuration during validation without requiring that configuration to be copied into <running>. Clients would still be allowed to explicitly express the system configuration is running as well - e.g., if they wanted a full configuration that they can validate off box. In your example below, I would probably mark the origin of the lo interface, the name leaf, and description leaf as "intended", but the type is "system". I think that this would be similar to how I would expect a default value to be reported. I.e., if the running config explicitly sets a leaf to its default value, I think that it is more informative to report that as origin "intended" rather than "origin" default. But I don't think that RFC 8342 proscribes what is be used in these cases.
Regards, Rob // As a contributor > -----Original Message----- > From: netmod <[email protected]> On Behalf Of Martin Björklund > Sent: 24 November 2021 10:44 > To: [email protected] > Cc: [email protected]; [email protected] > Subject: Re: [netmod] Should the origin="system" be required for system > configurations copied/pasted into <running>? > > Jürgen Schönwälder <[email protected]> wrote: > > On Wed, Nov 24, 2021 at 03:21:14AM +0000, maqiufang (A) wrote: > > > > > > But suppose the node is a list entry (e.g., an interface) or a leaf with > > > the > same value. In this case, it is not clear which origin should be used. I > think it > would be ok to use "system" in this case. > > > > For me, <running> is explicit config and hence it has precedence. The > > precedence must be a function of how the datastores related, it should > > not depend on which values a config leaf has. > > Here's a simple example. > > Suppose <system> has: > > <interface> > <name>lo</name> > <type>loopback</type> > <description>added by system</description> > </interface> > > and <intended> has: > > <interface> > <name>lo</name> > <description>set by a client</description> > </interface> > > Now we follow the picture in RFC 8342: > > +------------+ > | <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) | > +---------------+ > > > So now we merge intended and system into operational state. First we > add system to get: > > <interface origin="system"> > <name>lo</name> > <type>loopback</type> > <description>added by system</description> > </interface> > > and then we add intended to arrive at: > > <interface origin="system"> > <name>lo</name> > <type>loopback</type> > <description origin="intended">set by a client</description> > </interface> > > > Doesn't this make sense? > > > > /martin > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
