The way to resolve things is to use name bindings. I can configure the interface "lo" in running by refering to this interface by name. If there is no "lo" in the system, then the config gets ignored.
/js On Thu, Nov 25, 2021 at 12:54:28PM +0000, maqiufang (A) wrote: > Hi, Jurgen, Martin, > > -----Original Message----- > From: netmod [mailto:[email protected]] On Behalf Of Martin Bj?rklund > Sent: Thursday, November 25, 2021 8:02 PM > 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: > > 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. > [Qiufang Ma] There is often a desire to reference a system configuration or > configure a descendant node of system configuration. How to keep > <running>/<intended> valid when leaf-ref a system configuration which is only > present in <operational>? Or do we think that explicitly configuration in > <running> should always be the case? > > I strongly agree. I didn't understand that part of the proposal. I guess > the discussion about origin system confused me; if system feeds into intended > then the origin will be intended. > [Qiufang Ma] If <system> feeds into <intended>, the server MUST remember a > particular data node is from system or from intended, those previously > present in <operational> with origin=system will keep the origin unchanged. > This work does not change that behavior. > > Best Regards, > Qiufang Ma > > > /martin > > > > > > > /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 -- 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
