Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Hi Jimmy, On 11/12/2020 09:17, Dongjie (Jimmy) wrote: Hi Peter, -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Thursday, December 10, 2020 9:22 PM To: Dongjie (Jimmy) ; Acee Lindem (acee) ; lsr Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 Hi Jimmy, On 10/12/2020 13:02, Dongjie (Jimmy) wrote: In Flex-Algo draft, it says: "Application-specific Flex-Algorithm participation advertisements MAY be topology specific or MAY be topology independent, depending on the application itself." The preassumption of current IP Flex-Algo participation is that one node always participate in a Flex-Algo for both IPv4 and IPv6, and for all the topologies it joins. I'm not saying this does not work, just want to understand the reason of this design, and whether some flexibility (e.g. AF specific or topology specific) would be useful in some cases. this was the choice of authors, because there does not seem to be a string reason to do it per topology. BTW, a similar case is about SR-MPLS and SRv6 being treated as a single application. Below is the discussion quoted from a previous mail on this list: [Jie] OK. While the meaning of "app" here maybe a little vague, are SR-MPLS and SRv6 considered the same or different apps? [Peter] These are considered as single app, and share the same participation signaling. Please note that SRv6 support is signaled independently of FA participation. Does this imply that for Flex-Algo path computation with SRv6, in addition to the Flex-Algo participation information, the SRv6 support information of nodes also needs to be considered, so that nodes participate in this Flex-Algo but do not support SRv6 will be pruned from the topology? no. Let me elaborate with an example: 20 20 A--B---C 10 | 10 |/ || / 10 D--E --* 10 (The metrics on the links are delay metric) - Flex-Algo 128 is defined to use delay metric for computation. This FAD is application independent, thus can be used by all applications. - All of the nodes (A, B, C, D, E) participate in FA 128. - Node A, B, C, D support both SR-MPLS and SRv6. - Node E support SR-MPLS only, it may support IPv6. Then node A computes the path to node C with FA 128. According to the computation rules of FA 128, the path would be A-D-E-C. This path can be used to send SR-MPLS packet to node C. But if node A sends SRv6 packets with node C's SRv6 SID in FA 128 as the destination address, when the packet arrives at E, it will be dropped, because node E does not have the forwarding entry for C's SRv6 SID in FA 128. Do you think this is a problem? IMO this problem is due to the FA calculation is based on the combination of the constraints in FA definition, and the nodes' FA participation (which is app specific), while since SR-MPLS and SRv6 are treated as one single application, the difference in supporting SR-MPLS or SRv6 is not considered in FA calculation. This is why I asked whether the SRv6 support information also need be considered in FA calculation. To solve this problem, there are several options: Option 1: Define two different Flex-Algos for delay metric computation, one for SR-MPLS, the other one for SRv6. But this makes the FAD application dependent. Option 1 is the right one, given the way things are defined. And honestly I do not see a need to change it. Option 2: Include the SR-MPLS or SRv6 information in Flex-Algo participation, i.e. make SR-MPLS and SRv6 separate applications. Theoretically you can make SR MPLS and SRv6 a different applications using FA. Given the SR nature of both we intentionally kept them as a single app from FA perspective. Option 3: Also consider the SRv6 (or SR-MPLS) capability information in FA calculation. no. This is not being done for algo 0 either and it has nothing to do with FA. thanks, Peter Or do you have other options in mind? Best regards, Jie thanks, Peter If so, IMO this needs to be specified in the Flex-Algo draft. If not, please clarify how to prune the nodes which participate in the same Flex-Algo for SR-MPLS only? Thanks. Best regards, Jie ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Hi Peter, > -Original Message- > From: Peter Psenak [mailto:ppse...@cisco.com] > Sent: Thursday, December 10, 2020 9:22 PM > To: Dongjie (Jimmy) ; Acee Lindem (acee) > ; lsr > Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms > (Flex-Algorithm) > In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 > > Hi Jimmy, > > On 10/12/2020 13:02, Dongjie (Jimmy) wrote: > > In Flex-Algo draft, it says: > > > > "Application-specific Flex-Algorithm participation advertisements MAY be > topology specific or MAY be topology independent, depending on the > application itself." > > > > The preassumption of current IP Flex-Algo participation is that one node > always participate in a Flex-Algo for both IPv4 and IPv6, and for all the > topologies it joins. > > > > I'm not saying this does not work, just want to understand the reason of > > this > design, and whether some flexibility (e.g. AF specific or topology specific) > would > be useful in some cases. > > > > this was the choice of authors, because there does not seem to be a string > reason to do it per topology. > > > > BTW, a similar case is about SR-MPLS and SRv6 being treated as a single > application. Below is the discussion quoted from a previous mail on this list: > > > >[Jie] OK. While the meaning of "app" here maybe a little vague, are > SR-MPLS and SRv6 considered the same or different apps? > > > >[Peter] These are considered as single app, and share the same > participation signaling. Please note that SRv6 support is signaled > independently > of FA participation. > > > > Does this imply that for Flex-Algo path computation with SRv6, in addition > > to > the Flex-Algo participation information, the SRv6 support information of nodes > also needs to be considered, so that nodes participate in this Flex-Algo but > do > not support SRv6 will be pruned from the topology? > > no. Let me elaborate with an example: 20 20 A--B---C 10 | 10 |/ || / 10 D--E --* 10 (The metrics on the links are delay metric) - Flex-Algo 128 is defined to use delay metric for computation. This FAD is application independent, thus can be used by all applications. - All of the nodes (A, B, C, D, E) participate in FA 128. - Node A, B, C, D support both SR-MPLS and SRv6. - Node E support SR-MPLS only, it may support IPv6. Then node A computes the path to node C with FA 128. According to the computation rules of FA 128, the path would be A-D-E-C. This path can be used to send SR-MPLS packet to node C. But if node A sends SRv6 packets with node C's SRv6 SID in FA 128 as the destination address, when the packet arrives at E, it will be dropped, because node E does not have the forwarding entry for C's SRv6 SID in FA 128. Do you think this is a problem? IMO this problem is due to the FA calculation is based on the combination of the constraints in FA definition, and the nodes' FA participation (which is app specific), while since SR-MPLS and SRv6 are treated as one single application, the difference in supporting SR-MPLS or SRv6 is not considered in FA calculation. This is why I asked whether the SRv6 support information also need be considered in FA calculation. To solve this problem, there are several options: Option 1: Define two different Flex-Algos for delay metric computation, one for SR-MPLS, the other one for SRv6. But this makes the FAD application dependent. Option 2: Include the SR-MPLS or SRv6 information in Flex-Algo participation, i.e. make SR-MPLS and SRv6 separate applications. Option 3: Also consider the SRv6 (or SR-MPLS) capability information in FA calculation. Or do you have other options in mind? Best regards, Jie > thanks, > Peter > > > > If so, IMO this needs to be specified in the Flex-Algo draft. If not, please > clarify how to prune the nodes which participate in the same Flex-Algo for > SR-MPLS only? Thanks. > > > > Best regards, > > Jie ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Hi Peter: Following this approach, IP and SR Flex-Algo can also be distinguished by using different FA IDs, thus there is no need to treat them as separate applications, and the existing SR FAD TLV can be reused? My suggestion is to have a clear and consistent rule in FA participation, either defining application-specific FA partifcipation for each data plane (IPv4, IPv6, SR-MPLS, SRv6, etc.), or do not define any applications and simply use different FA IDs to distinguish them. Thanks ZHibo -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak Sent: Friday, December 11, 2020 5:13 PM To: Dongjie (Jimmy) ; Acee Lindem (acee) ; lsr Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 Hi Jimmy, On 11/12/2020 09:17, Dongjie (Jimmy) wrote: > Hi Peter, > >> -Original Message- >> From: Peter Psenak [mailto:ppse...@cisco.com] >> Sent: Thursday, December 10, 2020 9:22 PM >> To: Dongjie (Jimmy) ; Acee Lindem (acee) >> ; lsr >> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms >> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 >> >> Hi Jimmy, >> >> On 10/12/2020 13:02, Dongjie (Jimmy) wrote: >>> In Flex-Algo draft, it says: >>> >>> "Application-specific Flex-Algorithm participation advertisements >>> MAY be >> topology specific or MAY be topology independent, depending on the >> application itself." >>> >>> The preassumption of current IP Flex-Algo participation is that one >>> node >> always participate in a Flex-Algo for both IPv4 and IPv6, and for all >> the topologies it joins. >>> >>> I'm not saying this does not work, just want to understand the >>> reason of this >> design, and whether some flexibility (e.g. AF specific or topology >> specific) would be useful in some cases. >>> >> >> this was the choice of authors, because there does not seem to be a >> string reason to do it per topology. >> >> >>> BTW, a similar case is about SR-MPLS and SRv6 being treated as a >>> single >> application. Below is the discussion quoted from a previous mail on this >> list: >>> >>> [Jie] OK. While the meaning of "app" here maybe a little vague, >>> are >> SR-MPLS and SRv6 considered the same or different apps? >>> >>> [Peter] These are considered as single app, and share the same >> participation signaling. Please note that SRv6 support is signaled >> independently of FA participation. >>> >>> Does this imply that for Flex-Algo path computation with SRv6, in >>> addition to >> the Flex-Algo participation information, the SRv6 support information >> of nodes also needs to be considered, so that nodes participate in >> this Flex-Algo but do not support SRv6 will be pruned from the topology? >> >> no. > > Let me elaborate with an example: > >20 20 > A--B---C > 10 | 10 |/ > || / 10 > D--E --* >10 > > (The metrics on the links are delay metric) > > - Flex-Algo 128 is defined to use delay metric for computation. This FAD is > application independent, thus can be used by all applications. > > - All of the nodes (A, B, C, D, E) participate in FA 128. > > - Node A, B, C, D support both SR-MPLS and SRv6. > > - Node E support SR-MPLS only, it may support IPv6. > > Then node A computes the path to node C with FA 128. According to the > computation rules of FA 128, the path would be A-D-E-C. This path can be used > to send SR-MPLS packet to node C. > > But if node A sends SRv6 packets with node C's SRv6 SID in FA 128 as the > destination address, when the packet arrives at E, it will be dropped, > because node E does not have the forwarding entry for C's SRv6 SID in FA 128. > > Do you think this is a problem? > > IMO this problem is due to the FA calculation is based on the combination of > the constraints in FA definition, and the nodes' FA participation (which is > app specific), while since SR-MPLS and SRv6 are treated as one single > application, the difference in supporting SR-MPLS or SRv6 is not considered > in FA calculation. This is why I asked whether the SRv6 support information > also need be considered in FA calculation. > > To solve this problem, there are several options: > > Option 1: Define two different Flex-Algos for delay metric computation, one > for SR-MPLS, the other one for SRv6. But this makes the FAD application > dependent. Option 1 is the right one, given the way things are defined. And honestly I do not see a need to change it. > Option 2: Include the SR-MPLS or SRv6 information in Flex-Algo participation, > i.e. make SR-MPLS and SRv6 separate applications. Theoretically you can make SR MPLS and SRv6 a different applications using FA. Given the SR nature of both we intentionally kept them as a single app from FA perspective. > Option 3: Also consider the SRv6 (or SR-MPLS) capability information in FA > calculation. no.
Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Hi Jie, > But if node A sends SRv6 packets with node C's SRv6 SID in FA 128 as the > destination address, when the packet arrives at E, it will be dropped, > because node E does not have the forwarding entry for C's SRv6 SID in FA > 128. * How can E be on the SRv6 SID list if it did not advertise SRv6 participation in the first place ? * What do you mean by "SRv6 SID in FA 128" ? Aren't SIDs global and not per FA ? Btw this is good discussion but how is this related to IP Flex Algo topic/draft ? Last - I do share your concern on how topology computation can be data plane independent. Yes it works for IP Flex Algo when IPv4 and IPv6 are topologically congruent, but when you add running SR on subset of nodes to the mix it is no longer the case. Thx, R. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Hi peter: As you said, IGP does not distinguish between IP and SR when calculating Algo 0. Why does Flexalgo distinguish between IP and SR Flexalgo? I think you're trying to explain these differences in a ambivalent way. Thanks Zhibo -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Friday, December 11, 2020 5:59 PM To: Huzhibo ; Dongjie (Jimmy) ; Acee Lindem (acee) ; lsr Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 Zhibo, On 11/12/2020 10:39, Huzhibo wrote: > Hi Peter: > > Following this approach, IP and SR Flex-Algo can also be distinguished > by using different FA IDs, thus there is no need to treat them as > separate applications, and the existing SR FAD TLV can be reused? > My > suggestion is to have a clear and consistent rule in FA participation, either defining application-specific FA partifcipation for each data plane (IPv4, IPv6, SR-MPLS, SRv6, etc.), or do not define any applications and simply use different FA IDs to distinguish them. you are mixing data plane consistency with FA participation. Data plane consistency is NOT done in IGPs for regular algo 0 calculation either. If you add non MPLS capable router in a middle of your MPLS network your data path is broken and IGPs are not going to help you to find an alternate path avoiding non MPLS capable router. I see no reason to do anything extra in FA case to avoid it. We have defined SR and IP as different applications for FA for good reason. Participation for IP and SR is signaled independently. I see no reason to do the same for every possible data plane - FA is not a data plane consistency check tool - same way as regular IGPs are not the one for algo 0. thanks, Peter > > Thanks > ZHibo > -Original Message- > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak > Sent: Friday, December 11, 2020 5:13 PM > To: Dongjie (Jimmy) ; Acee Lindem (acee) > ; lsr > Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms > (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 > > Hi Jimmy, > > On 11/12/2020 09:17, Dongjie (Jimmy) wrote: >> Hi Peter, >> >>> -Original Message- >>> From: Peter Psenak [mailto:ppse...@cisco.com] >>> Sent: Thursday, December 10, 2020 9:22 PM >>> To: Dongjie (Jimmy) ; Acee Lindem (acee) >>> ; lsr >>> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms >>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 >>> >>> Hi Jimmy, >>> >>> On 10/12/2020 13:02, Dongjie (Jimmy) wrote: In Flex-Algo draft, it says: "Application-specific Flex-Algorithm participation advertisements MAY be >>> topology specific or MAY be topology independent, depending on the >>> application itself." The preassumption of current IP Flex-Algo participation is that one node >>> always participate in a Flex-Algo for both IPv4 and IPv6, and for >>> all the topologies it joins. I'm not saying this does not work, just want to understand the reason of this >>> design, and whether some flexibility (e.g. AF specific or topology >>> specific) would be useful in some cases. >>> >>> this was the choice of authors, because there does not seem to be a >>> string reason to do it per topology. >>> >>> BTW, a similar case is about SR-MPLS and SRv6 being treated as a single >>> application. Below is the discussion quoted from a previous mail on this >>> list: [Jie] OK. While the meaning of "app" here maybe a little vague, are >>> SR-MPLS and SRv6 considered the same or different apps? [Peter] These are considered as single app, and share the same >>> participation signaling. Please note that SRv6 support is signaled >>> independently of FA participation. Does this imply that for Flex-Algo path computation with SRv6, in addition to >>> the Flex-Algo participation information, the SRv6 support >>> information of nodes also needs to be considered, so that nodes >>> participate in this Flex-Algo but do not support SRv6 will be pruned from >>> the topology? >>> >>> no. >> >> Let me elaborate with an example: >> >> 20 20 >> A--B---C >>10 | 10 |/ >> || / 10 >> D--E --* >> 10 >> >> (The metrics on the links are delay metric) >> >> - Flex-Algo 128 is defined to use delay metric for computation. This FAD is >> application independent, thus can be used by all applications. >> >> - All of the nodes (A, B, C, D, E) participate in FA 128. >> >> - Node A, B, C, D support both SR-MPLS and SRv6. >> >> - Node E support SR-MPLS only, it may support IPv6. >> >> Then node A computes the path to node C with FA 128. According to the >> computation rules of FA 128, the path would be A-D-E-C. This path can be >> used to send SR-MPLS packet to node C. >> >> But if node A
Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Hi peter: If you think that IP and SR are two applications, which application-specific link attributes should IP flexalgo use? Thanks Zhibo -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Friday, December 11, 2020 6:11 PM To: Huzhibo ; Dongjie (Jimmy) ; Acee Lindem (acee) ; lsr Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 Zhibo, On 11/12/2020 11:06, Huzhibo wrote: > Hi peter: > > As you said, IGP does not distinguish between IP and SR when calculating > Algo 0. Why does Flexalgo distinguish between IP and SR Flexalgo? I think > you're trying to explain these differences in a ambivalent way. because FA has the concept of application and participation. That is however not equal to dataplane type. thanks, Peter > > > Thanks > Zhibo > -Original Message- > From: Peter Psenak [mailto:ppse...@cisco.com] > Sent: Friday, December 11, 2020 5:59 PM > To: Huzhibo ; Dongjie (Jimmy) > ; Acee Lindem (acee) ; lsr > > Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms > (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 > > Zhibo, > > On 11/12/2020 10:39, Huzhibo wrote: >> Hi Peter: >> >> Following this approach, IP and SR Flex-Algo can also be >> distinguished by using different FA IDs, thus there is no need to >> treat them as separate applications, and the existing SR FAD TLV can >> be reused? > My suggestion is to have a clear and consistent rule in >> FA > participation, either defining application-specific FA partifcipation for > each data plane (IPv4, IPv6, SR-MPLS, SRv6, etc.), or do not define any > applications and simply use different FA IDs to distinguish them. > > you are mixing data plane consistency with FA participation. Data plane > consistency is NOT done in IGPs for regular algo 0 calculation either. > If you add non MPLS capable router in a middle of your MPLS network your data > path is broken and IGPs are not going to help you to find an alternate path > avoiding non MPLS capable router. I see no reason to do anything extra in FA > case to avoid it. > > We have defined SR and IP as different applications for FA for good reason. > Participation for IP and SR is signaled independently. I see no reason to do > the same for every possible data plane - FA is not a data plane consistency > check tool - same way as regular IGPs are not the one for algo 0. > > thanks, > Peter > > >> >> Thanks >> ZHibo >> -Original Message- >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak >> Sent: Friday, December 11, 2020 5:13 PM >> To: Dongjie (Jimmy) ; Acee Lindem (acee) >> ; lsr >> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms >> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 >> >> Hi Jimmy, >> >> On 11/12/2020 09:17, Dongjie (Jimmy) wrote: >>> Hi Peter, >>> -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Thursday, December 10, 2020 9:22 PM To: Dongjie (Jimmy) ; Acee Lindem (acee) ; lsr Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 Hi Jimmy, On 10/12/2020 13:02, Dongjie (Jimmy) wrote: > In Flex-Algo draft, it says: > > "Application-specific Flex-Algorithm participation advertisements > MAY be topology specific or MAY be topology independent, depending on the application itself." > > The preassumption of current IP Flex-Algo participation is that > one node always participate in a Flex-Algo for both IPv4 and IPv6, and for all the topologies it joins. > > I'm not saying this does not work, just want to understand the > reason of this design, and whether some flexibility (e.g. AF specific or topology specific) would be useful in some cases. > this was the choice of authors, because there does not seem to be a string reason to do it per topology. > BTW, a similar case is about SR-MPLS and SRv6 being treated as a > single application. Below is the discussion quoted from a previous mail on this list: > > [Jie] OK. While the meaning of "app" here maybe a little > vague, are SR-MPLS and SRv6 considered the same or different apps? > > [Peter] These are considered as single app, and share the > same participation signaling. Please note that SRv6 support is signaled independently of FA participation. > > Does this imply that for Flex-Algo path computation with SRv6, in > addition to the Flex-Algo participation information, the SRv6 support information of nodes also needs to be considered, so that nodes participate in this Flex-Algo but do not support SRv6 will be pruned from
Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Zhibo, On 11/12/2020 10:39, Huzhibo wrote: Hi Peter: Following this approach, IP and SR Flex-Algo can also be distinguished by using different FA IDs, thus there is no need to treat them as separate applications, and the existing SR FAD TLV can be reused? > My suggestion is to have a clear and consistent rule in FA participation, either defining application-specific FA partifcipation for each data plane (IPv4, IPv6, SR-MPLS, SRv6, etc.), or do not define any applications and simply use different FA IDs to distinguish them. you are mixing data plane consistency with FA participation. Data plane consistency is NOT done in IGPs for regular algo 0 calculation either. If you add non MPLS capable router in a middle of your MPLS network your data path is broken and IGPs are not going to help you to find an alternate path avoiding non MPLS capable router. I see no reason to do anything extra in FA case to avoid it. We have defined SR and IP as different applications for FA for good reason. Participation for IP and SR is signaled independently. I see no reason to do the same for every possible data plane - FA is not a data plane consistency check tool - same way as regular IGPs are not the one for algo 0. thanks, Peter Thanks ZHibo -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak Sent: Friday, December 11, 2020 5:13 PM To: Dongjie (Jimmy) ; Acee Lindem (acee) ; lsr Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 Hi Jimmy, On 11/12/2020 09:17, Dongjie (Jimmy) wrote: Hi Peter, -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Thursday, December 10, 2020 9:22 PM To: Dongjie (Jimmy) ; Acee Lindem (acee) ; lsr Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 Hi Jimmy, On 10/12/2020 13:02, Dongjie (Jimmy) wrote: In Flex-Algo draft, it says: "Application-specific Flex-Algorithm participation advertisements MAY be topology specific or MAY be topology independent, depending on the application itself." The preassumption of current IP Flex-Algo participation is that one node always participate in a Flex-Algo for both IPv4 and IPv6, and for all the topologies it joins. I'm not saying this does not work, just want to understand the reason of this design, and whether some flexibility (e.g. AF specific or topology specific) would be useful in some cases. this was the choice of authors, because there does not seem to be a string reason to do it per topology. BTW, a similar case is about SR-MPLS and SRv6 being treated as a single application. Below is the discussion quoted from a previous mail on this list: [Jie] OK. While the meaning of "app" here maybe a little vague, are SR-MPLS and SRv6 considered the same or different apps? [Peter] These are considered as single app, and share the same participation signaling. Please note that SRv6 support is signaled independently of FA participation. Does this imply that for Flex-Algo path computation with SRv6, in addition to the Flex-Algo participation information, the SRv6 support information of nodes also needs to be considered, so that nodes participate in this Flex-Algo but do not support SRv6 will be pruned from the topology? no. Let me elaborate with an example: 20 20 A--B---C 10 | 10 |/ || / 10 D--E --* 10 (The metrics on the links are delay metric) - Flex-Algo 128 is defined to use delay metric for computation. This FAD is application independent, thus can be used by all applications. - All of the nodes (A, B, C, D, E) participate in FA 128. - Node A, B, C, D support both SR-MPLS and SRv6. - Node E support SR-MPLS only, it may support IPv6. Then node A computes the path to node C with FA 128. According to the computation rules of FA 128, the path would be A-D-E-C. This path can be used to send SR-MPLS packet to node C. But if node A sends SRv6 packets with node C's SRv6 SID in FA 128 as the destination address, when the packet arrives at E, it will be dropped, because node E does not have the forwarding entry for C's SRv6 SID in FA 128. Do you think this is a problem? IMO this problem is due to the FA calculation is based on the combination of the constraints in FA definition, and the nodes' FA participation (which is app specific), while since SR-MPLS and SRv6 are treated as one single application, the difference in supporting SR-MPLS or SRv6 is not considered in FA calculation. This is why I asked whether the SRv6 support information also need be considered in FA calculation. To solve this problem, there are several options: Option 1: Define two different Flex-Algos for delay metric computation, one for SR-MPLS, the other one for SRv6. But this makes the FAD application dependent.
Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Hi Robert, Please see inline: From: Robert Raszuk [mailto:rob...@raszuk.net] Sent: Friday, December 11, 2020 5:16 PM To: Dongjie (Jimmy) Cc: Peter Psenak ; Acee Lindem (acee) ; lsr Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 Hi Jie, But if node A sends SRv6 packets with node C's SRv6 SID in FA 128 as the destination address, when the packet arrives at E, it will be dropped, because node E does not have the forwarding entry for C's SRv6 SID in FA 128. * How can E be on the SRv6 SID list if it did not advertise SRv6 participation in the first place ? [Jie] In this case, there is no SID list in the packet, only node C’s SRv6 SID associated with FA 128 is carried in the destination IP field. While in node A’s (also D’s) FA computation, node E is on the lowest latency path to C. * What do you mean by "SRv6 SID in FA 128" ? Aren't SIDs global and not per FA ? [Jie] Yes the SRv6 SIDs are global. Node C will assign different SRv6 SIDs for each FA it participates in. here I mean node C’s SRv6 SID which is associated with FA 128. Btw this is good discussion but how is this related to IP Flex Algo topic/draft ? [Jie] This is about the rules of defining new applications for Flex-Algo. As I mentioned in previous mails, it is not quite clear to me why IP and SR are defined as different applications, while SR-MPLS and SRv6 are defined as one application, and IPv4 and IPv6 are defined as one application. There may be other applications in future. As Zhibo said, it is better to have a clear and consistent rule in the beginning. Last - I do share your concern on how topology computation can be data plane independent. Yes it works for IP Flex Algo when IPv4 and IPv6 are topologically congruent, but when you add running SR on subset of nodes to the mix it is no longer the case. [Jie] Agreed. Best regards, Jie Thx, R. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Zhibo, On 11/12/2020 11:06, Huzhibo wrote: Hi peter: As you said, IGP does not distinguish between IP and SR when calculating Algo 0. Why does Flexalgo distinguish between IP and SR Flexalgo? I think you're trying to explain these differences in a ambivalent way. because FA has the concept of application and participation. That is however not equal to dataplane type. thanks, Peter Thanks Zhibo -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Friday, December 11, 2020 5:59 PM To: Huzhibo ; Dongjie (Jimmy) ; Acee Lindem (acee) ; lsr Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 Zhibo, On 11/12/2020 10:39, Huzhibo wrote: Hi Peter: Following this approach, IP and SR Flex-Algo can also be distinguished by using different FA IDs, thus there is no need to treat them as separate applications, and the existing SR FAD TLV can be reused? > My suggestion is to have a clear and consistent rule in FA participation, either defining application-specific FA partifcipation for each data plane (IPv4, IPv6, SR-MPLS, SRv6, etc.), or do not define any applications and simply use different FA IDs to distinguish them. you are mixing data plane consistency with FA participation. Data plane consistency is NOT done in IGPs for regular algo 0 calculation either. If you add non MPLS capable router in a middle of your MPLS network your data path is broken and IGPs are not going to help you to find an alternate path avoiding non MPLS capable router. I see no reason to do anything extra in FA case to avoid it. We have defined SR and IP as different applications for FA for good reason. Participation for IP and SR is signaled independently. I see no reason to do the same for every possible data plane - FA is not a data plane consistency check tool - same way as regular IGPs are not the one for algo 0. thanks, Peter Thanks ZHibo -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak Sent: Friday, December 11, 2020 5:13 PM To: Dongjie (Jimmy) ; Acee Lindem (acee) ; lsr Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 Hi Jimmy, On 11/12/2020 09:17, Dongjie (Jimmy) wrote: Hi Peter, -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Thursday, December 10, 2020 9:22 PM To: Dongjie (Jimmy) ; Acee Lindem (acee) ; lsr Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 Hi Jimmy, On 10/12/2020 13:02, Dongjie (Jimmy) wrote: In Flex-Algo draft, it says: "Application-specific Flex-Algorithm participation advertisements MAY be topology specific or MAY be topology independent, depending on the application itself." The preassumption of current IP Flex-Algo participation is that one node always participate in a Flex-Algo for both IPv4 and IPv6, and for all the topologies it joins. I'm not saying this does not work, just want to understand the reason of this design, and whether some flexibility (e.g. AF specific or topology specific) would be useful in some cases. this was the choice of authors, because there does not seem to be a string reason to do it per topology. BTW, a similar case is about SR-MPLS and SRv6 being treated as a single application. Below is the discussion quoted from a previous mail on this list: [Jie] OK. While the meaning of "app" here maybe a little vague, are SR-MPLS and SRv6 considered the same or different apps? [Peter] These are considered as single app, and share the same participation signaling. Please note that SRv6 support is signaled independently of FA participation. Does this imply that for Flex-Algo path computation with SRv6, in addition to the Flex-Algo participation information, the SRv6 support information of nodes also needs to be considered, so that nodes participate in this Flex-Algo but do not support SRv6 will be pruned from the topology? no. Let me elaborate with an example: 20 20 A--B---C 10 | 10 |/ || / 10 D--E --* 10 (The metrics on the links are delay metric) - Flex-Algo 128 is defined to use delay metric for computation. This FAD is application independent, thus can be used by all applications. - All of the nodes (A, B, C, D, E) participate in FA 128. - Node A, B, C, D support both SR-MPLS and SRv6. - Node E support SR-MPLS only, it may support IPv6. Then node A computes the path to node C with FA 128. According to the computation rules of FA 128, the path would be A-D-E-C. This path can be used to send SR-MPLS packet to node C. But if node A sends SRv6 packets with node C's SRv6 SID in FA 128 as the destination address, when the packet arrives at E, it will be dropped, because node E does not
Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Zhibo, Hi peter: If you think that IP and SR are two applications, which application-specific link attributes should IP flexalgo use? there are two sets: a) applications that are using the flex-algo - e.g. SR, IP. These apps are advertising participation in FA. b) application link attributes - application is "flex-algo" itself. These two are independent. Flex-algo ASLA are used for all apps in (a). thanks, Peter Thanks Zhibo -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Friday, December 11, 2020 6:11 PM To: Huzhibo ; Dongjie (Jimmy) ; Acee Lindem (acee) ; lsr Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 Zhibo, On 11/12/2020 11:06, Huzhibo wrote: Hi peter: As you said, IGP does not distinguish between IP and SR when calculating Algo 0. Why does Flexalgo distinguish between IP and SR Flexalgo? I think you're trying to explain these differences in a ambivalent way. because FA has the concept of application and participation. That is however not equal to dataplane type. thanks, Peter Thanks Zhibo -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Friday, December 11, 2020 5:59 PM To: Huzhibo ; Dongjie (Jimmy) ; Acee Lindem (acee) ; lsr Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 Zhibo, On 11/12/2020 10:39, Huzhibo wrote: Hi Peter: Following this approach, IP and SR Flex-Algo can also be distinguished by using different FA IDs, thus there is no need to treat them as separate applications, and the existing SR FAD TLV can be reused? > My suggestion is to have a clear and consistent rule in FA participation, either defining application-specific FA partifcipation for each data plane (IPv4, IPv6, SR-MPLS, SRv6, etc.), or do not define any applications and simply use different FA IDs to distinguish them. you are mixing data plane consistency with FA participation. Data plane consistency is NOT done in IGPs for regular algo 0 calculation either. If you add non MPLS capable router in a middle of your MPLS network your data path is broken and IGPs are not going to help you to find an alternate path avoiding non MPLS capable router. I see no reason to do anything extra in FA case to avoid it. We have defined SR and IP as different applications for FA for good reason. Participation for IP and SR is signaled independently. I see no reason to do the same for every possible data plane - FA is not a data plane consistency check tool - same way as regular IGPs are not the one for algo 0. thanks, Peter Thanks ZHibo -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak Sent: Friday, December 11, 2020 5:13 PM To: Dongjie (Jimmy) ; Acee Lindem (acee) ; lsr Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 Hi Jimmy, On 11/12/2020 09:17, Dongjie (Jimmy) wrote: Hi Peter, -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Thursday, December 10, 2020 9:22 PM To: Dongjie (Jimmy) ; Acee Lindem (acee) ; lsr Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 Hi Jimmy, On 10/12/2020 13:02, Dongjie (Jimmy) wrote: In Flex-Algo draft, it says: "Application-specific Flex-Algorithm participation advertisements MAY be topology specific or MAY be topology independent, depending on the application itself." The preassumption of current IP Flex-Algo participation is that one node always participate in a Flex-Algo for both IPv4 and IPv6, and for all the topologies it joins. I'm not saying this does not work, just want to understand the reason of this design, and whether some flexibility (e.g. AF specific or topology specific) would be useful in some cases. this was the choice of authors, because there does not seem to be a string reason to do it per topology. BTW, a similar case is about SR-MPLS and SRv6 being treated as a single application. Below is the discussion quoted from a previous mail on this list: [Jie] OK. While the meaning of "app" here maybe a little vague, are SR-MPLS and SRv6 considered the same or different apps? [Peter] These are considered as single app, and share the same participation signaling. Please note that SRv6 support is signaled independently of FA participation. Does this imply that for Flex-Algo path computation with SRv6, in addition to the Flex-Algo participation information, the SRv6 support information of nodes also needs to be considered, so that nodes participate in this Flex-Algo but do not support SRv6 will be pruned from the topology? no. Let me elaborate with an example: 20 20 A--B---C 10 | 10 |
Re: [Lsr] Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo
Hey Eric, The Routing Directorate review is marked completed (giving that the comments were Nits): https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/reviewrequest/13840/ We are assuming that you are happy with Peter's responses to your comments. Thanks again for your review. Thanks, Acee On 10/19/20, 5:46 AM, "Lsr on behalf of Peter Psenak" wrote: Hi Eric, thanks for the review, please see inline: On 16/10/2020 20:48, Eric Gray wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and > sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. For more information about the Routing > Directorate, please see > https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir. > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-lsr-flex-algo-12.txt > > Reviewer: Eric Gray > > Review Date: 16 October, 2020 > > IETF LC End Date: Unknown > > Intended Status: Standards Track > > Summary: > > This document is well organized, relatively easy to read, and probably > ready for publication, but has one potential minor issue and a very > small number of NITs that might be considered prior to publication. > > Major Issues: > > None > > Minor Issues: > > The statement in section 15 (Backward Compatibility) - "This extension > brings no new backward compatibility issues" - seems somewhat flip. > > I suspect that a tiny bit of analysis would not hurt. > > The extensions in this draft are clearly intended to work in an > environment where routers that _do_not_ support these extensions are > also deployed, but apparently relies on configuration of those routers > that _do_ support the extensions to address this. > > That seems correct. > > From my reading of the draft (which I have not closely followed for its > entire development), while it introduces at least one new TLV, the OSPF > routing protocol has well defined handling for TLVs that are not > understood - hence the introduction of one or more new TLVs should not > present a problem in OSPF. > > Obviously Sub-TLVs of the new OSPF TLV type will not introduce > compatibility issues. > > I assume (but do not actually know) that a similar situation exists for > the new ISIS FAD Sub-TLV of the existing TLV Type 242 - i.e. - ISIS > presumably has well defined handling for sub-TLVs (of at least type 242) > that are not recognized. If so, than the new Sub-TLV types defined are > also not an issue. > > Shouldn't this section say something along these lines? I suspect that > it would be more helpful if verifying the content of the > "considerations" sections were not left as an exercise for the reader. What about the "Backward Compatibility" section to be updated to: "This extension brings no new backward compatibility issues. ISIS, OSPFv2 and OSPFv3 all have well defined handling of unrecognized TLVs and sub-TLVs, that allows the introduction of the new extensions, similar to those defined here, without introducing any interoperability problems." > > NITs: > > In the Introduction, the phrase "must often be replaced" seems very > slightly problematic (especially given this is a standards track RFC > wanna-be). Would it be better to say "is often replaced" instead? done. > > In section 17.1.2 and 17.2 - '... a "Interior Gateway ...' should > probably be '... an "Interior Gateway ..." in both cases. done. thanks, Peter > > -- > > Eric > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
