Deletion of an interface != deletion of explicit configuration of an interface. NMDA allows to make this distinction and in a way that a client can discover what is going on.
/js On Thu, May 17, 2018 at 12:02:24PM +0000, Rohit R Ranade wrote: > Hi Robert, > > Thank you for the detailed explanation. > On the same lines that you mentioned, maybe some vendors were showing the > loopback interface, as part of running. Once they implement NMDA, is it the > intention of the authors to mandate that such configurations must be moved to > "system" ? Currently they may have limitations on such interfaces and donot > support deletion of such interfaces. > > With Regards, > Rohit R Ranade > > > From: Robert Wilton [mailto:[email protected]] > Sent: 17 May 2018 15:42 > To: Rohit R Ranade <[email protected]>; [email protected] > Subject: Re: [netmod] NMDA System controlled resource > > Hi Rohit, > On 17/05/2018 10:30, Rohit R Ranade wrote: > Hi Robert, > > So first , we try to get to know the system configuration. > Then for the configuration leaves (based on description), check whether > system configuration trumps the intended configuration ? If yes, retain > system configuration, Else apply intended configuration. > I think that this is probably an implementation choice, so my comments below > are subjective. > > E.g. I think that Junos devices always instantiate a loopback interface (lo0) > even if not configured, but IOS XR does not. This is fine, this is just a > difference in architecture. > > However, for both types of devices, configuring an IP address on the loopback > interface should work just fine: > > In the Junos case the lo0 interface already exists in <operational> with > origin "system", along with an IP address underneath it with origin > "intended". > > In the XR case, both the loopback0 interface and IP address are configured, > hence when the config is applied both data nodes appear in <operational> with > the origin "intended". > > > Hence normally it is up to the device implementation to decide whether a > particular item of system configuration trumps the intended configuration. > Whatever the system decides the appropriate value appears in <operational> > and the origin (if supported) of that value in <operational> MUST indicate > where it came from. So in the general case, I wouldn't expect YANG modules > to need to refer to system configuration. However, there are some specific > cases where it is useful to do so (e.g. RFC8343 describes system-controlled > interfaces). > > > > If for some leaf, there is no <intended> configuration , then apply system > configuration . > For the systems that I work on then I would normally expect an explicitly > configured value to trump a system value. If the device does not allow > values other than the system provided value then ideally it should deviate > the data node to only allow the system assigned value to be configured. > > If it is a container/list/etc then you may well need to merge the data coming > from <intended>, system and other places as well (e.g. IP addressed learned > via DHCP) > > Thanks, > Rob > > > > > Is my understanding correct ? > > With Regards, > Rohit R Ranade > > From: Robert Wilton [mailto:[email protected]] > Sent: 17 May 2018 14:29 > To: Rohit R Ranade <[email protected]><mailto:[email protected]>; > [email protected]<mailto:[email protected]> > Subject: Re: [netmod] NMDA System controlled resource > > > Hi Rohit, > > Section 5.3.2 states that you allowed to have configuration in > <running>/<intended> for resources that could be present on the device but > are not currently present. The canonical example would be interface > configuration for an interface on a linecard that isn't operational (either > because it isn't present, or hasn't completely initialized). > > Section 5.3.3 is saying that if the linecard becomes operational, then it may > instantiate system controlled entries (in <operational>) for those > interfaces. It also states that if there also happens to be configuration in > <running>/<intended> for those interfaces then that configuration will also > get applied as those interfaces as instantiated in <operational>. All of the > configuration that has been successfully applied would also appear in > <operational>. > > Thanks, > Rob > > On 17/05/2018 04:57, Rohit R Ranade wrote: > Hi All, > > RFC 8342 has below statement in Section 5.3.3 > "If a system-controlled resource has > matching configuration in <intended> when it appears, the system will > try to apply the configuration; this causes the configuration to > appear in <operational> eventually (if application of the > configuration was successful). > " > Why does application of configuration for system-controlled resources depend > on whether <intended> has configurations for that resource ? The > configuration will still get applied as part of "system" configuration as > shown in examples in Section C.1 in the same RFC given below > > "In addition to filling in the default value for the auto-negotiation > enabled leaf, a loopback interface entry is also automatically > instantiated by the system. All of this is reflected in > <operational>." > > > With Regards, > Rohit R Ranade > > > > > > _______________________________________________ > > netmod mailing list > > [email protected]<mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > 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
