Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt
Hi Robert, We will add it to the draft. This will presumably also affect the l3-topo draft, to augment the –state with its own –state tree. You mention tooling that can automatically generate this. Can you please point me to such a tool? (If not, no problem, will update manually.) Will investigate use of grouping and uses statements. In that case the –state module could simply use the grouping defined in the NMDA-compliant module. Thanks --- Alex From: Robert Wilton [mailto:rwil...@cisco.com] Sent: Tuesday, June 27, 2017 2:50 AM To: Alexander Clemm; 'Xufeng Liu' ; i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt Hi Alex, If you need to represent learned topologies before NMDA compliant implementations are available then you need the extra -state module (i.e. a copy of the NMDA compatible I2RS topology module, but with name appended with -state and all nodes set as config false). This could be generated via tooling, put into github, or added in an appendix to the draft. Without this, then the existing I2RS topology module can only be used to represent configured topologies on non NMDA compliant implementations (specifically any implementations that don't expose the operational state datastore). For NMDA compliant implementations the network topology module in draft -13 works well. Thanks, Rob On 26/06/2017 18:52, Alexander Clemm wrote: Hi Rob, Inline , below Thanks --- Alex -- Forwarded message -- From: "Robert Wilton" > Date: Mon, Jun 26, 2017 at 1:53 AM -0700 Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt To: "Alexander Clemm" >, >, "'Nitin Bahadur'" >, "'Russ White'" >, "'Xufeng Liu'" >, >, "'Jan Medved (jmedved)'" >, >, "'Susan Hares'" >, "Kent Watsen" >, "Martin Bjorklund" > Hi Juergen, On 24/06/2017 14:17, Juergen Schoenwaelder wrote: > On Thu, Jun 22, 2017 at 11:44:00AM +0100, Robert Wilton wrote: >> Do you think that it would be useful if the draft also included the extra >> transient "-state" modules in an appendix (e.g. as per >> draft-dsdt-nmda-guidelines-01 section 2)? >> >> Specifically, I'm thinking to help make the topology module fully usable by >> modules that augment it (e.g. by the TE modules if/when they adopt the NMDA >> conventions), until NMDA implementations before widely available. >> > Rob, > > the less we have of those transient "-state" trees, the better it is. > For LMAP (in auth48) we did not do this. These extra "-state" trees > should ideally only be used in very rare cases, I think existing code > already works with a single tree (at least this is what I understood > from the OpenDaylight discussions). I completely agree with you in general, but for the topology module I think that the -state tree is required to represent topologies that exist but have not been configured (e.g. perhaps those learned from a dynamic routing protocol). Also copying Kent and Martin, since they were very both very involved in the discussions on the I2RS alias discussing the structure of the I2RS network topology module. My interpretation is from Xufeng was it is needed for the TE YANG modules, but if it turns out that it is not actually needed, then that is also good with me ;-) The need to represent topologies that are learned is certainly there. It is not exclusive to TE, and I would be surprised if TE YANG modules have an extra need for a separate state tree. Probably the best person to comment here is Xufeng, but it sounds to me, also per Juergen’s comments, that an extra state tree will _not_ be needed. Thanks, Rob > > /js > ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt
Xufeng, Thanks for the confirmation. That hadn't been clear from the previous emails. When you generate the "-state" modules, I would suggest that you also reuse and import any typedefs that you have in the original NMDA compliant module, rather than redefine them. That should make it easier for implementers, both now and in the future. Thanks, Rob On 27/06/2017 14:23, Xufeng Liu wrote: As Alex mentioned in another email, we have discussed and agreed on the plan to move forward with both I2RS topology model and TE topology model, by adding the “-state” module. We will do it as quickly as possible. Thanks, - Xufeng *From:*Robert Wilton [mailto:rwil...@cisco.com] *Sent:* Tuesday, June 27, 2017 5:50 AM *To:* Alexander Clemm; Xufeng Liu ; i2rs@ietf.org *Subject:* Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt Hi Alex, If you need to represent learned topologies before NMDA compliant implementations are available then you need the extra -state module (i.e. a copy of the NMDA compatible I2RS topology module, but with name appended with -state and all nodes set as config false). This could be generated via tooling, put into github, or added in an appendix to the draft. Without this, then the existing I2RS topology module can only be used to represent configured topologies on non NMDA compliant implementations (specifically any implementations that don't expose the operational state datastore). For NMDA compliant implementations the network topology module in draft -13 works well. Thanks, Rob On 26/06/2017 18:52, Alexander Clemm wrote: Hi Rob, Inline , below Thanks --- Alex -- Forwarded message -- From: "*Robert Wilton*" > Date: Mon, Jun 26, 2017 at 1:53 AM -0700 Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt To: "Alexander Clemm" >, >, "'Nitin Bahadur'" >, "'Russ White'" >, "'Xufeng Liu'" >, >, "'Jan Medved (jmedved)'" >, >, "'Susan Hares'" >, "Kent Watsen" >, "Martin Bjorklund" > Hi Juergen, On 24/06/2017 14:17, Juergen Schoenwaelder wrote: > On Thu, Jun 22, 2017 at 11:44:00AM +0100, Robert Wilton wrote: >> Do you think that it would be useful if the draft also included the extra >> transient "-state" modules in an appendix (e.g. as per >> draft-dsdt-nmda-guidelines-01 section 2)? >> >> Specifically, I'm thinking to help make the topology module fully usable by >> modules that augment it (e.g. by the TE modules if/when they adopt the NMDA >> conventions), until NMDA implementations before widely available. >> > Rob, > > the less we have of those transient "-state" trees, the better it is. > For LMAP (in auth48) we did not do this. These extra "-state" trees > should ideally only be used in very rare cases, I think existing code > already works with a single tree (at least this is what I understood > from the OpenDaylight discussions). I completely agree with you in general, but for the topology module I think that the -state tree is required to represent topologies that exist but have not been configured (e.g. perhaps those learned from a dynamic routing protocol). Also copying Kent and Martin, since they were very both very involved in the discussions on the I2RS alias discussing the structure of the I2RS network topology module. My interpretation is from Xufeng was it is needed for the TE YANG modules, but if it turns out that it is not actually needed, then that is also good with me ;-) The need to represent topologies that are learned is certainly there. It is not exclusive to TE, and I would be surprised if TE YANG modules have an extra need for a separate state tree. Probably the best person to comment here is Xufeng, but it sounds to me, also per Juergen’s comments, that an extra state tree will _/not/_ be needed. Thanks, Rob > > /js > ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt
As Alex mentioned in another email, we have discussed and agreed on the plan to move forward with both I2RS topology model and TE topology model, by adding the “-state” module. We will do it as quickly as possible. Thanks, - Xufeng From: Robert Wilton [mailto:rwil...@cisco.com] Sent: Tuesday, June 27, 2017 5:50 AM To: Alexander Clemm; Xufeng Liu ; i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt Hi Alex, If you need to represent learned topologies before NMDA compliant implementations are available then you need the extra -state module (i.e. a copy of the NMDA compatible I2RS topology module, but with name appended with -state and all nodes set as config false). This could be generated via tooling, put into github, or added in an appendix to the draft. Without this, then the existing I2RS topology module can only be used to represent configured topologies on non NMDA compliant implementations (specifically any implementations that don't expose the operational state datastore). For NMDA compliant implementations the network topology module in draft -13 works well. Thanks, Rob On 26/06/2017 18:52, Alexander Clemm wrote: Hi Rob, Inline , below Thanks --- Alex -- Forwarded message -- From: "Robert Wilton" > Date: Mon, Jun 26, 2017 at 1:53 AM -0700 Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt To: "Alexander Clemm" >, >, "'Nitin Bahadur'" >, "'Russ White'" >, "'Xufeng Liu'" >, >, "'Jan Medved (jmedved)'" >, >, "'Susan Hares'" >, "Kent Watsen" >, "Martin Bjorklund" > Hi Juergen, On 24/06/2017 14:17, Juergen Schoenwaelder wrote: > On Thu, Jun 22, 2017 at 11:44:00AM +0100, Robert Wilton wrote: >> Do you think that it would be useful if the draft also included the extra >> transient "-state" modules in an appendix (e.g. as per >> draft-dsdt-nmda-guidelines-01 section 2)? >> >> Specifically, I'm thinking to help make the topology module fully usable by >> modules that augment it (e.g. by the TE modules if/when they adopt the NMDA >> conventions), until NMDA implementations before widely available. >> > Rob, > > the less we have of those transient "-state" trees, the better it is. > For LMAP (in auth48) we did not do this. These extra "-state" trees > should ideally only be used in very rare cases, I think existing code > already works with a single tree (at least this is what I understood > from the OpenDaylight discussions). I completely agree with you in general, but for the topology module I think that the -state tree is required to represent topologies that exist but have not been configured (e.g. perhaps those learned from a dynamic routing protocol). Also copying Kent and Martin, since they were very both very involved in the discussions on the I2RS alias discussing the structure of the I2RS network topology module. My interpretation is from Xufeng was it is needed for the TE YANG modules, but if it turns out that it is not actually needed, then that is also good with me ;-) The need to represent topologies that are learned is certainly there. It is not exclusive to TE, and I would be surprised if TE YANG modules have an extra need for a separate state tree. Probably the best person to comment here is Xufeng, but it sounds to me, also per Juergen’s comments, that an extra state tree will _not_ be needed. Thanks, Rob > > /js > ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt
Hi Alex, If you need to represent learned topologies before NMDA compliant implementations are available then you need the extra -state module (i.e. a copy of the NMDA compatible I2RS topology module, but with name appended with -state and all nodes set as config false). This could be generated via tooling, put into github, or added in an appendix to the draft. Without this, then the existing I2RS topology module can only be used to represent configured topologies on non NMDA compliant implementations (specifically any implementations that don't expose the operational state datastore). For NMDA compliant implementations the network topology module in draft -13 works well. Thanks, Rob On 26/06/2017 18:52, Alexander Clemm wrote: Hi Rob, Inline , below Thanks --- Alex -- Forwarded message -- From: "*Robert Wilton*"> Date: Mon, Jun 26, 2017 at 1:53 AM -0700 Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt To: "Alexander Clemm" >, >, "'Nitin Bahadur'" >, "'Russ White'" >, "'Xufeng Liu'" >, >, "'Jan Medved (jmedved)'" >, >, "'Susan Hares'" >, "Kent Watsen" >, "Martin Bjorklund" > Hi Juergen, On 24/06/2017 14:17, Juergen Schoenwaelder wrote: > On Thu, Jun 22, 2017 at 11:44:00AM +0100, Robert Wilton wrote: >> Do you think that it would be useful if the draft also included the extra >> transient "-state" modules in an appendix (e.g. as per >> draft-dsdt-nmda-guidelines-01 section 2)? >> >> Specifically, I'm thinking to help make the topology module fully usable by >> modules that augment it (e.g. by the TE modules if/when they adopt the NMDA >> conventions), until NMDA implementations before widely available. >> > Rob, > > the less we have of those transient "-state" trees, the better it is. > For LMAP (in auth48) we did not do this. These extra "-state" trees > should ideally only be used in very rare cases, I think existing code > already works with a single tree (at least this is what I understood > from the OpenDaylight discussions). I completely agree with you in general, but for the topology module I think that the -state tree is required to represent topologies that exist but have not been configured (e.g. perhaps those learned from a dynamic routing protocol). Also copying Kent and Martin, since they were very both very involved in the discussions on the I2RS alias discussing the structure of the I2RS network topology module. My interpretation is from Xufeng was it is needed for the TE YANG modules, but if it turns out that it is not actually needed, then that is also good with me ;-) The need to represent topologies that are learned is certainly there. It is not exclusive to TE, and I would be surprised if TE YANG modules have an extra need for a separate state tree. Probably the best person to comment here is Xufeng, but it sounds to me, also per Juergen’s comments, that an extra state tree will _/not/_ be needed. Thanks, Rob > > /js > ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs