Re: [netmod] NMDA System controlled resource
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 +, 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:rwil...@cisco.com] > Sent: 17 May 2018 15:42 > To: Rohit R Ranade <rohitrran...@huawei.com>; netmod@ietf.org > 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 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 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 > and the origin (if supported) of that value in 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 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 , 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:rwil...@cisco.com] > Sent: 17 May 2018 14:29 > To: Rohit R Ranade <rohitrran...@huawei.com><mailto:rohitrran...@huawei.com>; > netmod@ietf.org<mailto:netmod@ietf.org> > Subject: Re: [netmod] NMDA System controlled resource > > > Hi Rohit, > > Section 5.3.2 states that you allowed to have configuration in > / 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 ) for those > interfaces. It also states that if there also happens to be configuration in > / for those interfaces then that configuration will also > get applied as those interfaces as instantiated in . All of the > configuration that has been successfully applied would also appear in > . > > 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 when it appears, the system will >try to apply the configuration; this causes the configuration to >appear in eventually (if application of the >
Re: [netmod] NMDA System controlled resource
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:rwil...@cisco.com] Sent: 17 May 2018 15:42 To: Rohit R Ranade <rohitrran...@huawei.com>; netmod@ietf.org 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 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 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 and the origin (if supported) of that value in 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 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 , 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:rwil...@cisco.com] Sent: 17 May 2018 14:29 To: Rohit R Ranade <rohitrran...@huawei.com><mailto:rohitrran...@huawei.com>; netmod@ietf.org<mailto:netmod@ietf.org> Subject: Re: [netmod] NMDA System controlled resource Hi Rohit, Section 5.3.2 states that you allowed to have configuration in / 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 ) for those interfaces. It also states that if there also happens to be configuration in / for those interfaces then that configuration will also get applied as those interfaces as instantiated in . All of the configuration that has been successfully applied would also appear in . 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 when it appears, the system will try to apply the configuration; this causes the configuration to appear in eventually (if application of the configuration was successful). " Why does application of configuration for system-controlled resources depend on whether 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 ." With Regards, Rohit R Ranade ___ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] NMDA System controlled resource
From: Robert Wilton [mailto:rwil...@cisco.com] Sent: 17 May 2018 15:42 To: Rohit R Ranade <rohitrran...@huawei.com>; netmod@ietf.org 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 with origin "system", along with an IP address underneath it with origin "intended". [Rohit R Ranade] In this case, I think the lo0 interface will be part of startup DB / running DB. Because if the parent (interface) is part of "intended" only then a child (IP address) can be part of "intended". Right ? In the XR case, both the loopback0 interface and IP address are configured, hence when the config is applied both data nodes appear in 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 and the origin (if supported) of that value in 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 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 , 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:rwil...@cisco.com] Sent: 17 May 2018 14:29 To: Rohit R Ranade <rohitrran...@huawei.com><mailto:rohitrran...@huawei.com>; netmod@ietf.org<mailto:netmod@ietf.org> Subject: Re: [netmod] NMDA System controlled resource Hi Rohit, Section 5.3.2 states that you allowed to have configuration in / 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 ) for those interfaces. It also states that if there also happens to be configuration in / for those interfaces then that configuration will also get applied as those interfaces as instantiated in . All of the configuration that has been successfully applied would also appear in . 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 when it appears, the system will try to apply the configuration; this causes the configuration to appear in eventually (if application of the configuration was successful). " Why does application of configuration for system-controlled resources depend on whether 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 ." With Regards, Rohit R Ranade ___ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
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 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 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 and the origin (if supported) of that value in 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 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 , 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:rwil...@cisco.com] *Sent:* 17 May 2018 14:29 *To:* Rohit R Ranade <rohitrran...@huawei.com>; netmod@ietf.org *Subject:* Re: [netmod] NMDA System controlled resource Hi Rohit, Section 5.3.2 states that you allowed to have configuration in / 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 ) for those interfaces. It also states that if there also happens to be configuration in / for those interfaces then that configuration will also get applied as those interfaces as instantiated in . All of the configuration that has been successfully applied would also appear in . 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 when it appears, the system will try to apply the configuration; this causes the configuration to appear in eventually (if application of the configuration was successful). “ Why does application of configuration for system-controlled resources depend on whether 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 .” With Regards, Rohit R Ranade ___ netmod mailing list netmod@ietf.org <mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] NMDA System controlled resource
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. If for some leaf, there is no configuration , then apply system configuration . Is my understanding correct ? With Regards, Rohit R Ranade From: Robert Wilton [mailto:rwil...@cisco.com] Sent: 17 May 2018 14:29 To: Rohit R Ranade <rohitrran...@huawei.com>; netmod@ietf.org Subject: Re: [netmod] NMDA System controlled resource Hi Rohit, Section 5.3.2 states that you allowed to have configuration in / 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 ) for those interfaces. It also states that if there also happens to be configuration in / for those interfaces then that configuration will also get applied as those interfaces as instantiated in . All of the configuration that has been successfully applied would also appear in . 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 when it appears, the system will try to apply the configuration; this causes the configuration to appear in eventually (if application of the configuration was successful). " Why does application of configuration for system-controlled resources depend on whether 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 ." With Regards, Rohit R Ranade ___ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] NMDA System controlled resource
Hi Rohit, Section 5.3.2 states that you allowed to have configuration in / 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 ) for those interfaces. It also states that if there also happens to be configuration in / for those interfaces then that configuration will also get applied as those interfaces as instantiated in . All of the configuration that has been successfully applied would also appear in . 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 when it appears, the system will try to apply the configuration; this causes the configuration to appear in eventually (if application of the configuration was successful). “ Why does application of configuration for system-controlled resources depend on whether 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 .” With Regards, Rohit R Ranade ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
