I think it may be a server implementor's choice whether they would put a loopback interface into <system> (i.e. consider it as system provisioned configuration), or into <operational> (and not system, i.e. consider it as state information).
The primary <system> config use cases I see aren't so much interfaces, cards, etc. It is more for things like built in qos profiles and other handy policy objects that are more static (e.g. like Kent's JUNOS examples he has described). I'm not necessarily saying we preclude some of the resource-based dynamic system config proposed in the draft, but maybe those parts are more confusing/contentious. Jason > -----Original Message----- > From: netmod <[email protected]> On Behalf Of Jürgen > Schönwälder > Sent: Thursday, November 25, 2021 6:48 AM > To: Rob Wilton (rwilton) <[email protected]> > Cc: [email protected]; [email protected] > Subject: Re: [netmod] Should the origin="system" be required for system > configurations copied/pasted into <running>? > > I personally believe this notion of a system datastore is actually a > bad idea. A loopback interface, for example, is system generated and > it exists in operational but usually not in intended. I think it is > wrong to think that a system datastore feeds into intended. After all, > system config also comes and goes at the will of the system. I am not > following this in detail but I fear this work likely creates more > damage than that is solves serious real-world problems. > > /js > > On Thu, Nov 25, 2021 at 09:45:56AM +0000, Rob Wilton (rwilton) wrote: > > 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 > > -- > 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
