Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Peter Psenak]

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 w

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Huzhibo]

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 
>

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Peter Psenak]

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 a

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Huzhibo]

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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Dongjie (Jimmy)]

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

[Peter Psenak]

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. B

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Huzhibo]

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 thi

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Robert Raszuk]

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

[Peter Psenak]

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

[Dongjie (Jimmy)]

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

[Duncan, Ian]

Hello -

I have read through the draft and support the WG adoption.

Best .. Ian


From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Tuesday, December 1, 2020 at 4:13 PM
To: lsr 
Subject: [**EXTERNAL**] [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee

___
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

[Peter Psenak]

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.

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

[Dongjie (Jimmy)]

Hi Peter, 

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Thursday, December 10, 2020 5:05 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 09:06, Dongjie (Jimmy) wrote:
> > Hi Peter,
> >
> >> -Original Message-
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Wednesday, December 9, 2020 9:06 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 09/12/2020 13:52, Dongjie (Jimmy) wrote:
> >>> Hi Peter,
> >>>
> >>>> -Original Message-----
> >>>> From: Peter Psenak [mailto:ppse...@cisco.com]
> >>>> Sent: Wednesday, December 9, 2020 6:45 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
> >>>>
> >>>> Jimmy,
> >>>>
> >>>> On 09/12/2020 11:10, Dongjie (Jimmy) wrote:
> >>>>> Hi authors,
> >>>>>
> >>>>> Here is one comment following the previous discussion on the mail
> >>>>> list and the IETF meeting.
> >>>>>
> >>>>> The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm
> >>>>> participation information, there is no separate TLV for IPv4 or
> >>>>> IPv6 Flex-Algo participation.
> >>>>
> >>>> the draft clearly says:
> >>>>
> >>>>   "The IP Flex-Algorithm participation advertised in ISIS IP 
> >>>> Algorithm
> >>>>   Sub-TLV is topology independent."
> >>>
> >>> This does not answer my question.
> >>>
> >>> Section 7 gives the rules of IP Flex-Algo Path calculation:
> >>>
> >>> " IP Flex-Algorithm application only considers participating nodes
> >>> during
> >> the Flex-Algorithm calculation.  When computing paths for a given
> >> Flex-Algorithm, all nodes that do not advertise participation for IP
> >> Flex-Algorithm, as described in Section 5, MUST be pruned from the
> >> topology."
> >>>
> >>> >From IP Algorithm TLV, one cannot tell whether a node participates
> >>> >in
> >>>> Flex-Algo 128 for IPv4, IPv6 or both. This would cause the problem
> >>>> described below: >
> >>> When one node uses IP Flex-Algo participation to compute a path for
> >>> an
> >> IPv6 address advertised with Flex-Algo 128, it will not prune the
> >> nodes which participate in Flex-Algo 128 for IPv4 only from the
> >> topology. Thus IPv6 packets following that path may get dropped on
> >> nodes which participates in Flex-Algo 128 for IPv4 only.
> >>
> >> FA calculation is done for every MT topology independently.
> >>
> >> For IPv4 it will take all routers participating in MT0 and run the FA
> >> calculation on top of MT0.
> >>
> >> For IPv6 it will take all routers participating in MT2 and run the FA
> >> calculation on top of MT2.
> >>
> >
> > Using different MTs for different data plane and run FA path computation
> within each MT may solve the problem in many cases.
> >
> > While the different rules related to FA definition, FA participation, and FA
> reachability advertisement still make me a little confused, and there may be
> some cases not covered by the above approach.
> >
> > - Flex-Algo definition is application independent and topology independent.
> >
> > - IP Flex-Algo participation is application specific and topology 
> > independent.
> >
> > - IPv4 and IPv6 are considered as one application, while may use different
> topologies.
> >
> > - IP Flex-Algo reachability advertisement is per AF, and may with different
> topologies.
> >
> > With the above rules, let's consider the case below:
> >
> > - A node participates in both MT 0 (for IPv4) and MT 2 (for IPv6).
> >

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Peter Psenak]

Hi Jimmy,

On 10/12/2020 09:06, Dongjie (Jimmy) wrote:

Hi Peter,


-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Wednesday, December 9, 2020 9:06 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 09/12/2020 13:52, Dongjie (Jimmy) wrote:

Hi Peter,


-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Wednesday, December 9, 2020 6:45 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

Jimmy,

On 09/12/2020 11:10, Dongjie (Jimmy) wrote:

Hi authors,

Here is one comment following the previous discussion on the mail
list and the IETF meeting.

The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm
participation information, there is no separate TLV for IPv4 or IPv6
Flex-Algo participation.


the draft clearly says:

  "The IP Flex-Algorithm participation advertised in ISIS IP Algorithm
  Sub-TLV is topology independent."


This does not answer my question.

Section 7 gives the rules of IP Flex-Algo Path calculation:

" IP Flex-Algorithm application only considers participating nodes during

the Flex-Algorithm calculation.  When computing paths for a given
Flex-Algorithm, all nodes that do not advertise participation for IP
Flex-Algorithm, as described in Section 5, MUST be pruned from the
topology."


>From IP Algorithm TLV, one cannot tell whether a node participates in

Flex-Algo 128 for IPv4, IPv6 or both. This would cause the problem
described below: >

When one node uses IP Flex-Algo participation to compute a path for an

IPv6 address advertised with Flex-Algo 128, it will not prune the nodes which
participate in Flex-Algo 128 for IPv4 only from the topology. Thus IPv6
packets following that path may get dropped on nodes which participates in
Flex-Algo 128 for IPv4 only.

FA calculation is done for every MT topology independently.

For IPv4 it will take all routers participating in MT0 and run the FA
calculation on top of MT0.

For IPv6 it will take all routers participating in MT2 and run the FA
calculation on top of MT2.



Using different MTs for different data plane and run FA path computation within 
each MT may solve the problem in many cases.

While the different rules related to FA definition, FA participation, and FA 
reachability advertisement still make me a little confused, and there may be 
some cases not covered by the above approach.

- Flex-Algo definition is application independent and topology independent.

- IP Flex-Algo participation is application specific and topology independent.

- IPv4 and IPv6 are considered as one application, while may use different 
topologies.

- IP Flex-Algo reachability advertisement is per AF, and may with different 
topologies.

With the above rules, let's consider the case below:

- A node participates in both MT 0 (for IPv4) and MT 2 (for IPv6).

- This node advertises its IP Flex-Algo participation of FA 128.

- This node advertises IPv4 Flex-Algo reachability with MT=0/FA=128.

- This node does NOT advertise IPv6 Flex-Algo reachability for FA 128. It may 
advertise normal IPv6 reachability in MT 2.

Thus this node is not reachable in MT 2 with FA 128. 


above is wrong.

The node participates in MT2 and FA 128, as such it is reachable in MT2 
in FA 128.



While it will be considered by other nodes for path computation in MT 2 with FA 
128.

The question is: will this node compute paths for other IPv6 prefixes 
advertised with MT=2/FA=128?


absolutely. It is participating in MT2 and FA 128. The fact that "does 
NOT advertise IPv6 Flex-Algo reachability" is completely irrelevant. It 
is NOT mandatory for a node to advertise the reachability for prefix in 
every MT/FA algo it participates.


Similarly it is not required for a node that participates in in MT0 to 
advetise any IPv4 prefix and IPv4 traffic will flow over it.




If not, this node may drop packets whose destination is IPv6 prefixes with FA 
128.

And do you think it is needed to provide approach to only consider this node 
for IPv4 path computation with FA 128, and prune it from IPv6 path computation 
with FA 128? For example, make the IP Flex-Algo participation per AF or per 
topology?


absolutely not.

thanks,
Peter




Best regards,
Jie




If some nodes participate in IPv4 Flex-Algo 128, and some of these
nodes participate in IPv6 Flex-Algo 128, how to ensure that the path
computed for IPv6 Flex-Algo will not use the nodes which only
participate in IPv4 Flex-Algo 128?


there is no such thing as "IPv4 Flex-Algo 128" or "IPv6 Flex-Algo 128".
There is only algo 128.


Agree that Flex-Algo 128 is application or data plane agnostic, and as we

discussed th

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Peter Psenak]

Zhenqiang,

On 10/12/2020 05:03, li_zhenqi...@hotmail.com wrote:

Hello Peter,

follow-up questions with [Zhenqiang].

FA calculation is done for every MT topology independently.
For IPv4 it will take all routers participating in MT0 and run the FA
calculation on top of MT0.
For IPv6 it will take all routers participating in MT2 and run the FA
calculation on top of MT2.

[Zhenqiang] Could you please elaborate this explicitly in the draft? For 
example, in section 7, replace the setence "IP Flex-Algorithm 
application only considers participating nodes during the Flex-Algorithm 
calculation" with "IP Flex-Algorithm application only considers 
participating nodes within the same MTID during the Flex-Algorithm 
calculation".


FA does not changing the way SPFs and route calculations are done for 
each MT. We are only adding FA constraints to existing MT calculations.


thanks,
Peter





[Zhenqiang]Since paths for IP flex-algo are calculated within specific 
MT, I think one new top-level TLV for ISIS is enough to advertise prefix 
reachability associated with a Flex-Algorithm, that is the one defined 
in section 6.1. MTID can be used to indicate it is for IPv4 or IPv6.


Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

*From:* Peter Psenak <mailto:ppsenak=40cisco@dmarc.ietf.org>
*Date:* 2020-12-09 21:05
*To:* Dongjie (Jimmy) <mailto:jie.d...@huawei.com>; Acee Lindem
(acee) <mailto:acee=40cisco@dmarc.ietf.org>; lsr
<mailto:lsr@ietf.org>
    *Subject:* Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
    (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Hi Jimmy,
On 09/12/2020 13:52, Dongjie (Jimmy) wrote:
 > Hi Peter,
 >
 >> -Original Message-
 >> From: Peter Psenak [mailto:ppse...@cisco.com]
 >> Sent: Wednesday, December 9, 2020 6:45 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
 >>
 >> Jimmy,
 >>
 >> On 09/12/2020 11:10, Dongjie (Jimmy) wrote:
 >>> Hi authors,
 >>>
 >>> Here is one comment following the previous discussion on the
mail list
 >>> and the IETF meeting.
 >>>
 >>> The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm
 >>> participation information, there is no separate TLV for IPv4 or
IPv6
 >>> Flex-Algo participation.
 >>
 >> the draft clearly says:
 >>
 >>  "The IP Flex-Algorithm participation advertised in ISIS IP
Algorithm
 >>  Sub-TLV is topology independent."
 >
 > This does not answer my question.
 >
 > Section 7 gives the rules of IP Flex-Algo Path calculation:
 >
 > " IP Flex-Algorithm application only considers participating
nodes during the Flex-Algorithm calculation.  When computing paths
for a given Flex-Algorithm, all nodes that do not advertise
participation for IP Flex-Algorithm, as described in Section 5, MUST
be pruned from the topology."
 >
 >>From IP Algorithm TLV, one cannot tell whether a node
participates in Flex-Algo 128 for IPv4, IPv6 or both. This would
cause the problem described below: >
 > When one node uses IP Flex-Algo participation to compute a path
for an IPv6 address advertised with Flex-Algo 128, it will not prune
the nodes which participate in Flex-Algo 128 for IPv4 only from the
topology. Thus IPv6 packets following that path may get dropped on
nodes which participates in Flex-Algo 128 for IPv4 only.
FA calculation is done for every MT topology independently.
For IPv4 it will take all routers participating in MT0 and run the FA
calculation on top of MT0.
For IPv6 it will take all routers participating in MT2 and run the FA
calculation on top of MT2.
 >
 >>
 >>> If some nodes participate in IPv4 Flex-Algo 128, and some of these
 >>> nodes participate in IPv6 Flex-Algo 128, how to ensure that the
path
 >>> computed for IPv6 Flex-Algo will not use the nodes which only
 >>> participate in IPv4 Flex-Algo 128?
 >>
 >> there is no such thing as "IPv4 Flex-Algo 128" or "IPv6
Flex-Algo 128".
 >> There is only algo 128.
 >
 > Agree that Flex-Algo 128 is application or data plane agnostic,
and as we discussed the same Flex-Algo can be used with both IPv4
and IPv6 (maybe also for SR-MPLS, SRv6). These te

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Dongjie (Jimmy)]

Hi Peter, 

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Wednesday, December 9, 2020 9:06 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 09/12/2020 13:52, Dongjie (Jimmy) wrote:
> > Hi Peter,
> >
> >> -Original Message-
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Wednesday, December 9, 2020 6:45 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
> >>
> >> Jimmy,
> >>
> >> On 09/12/2020 11:10, Dongjie (Jimmy) wrote:
> >>> Hi authors,
> >>>
> >>> Here is one comment following the previous discussion on the mail
> >>> list and the IETF meeting.
> >>>
> >>> The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm
> >>> participation information, there is no separate TLV for IPv4 or IPv6
> >>> Flex-Algo participation.
> >>
> >> the draft clearly says:
> >>
> >>  "The IP Flex-Algorithm participation advertised in ISIS IP Algorithm
> >>  Sub-TLV is topology independent."
> >
> > This does not answer my question.
> >
> > Section 7 gives the rules of IP Flex-Algo Path calculation:
> >
> > " IP Flex-Algorithm application only considers participating nodes during
> the Flex-Algorithm calculation.  When computing paths for a given
> Flex-Algorithm, all nodes that do not advertise participation for IP
> Flex-Algorithm, as described in Section 5, MUST be pruned from the
> topology."
> >
> >>From IP Algorithm TLV, one cannot tell whether a node participates in
> >>Flex-Algo 128 for IPv4, IPv6 or both. This would cause the problem
> >>described below: >
> > When one node uses IP Flex-Algo participation to compute a path for an
> IPv6 address advertised with Flex-Algo 128, it will not prune the nodes which
> participate in Flex-Algo 128 for IPv4 only from the topology. Thus IPv6
> packets following that path may get dropped on nodes which participates in
> Flex-Algo 128 for IPv4 only.
> 
> FA calculation is done for every MT topology independently.
> 
> For IPv4 it will take all routers participating in MT0 and run the FA
> calculation on top of MT0.
> 
> For IPv6 it will take all routers participating in MT2 and run the FA
> calculation on top of MT2.
> 

Using different MTs for different data plane and run FA path computation within 
each MT may solve the problem in many cases.

While the different rules related to FA definition, FA participation, and FA 
reachability advertisement still make me a little confused, and there may be 
some cases not covered by the above approach.

- Flex-Algo definition is application independent and topology independent.

- IP Flex-Algo participation is application specific and topology independent.

- IPv4 and IPv6 are considered as one application, while may use different 
topologies.

- IP Flex-Algo reachability advertisement is per AF, and may with different 
topologies.

With the above rules, let's consider the case below:

- A node participates in both MT 0 (for IPv4) and MT 2 (for IPv6).

- This node advertises its IP Flex-Algo participation of FA 128. 

- This node advertises IPv4 Flex-Algo reachability with MT=0/FA=128.

- This node does NOT advertise IPv6 Flex-Algo reachability for FA 128. It may 
advertise normal IPv6 reachability in MT 2. 

Thus this node is not reachable in MT 2 with FA 128. While it will be 
considered by other nodes for path computation in MT 2 with FA 128. 

The question is: will this node compute paths for other IPv6 prefixes 
advertised with MT=2/FA=128? 

If not, this node may drop packets whose destination is IPv6 prefixes with FA 
128. 

And do you think it is needed to provide approach to only consider this node 
for IPv4 path computation with FA 128, and prune it from IPv6 path computation 
with FA 128? For example, make the IP Flex-Algo participation per AF or per 
topology?

Best regards,
Jie

> >>
> >>> If some nodes participate in IPv4 Flex-Algo 128, and some of these
> >>> nodes participate in IPv6 Flex-Algo 128, how to ensure that the path
> >>> computed for IPv6 Flex-Algo will not use the nodes which only
> >>> participate in IPv4 Flex-Algo 128?
> >>
> >> there is no such thing as "IPv4 Flex-Algo 128" or "IPv6 Fl

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Les Ginsberg (ginsberg)]

Zhenqiang -

In regards to:


[Zhenqiang]Since paths for IP flex-algo are calculated within specific MT, I 
think one new top-level TLV for ISIS is enough to advertise prefix reachability 
associated with a Flex-Algorithm, that is the one defined in section 6.1. MTID 
can be used to indicate it is for IPv4 or IPv6.


You have misunderstood RFC 5120.
It is true that the reserved MTIDs defined in 
https://www.rfc-editor.org/rfc/rfc5120.html Section 7.5  are restricted to 
support only a single AFI/SAFI, but non-reserved MTIDs are NOT subject to this 
restriction. It is quite possible to use one of the unreserved MTIDs and 
support forwarding of both IPv4 and IPv6 address families on the topology 
associated with that MTID. Therefore, it is necessary to define AF specific 
TLVs. And that is why RFC 5120 did so and why this draft also must do so.

Draft authors -

https://tools.ietf.org/html/draft-bonica-lsr-ip-flexalgo-01#section-6.2 states:

"The ISIS IPv6 Algorithm Prefix Reachability TLV is identical to the
   ISIS IPv4 Algorithm Prefix Reachability TLV, except that it has a
   unique type."

But this is not completely accurate.
The existing Prefix Reachability TLVs for IPV4 (135, 235) and IPv6 (236, 237) 
have different flags formats.
See https://www.rfc-editor.org/rfc/rfc5305.html#section-4 and 
https://www.rfc-editor.org/rfc/rfc5308.html  Section 2 respectively.
And of course the legal ranges for prefix length are different.

I would expect these differences to be preserved in the new TLVs defined in 
this draft. It would therefore be better (and more accurate) if you replaced 
the above statement with a diagram for the new IPv6 TLV comparable to the one 
in Section 6.1.

Thanx.

   Les


From: Lsr  On Behalf Of li_zhenqi...@hotmail.com
Sent: Wednesday, December 09, 2020 8:04 PM
To: Peter Psenak ; 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

Hello Peter,

follow-up questions with [Zhenqiang].

FA calculation is done for every MT topology independently.
For IPv4 it will take all routers participating in MT0 and run the FA
calculation on top of MT0.
For IPv6 it will take all routers participating in MT2 and run the FA
calculation on top of MT2.

[Zhenqiang] Could you please elaborate this explicitly in the draft? For 
example, in section 7, replace the setence "IP Flex-Algorithm application only 
considers participating nodes during the Flex-Algorithm calculation" with "IP 
Flex-Algorithm application only considers participating nodes within the same 
MTID during the Flex-Algorithm calculation".

[Zhenqiang]Since paths for IP flex-algo are calculated within specific MT, I 
think one new top-level TLV for ISIS is enough to advertise prefix reachability 
associated with a Flex-Algorithm, that is the one defined in section 6.1. MTID 
can be used to indicate it is for IPv4 or IPv6.

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

From: Peter Psenak<mailto:ppsenak=40cisco@dmarc.ietf.org>
Date: 2020-12-09 21:05
To: Dongjie (Jimmy)<mailto:jie.d...@huawei.com>; Acee Lindem 
(acee)<mailto:acee=40cisco....@dmarc.ietf.org>; lsr<mailto:lsr@ietf.org>
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Hi Jimmy,

On 09/12/2020 13:52, Dongjie (Jimmy) wrote:
> Hi Peter,
>
>> -Original Message-
>> From: Peter Psenak [mailto:ppse...@cisco.com]
>> Sent: Wednesday, December 9, 2020 6:45 PM
>> To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Acee 
>> Lindem (acee)
>> mailto:acee=40cisco....@dmarc.ietf.org>>; 
>> lsr mailto:lsr@ietf.org>>
>> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>>
>> Jimmy,
>>
>> On 09/12/2020 11:10, Dongjie (Jimmy) wrote:
>>> Hi authors,
>>>
>>> Here is one comment following the previous discussion on the mail list
>>> and the IETF meeting.
>>>
>>> The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm
>>> participation information, there is no separate TLV for IPv4 or IPv6
>>> Flex-Algo participation.
>>
>> the draft clearly says:
>>
>>  "The IP Flex-Algorithm participation advertised in ISIS IP Algorithm
>>  Sub-TLV is topology independent."
>
> This does not answer my question.
>
> Section 7 gives the rules of IP Flex-Algo Path calculation:
>
> " IP Flex-Algorithm application only considers participating nodes during the 
> Flex-Algorithm calculation.  When computing pat

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[li_zhenqi...@hotmail.com]

Hello Peter,

follow-up questions with [Zhenqiang].

FA calculation is done for every MT topology independently. 
For IPv4 it will take all routers participating in MT0 and run the FA
calculation on top of MT0. 
For IPv6 it will take all routers participating in MT2 and run the FA
calculation on top of MT2.

[Zhenqiang] Could you please elaborate this explicitly in the draft? For 
example, in section 7, replace the setence "IP Flex-Algorithm application only 
considers participating nodes during the Flex-Algorithm calculation" with "IP 
Flex-Algorithm application only considers participating nodes within the same 
MTID during the Flex-Algorithm calculation".

[Zhenqiang]Since paths for IP flex-algo are calculated within specific MT, I 
think one new top-level TLV for ISIS is enough to advertise prefix reachability 
associated with a Flex-Algorithm, that is the one defined in section 6.1. MTID 
can be used to indicate it is for IPv4 or IPv6.

Best Regards,
Zhenqiang Li


li_zhenqi...@hotmail.com
 
From: Peter Psenak
Date: 2020-12-09 21:05
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 09/12/2020 13:52, Dongjie (Jimmy) wrote:
> Hi Peter,
> 
>> -Original Message-
>> From: Peter Psenak [mailto:ppse...@cisco.com]
>> Sent: Wednesday, December 9, 2020 6:45 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
>>
>> Jimmy,
>>
>> On 09/12/2020 11:10, Dongjie (Jimmy) wrote:
>>> Hi authors,
>>>
>>> Here is one comment following the previous discussion on the mail list
>>> and the IETF meeting.
>>>
>>> The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm
>>> participation information, there is no separate TLV for IPv4 or IPv6
>>> Flex-Algo participation.
>>
>> the draft clearly says:
>>
>>  "The IP Flex-Algorithm participation advertised in ISIS IP Algorithm
>>  Sub-TLV is topology independent."
> 
> This does not answer my question.
> 
> Section 7 gives the rules of IP Flex-Algo Path calculation:
> 
> " IP Flex-Algorithm application only considers participating nodes during the 
> Flex-Algorithm calculation.  When computing paths for a given Flex-Algorithm, 
> all nodes that do not advertise participation for IP Flex-Algorithm, as 
> described in Section 5, MUST be pruned from the topology."
> 
>>From IP Algorithm TLV, one cannot tell whether a node participates in 
>>Flex-Algo 128 for IPv4, IPv6 or both. This would cause the problem described 
>>below: >
> When one node uses IP Flex-Algo participation to compute a path for an IPv6 
> address advertised with Flex-Algo 128, it will not prune the nodes which 
> participate in Flex-Algo 128 for IPv4 only from the topology. Thus IPv6 
> packets following that path may get dropped on nodes which participates in 
> Flex-Algo 128 for IPv4 only.
 
FA calculation is done for every MT topology independently.
 
For IPv4 it will take all routers participating in MT0 and run the FA 
calculation on top of MT0.
 
For IPv6 it will take all routers participating in MT2 and run the FA 
calculation on top of MT2.
 
 
> 
>>
>>> If some nodes participate in IPv4 Flex-Algo 128, and some of these
>>> nodes participate in IPv6 Flex-Algo 128, how to ensure that the path
>>> computed for IPv6 Flex-Algo will not use the nodes which only
>>> participate in IPv4 Flex-Algo 128?
>>
>> there is no such thing as "IPv4 Flex-Algo 128" or "IPv6 Flex-Algo 128".
>> There is only algo 128.
> 
> Agree that Flex-Algo 128 is application or data plane agnostic, and as we 
> discussed the same Flex-Algo can be used with both IPv4 and IPv6 (maybe also 
> for SR-MPLS, SRv6). These terms are used as shorthand of "Flex-Algo 128 used 
> with IPv4 or IPv6"
> 
>> You are mixing data plane support with algo participation.
> 
> I understand Flex-Algo definition is application agnostic, and Flex-Algo 
> participation is application specific, it is just not clear to me whether 
> IPv4 and IPv6 can be treated as one application.
 
yes they can.
 
> 
>> If you want an algo to only include nodes that supports specific data plane,
>> you would need to define a specific algo for it.
> 
> This IMO contradicts with the base concept: Flex-Algo definition is 
> application (or data plane) agnostic.
 
not really, see above.
 
thanks,
Peter
 
> 
> Best regards,
> 

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[peng.shaofu]

Hi Peter,






Is it possible for a TI-LFA path, expressed as a native IP address list,  to be 
encoded in a Routing Header which is not necessarily Segment Routing Header, or 
to be encoded in LSRR option defined in RFC791 ?






Regards,


PSF














原始邮件



发件人：PeterPsenak
收件人：Huzhibo;Acee Lindem (acee);lsr;
日 期 ：2020年12月09日 20:44
主 题 ：Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01


Hi Zhibo,
 
On 09/12/2020 13:05, Huzhibo wrote:
> Hi Peter:
>  
>  If Ti-LFA can protect IP flexalgo, the native IP and SR must share the 
> same algorithm ID.
 
that is correct.
 
thanks,
Peter
>  
> thanks,
> Zhibo
>  
> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Wednesday, December 9, 2020 7:16 PM
> To: Huzhibo ; 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 09/12/2020 11:50, Huzhibo wrote:
>> Hi authors,
>> 
>> Here are some comments about IP flexalgo as follows:
>> 
>> 1.In Flex-Algo draft, there is description about using fast-rerouting
>> with Flex-Algo for SR-MPLS and SRv6 data plane. It is recommended that
>> similar text be added for IP Flex-Algo.
>  
> there is a similar text in section 8, but more work is required indeed.
>  
> One important note - TI-LFA requires some form of traffic steering. This can 
> be achieved by enabling both IP and SR flex-algo and use SR FA only to 
> protect IP FA, similar to protection of "unlabeled" traffic with SR MPLS. Or 
> some alternative mechanism for enforcing the traffic on the LFA path is 
> required.
>  
>> 
>> 2.Is Application-Specific Link Attribute (ASLA) MUST be used for IP
>> Flex-Algo path computation?
>  
> yes, the flex-algo application uses Flex-algo specific link attributes as 
> defined in base flex-algo draft.
>  
> thanks,
> Peter
>> 
>> Best regards,
>> 
>> Zhibo
>> 
>> *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem
>> (acee)
>> *Sent:* Wednesday, December 2, 2020 5:13 AM
>> *To:* lsr  
>> *Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms
>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>> 
>> This IP Flex Algorithm draft generated quite a bit of discussion on
>> use cases and deployment prior to IETF 109 and there was generally
>> support for WG adoption. This begins a two week WG adoption call.
>> Please indicate your support or objection to WG adoption on this list
>> prior to
>> 12:00 AM UTC on December 16^th , 2020. Also, review comments are
>> certainly welcome.
>> 
>> Thanks,
>> 
>> Acee
>> 
>  
>  
>  
 
___
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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Peter Psenak]

Hi Jimmy,

On 09/12/2020 13:52, Dongjie (Jimmy) wrote:

Hi Peter,


-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Wednesday, December 9, 2020 6:45 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

Jimmy,

On 09/12/2020 11:10, Dongjie (Jimmy) wrote:

Hi authors,

Here is one comment following the previous discussion on the mail list
and the IETF meeting.

The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm
participation information, there is no separate TLV for IPv4 or IPv6
Flex-Algo participation.


the draft clearly says:

 "The IP Flex-Algorithm participation advertised in ISIS IP Algorithm
 Sub-TLV is topology independent."


This does not answer my question.

Section 7 gives the rules of IP Flex-Algo Path calculation:

" IP Flex-Algorithm application only considers participating nodes during the 
Flex-Algorithm calculation.  When computing paths for a given Flex-Algorithm, all nodes 
that do not advertise participation for IP Flex-Algorithm, as described in Section 5, 
MUST be pruned from the topology."


From IP Algorithm TLV, one cannot tell whether a node participates in Flex-Algo 
128 for IPv4, IPv6 or both. This would cause the problem described below: >

When one node uses IP Flex-Algo participation to compute a path for an IPv6 
address advertised with Flex-Algo 128, it will not prune the nodes which 
participate in Flex-Algo 128 for IPv4 only from the topology. Thus IPv6 packets 
following that path may get dropped on nodes which participates in Flex-Algo 
128 for IPv4 only.


FA calculation is done for every MT topology independently.

For IPv4 it will take all routers participating in MT0 and run the FA 
calculation on top of MT0.


For IPv6 it will take all routers participating in MT2 and run the FA 
calculation on top of MT2.








If some nodes participate in IPv4 Flex-Algo 128, and some of these
nodes participate in IPv6 Flex-Algo 128, how to ensure that the path
computed for IPv6 Flex-Algo will not use the nodes which only
participate in IPv4 Flex-Algo 128?


there is no such thing as "IPv4 Flex-Algo 128" or "IPv6 Flex-Algo 128".
There is only algo 128.


Agree that Flex-Algo 128 is application or data plane agnostic, and as we discussed the 
same Flex-Algo can be used with both IPv4 and IPv6 (maybe also for SR-MPLS, SRv6). These 
terms are used as shorthand of "Flex-Algo 128 used with IPv4 or IPv6"


You are mixing data plane support with algo participation.


I understand Flex-Algo definition is application agnostic, and Flex-Algo 
participation is application specific, it is just not clear to me whether IPv4 
and IPv6 can be treated as one application.


yes they can.




If you want an algo to only include nodes that supports specific data plane,
you would need to define a specific algo for it.


This IMO contradicts with the base concept: Flex-Algo definition is application 
(or data plane) agnostic.


not really, see above.

thanks,
Peter



Best regards,
Jie



thanks,
Peter




Best regards,

Jie

*From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem
(acee)
*Sent:* Wednesday, December 2, 2020 5:13 AM
*To:* lsr 
*Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on
use cases and deployment prior to IETF 109 and there was generally
support for WG adoption. This begins a two week WG adoption call.
Please indicate your support or objection to WG adoption on this list
prior to
12:00 AM UTC on December 16^th , 2020. Also, review comments are
certainly welcome.

Thanks,

Acee







___
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

[Dongjie (Jimmy)]

Hi Parag,

Thanks for your reply. While perhaps I should make my comment clearer:

I agree a node which does not support a particular address family (e.g. IPv6) 
will not install route for that family. While according to the rules in section 
7, this node will be included in the topology for path computation of one 
Flex-Algo by another node, just because it advertises the participation to the 
same Flex-Algo for another address family (e.g. IPv4). In my understanding this 
would cause packet drop. Did I miss something?

Best regards,
Jie

From: Parag Kaneriya [mailto:pkane...@juniper.net]
Sent: Wednesday, December 9, 2020 6:46 PM
To: Dongjie (Jimmy) ; Acee Lindem (acee) 
; lsr 
Subject: RE: WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In 
IP Networks" - draft-bonica-lsr-ip-flexalgo-01

IP Algorithm SUBTLV indicate the participation for particular flex algo by 
node.  Participation doesn't depend on whether it support ipv4 prefix or ipv6 
prefix.  Node which doesn't support particular family will not install that 
family route.

Regards
Parag



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Dongjie (Jimmy)
Sent: Wednesday, December 9, 2020 3:40 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[External Email. Be cautious of content]

Hi authors,

Here is one comment following the previous discussion on the mail list and the 
IETF meeting.

The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm 
participation information, there is no separate TLV for IPv4 or IPv6 Flex-Algo 
participation. If some nodes participate in IPv4 Flex-Algo 128, and some of 
these nodes participate in IPv6 Flex-Algo 128, how to ensure that the path 
computed for IPv6 Flex-Algo will not use the nodes which only participate in 
IPv4 Flex-Algo 128?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr mailto:lsr@ietf.org>>
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee


___
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

[Peter Psenak]

Hi Zhibo,

On 09/12/2020 13:05, Huzhibo wrote:

Hi Peter:

 If Ti-LFA can protect IP flexalgo, the native IP and SR must share the 
same algorithm ID.


that is correct.

thanks,
Peter


thanks,
Zhibo

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Wednesday, December 9, 2020 7:16 PM
To: Huzhibo ; 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 09/12/2020 11:50, Huzhibo wrote:

Hi authors,

Here are some comments about IP flexalgo as follows:

1.In Flex-Algo draft, there is description about using fast-rerouting
with Flex-Algo for SR-MPLS and SRv6 data plane. It is recommended that
similar text be added for IP Flex-Algo.


there is a similar text in section 8, but more work is required indeed.

One important note - TI-LFA requires some form of traffic steering. This can be achieved 
by enabling both IP and SR flex-algo and use SR FA only to protect IP FA, similar to 
protection of "unlabeled" traffic with SR MPLS. Or some alternative mechanism 
for enforcing the traffic on the LFA path is required.



2.Is Application-Specific Link Attribute (ASLA) MUST be used for IP
Flex-Algo path computation?


yes, the flex-algo application uses Flex-algo specific link attributes as 
defined in base flex-algo draft.

thanks,
Peter


Best regards,

Zhibo

*From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem
(acee)
*Sent:* Wednesday, December 2, 2020 5:13 AM
*To:* lsr 
*Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on
use cases and deployment prior to IETF 109 and there was generally
support for WG adoption. This begins a two week WG adoption call.
Please indicate your support or objection to WG adoption on this list
prior to
12:00 AM UTC on December 16^th , 2020. Also, review comments are
certainly welcome.

Thanks,

Acee







___
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

[Huzhibo]

Hi Peter:

If Ti-LFA can protect IP flexalgo, the native IP and SR must share the same 
algorithm ID.

thanks,
Zhibo

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Wednesday, December 9, 2020 7:16 PM
To: Huzhibo ; 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 09/12/2020 11:50, Huzhibo wrote:
> Hi authors,
> 
> Here are some comments about IP flexalgo as follows:
> 
> 1.In Flex-Algo draft, there is description about using fast-rerouting 
> with Flex-Algo for SR-MPLS and SRv6 data plane. It is recommended that 
> similar text be added for IP Flex-Algo.

there is a similar text in section 8, but more work is required indeed.

One important note - TI-LFA requires some form of traffic steering. This can be 
achieved by enabling both IP and SR flex-algo and use SR FA only to protect IP 
FA, similar to protection of "unlabeled" traffic with SR MPLS. Or some 
alternative mechanism for enforcing the traffic on the LFA path is required.

> 
> 2.Is Application-Specific Link Attribute (ASLA) MUST be used for IP 
> Flex-Algo path computation?

yes, the flex-algo application uses Flex-algo specific link attributes as 
defined in base flex-algo draft.

thanks,
Peter
> 
> Best regards,
> 
> Zhibo
> 
> *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem 
> (acee)
> *Sent:* Wednesday, December 2, 2020 5:13 AM
> *To:* lsr 
> *Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms
> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
> 
> This IP Flex Algorithm draft generated quite a bit of discussion on 
> use cases and deployment prior to IETF 109 and there was generally 
> support for WG adoption. This begins a two week WG adoption call. 
> Please indicate your support or objection to WG adoption on this list 
> prior to
> 12:00 AM UTC on December 16^th , 2020. Also, review comments are 
> certainly welcome.
> 
> Thanks,
> 
> Acee
> 

___
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

[Peter Psenak]

Zhibo,

On 09/12/2020 11:50, Huzhibo wrote:

Hi authors,

Here are some comments about IP flexalgo as follows:

1.In Flex-Algo draft, there is description about using fast-rerouting 
with Flex-Algo for SR-MPLS and SRv6 data plane. It is recommended that 
similar text be added for IP Flex-Algo.


there is a similar text in section 8, but more work is required indeed.

One important note - TI-LFA requires some form of traffic steering. This 
can be achieved by enabling both IP and SR flex-algo and use SR FA only 
to protect IP FA, similar to protection of "unlabeled" traffic with SR 
MPLS. Or some alternative mechanism for enforcing the traffic on the LFA 
path is required.




2.Is Application-Specific Link Attribute (ASLA) MUST be used for IP 
Flex-Algo path computation?


yes, the flex-algo application uses Flex-algo specific link attributes 
as defined in base flex-algo draft.


thanks,
Peter


Best regards,

Zhibo

*From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem (acee)
*Sent:* Wednesday, December 2, 2020 5:13 AM
*To:* lsr 
*Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01


This IP Flex Algorithm draft generated quite a bit of discussion on use 
cases and deployment prior to IETF 109 and there was generally support 
for WG adoption. This begins a two week WG adoption call. Please 
indicate your support or objection to WG adoption on this list prior to 
12:00 AM UTC on December 16^th , 2020. Also, review comments are 
certainly welcome.


Thanks,

Acee



___
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

[Huzhibo]

Hi authors,

Here are some comments about IP flexalgo as follows:

1.   In Flex-Algo draft, there is description about using fast-rerouting 
with Flex-Algo for SR-MPLS and SRv6 data plane. It is recommended that similar 
text be added for IP Flex-Algo.

2.   Is Application-Specific Link Attribute (ASLA) MUST be used for IP 
Flex-Algo path computation?

Best regards,
Zhibo

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee


___
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

[Parag Kaneriya]

IP Algorithm SUBTLV indicate the participation for particular flex algo by 
node.  Participation doesn't depend on whether it support ipv4 prefix or ipv6 
prefix.  Node which doesn't support particular family will not install that 
family route.

Regards
Parag



Juniper Business Use Only
From: Lsr  On Behalf Of Dongjie (Jimmy)
Sent: Wednesday, December 9, 2020 3:40 PM
To: 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

[External Email. Be cautious of content]

Hi authors,

Here is one comment following the previous discussion on the mail list and the 
IETF meeting.

The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm 
participation information, there is no separate TLV for IPv4 or IPv6 Flex-Algo 
participation. If some nodes participate in IPv4 Flex-Algo 128, and some of 
these nodes participate in IPv6 Flex-Algo 128, how to ensure that the path 
computed for IPv6 Flex-Algo will not use the nodes which only participate in 
IPv4 Flex-Algo 128?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr mailto:lsr@ietf.org>>
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee


___
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

[Peter Psenak]

Jimmy,

On 09/12/2020 11:10, Dongjie (Jimmy) wrote:

Hi authors,

Here is one comment following the previous discussion on the mail list 
and the IETF meeting.


The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm 
participation information, there is no separate TLV for IPv4 or IPv6 
Flex-Algo participation. 


the draft clearly says:

   "The IP Flex-Algorithm participation advertised in ISIS IP Algorithm
   Sub-TLV is topology independent."


If some nodes participate in IPv4 Flex-Algo 
128, and some of these nodes participate in IPv6 Flex-Algo 128, how to 
ensure that the path computed for IPv6 Flex-Algo will not use the nodes 
which only participate in IPv4 Flex-Algo 128?


there is no such thing as "IPv4 Flex-Algo 128" or "IPv6 Flex-Algo 128". 
There is only algo 128.


You are mixing data plane support with algo participation.

If you want an algo to only include nodes that supports specific data 
plane, you would need to define a specific algo for it.


thanks,
Peter




Best regards,

Jie

*From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem (acee)
*Sent:* Wednesday, December 2, 2020 5:13 AM
*To:* lsr 
*Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01


This IP Flex Algorithm draft generated quite a bit of discussion on use 
cases and deployment prior to IETF 109 and there was generally support 
for WG adoption. This begins a two week WG adoption call. Please 
indicate your support or objection to WG adoption on this list prior to 
12:00 AM UTC on December 16^th , 2020. Also, review comments are 
certainly welcome.


Thanks,

Acee



___
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

[Dongjie (Jimmy)]

Hi authors,

Here is one comment following the previous discussion on the mail list and the 
IETF meeting.

The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm 
participation information, there is no separate TLV for IPv4 or IPv6 Flex-Algo 
participation. If some nodes participate in IPv4 Flex-Algo 128, and some of 
these nodes participate in IPv6 Flex-Algo 128, how to ensure that the path 
computed for IPv6 Flex-Algo will not use the nodes which only participate in 
IPv4 Flex-Algo 128?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee


___
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

[Jeff Tantsura]

Zhenqiang,

please see inline

Cheers,
Jeff


4. I want to know the path for a specific IP Flex-Algorithm is calculated 
distributedly by each nodes paticipating this Flex-Algorithm or calculated 
centralized by an controller? I wonder we can guarantee the loop free  path 
with IP Flex-Algorithm especially when the path is calculated distributedly?

The valid topology must consist of a set of connected routers sharing a common 
Calc-Type, then loop-free calculation is done accordingly


Best Regards,
Zhenqiang Li
li_zhenqi...@hotmail.com

From: Jeff Tantsura
Date: 2020-12-04 09:18
To: Tony Li; Robert Raszuk
CC: lsr; Acee Lindem \(acee\)
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Anything else than IGP metric based SPT is considered TE. Looking holistically 
- topology virtualization (or similar) could have been a better name.

Cheers,
Jeff
On Dec 3, 2020, 4:25 PM -0800, Robert Raszuk , wrote:
Hi Tony,

The moment I hit "Send" I knew that this response may be coming as it really 
depends what is one's definition of TE.

If indeed IGP TE is anything more then SPF - then sure we can call it a TE 
feature.

However, while a very useful and really cool proposal, my point is to make sure 
this is not oversold - that's all.

Best,
R.


> On Fri, Dec 4, 2020 at 1:13 AM Tony Li  wrote:
> >
> > Hi Robert,
> >
> >
> > > However I really do not think that what Flexible Algorithm offers can be 
> > > compared or even called as Traffic Engineering (MPLS or SR).
> > >
> > > Sure Flex Algo can accomplish in a very elegant way with little cost 
> > > multi topology routing but this is not full TE. It can also direct 
> > > traffic based on static or dynamic network preferences (link colors, rtt 
> > > drops etc ... ),  but again it is not taking into account load of the 
> > > entire network and IMHO has no way of accomplish TE level traffic 
> > > distribution.
> > >
> > > Just to make sure the message here is proper.
> >
> >
> > It’s absolutely true that FlexAlgo (IP or SR) has limitations. There’s no 
> > bandwidth reservation. There’s no dynamic load balancing. No, it’s not a 
> > drop in replacement for RSVP. No, it does not supplant SR-TE and a good 
> > controller. Etc., etc., etc….
> >
> > However I don’t feel that it’s fair to say that FlexAlgo can’t be called 
> > Traffic Engineering.  After all TE is a very broad topic. Everything that 
> > we’ve done that’s more sophisticated than simple SPF falls in the area of 
> > Traffic Engineering.  Link coloring and SRLG alone clearly fall into that 
> > bucket.
> >
> > I’ll grant you that it may not have the right TE features for your 
> > application, but that doesn’t mean that it’s not sufficient for some.  
> > Please don’t mislead people by saying that it’s not Traffic Engineering.
> >
> > Regards,
> > Tony
> >
> >
___
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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[slitkows.ietf]

Hi,

 

I support the WG adoption. This is a useful work.

 

Stephane

 

 

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: mardi 1 décembre 2020 22:13
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

 

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.

Thanks,

Acee

 

 

___
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

[Tony Li]

> Can't we associate multiple Flex-Algorithms with one
>> loopback address, which means we want to reach the loopback address through 
>> different paths?



Pragmatically, this is not a big deal. Most implementations allow many loopback 
interfaces, so this just costs a single /32 or /128.

Tony

___
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

[Peter Psenak]

Zhenqiang,

On 04/12/2020 05:26, li_zhenqi...@hotmail.com wrote:

Hello All,

I've read the draft and support its adoption. I have some comments as 
follows.


1. I agree with Jeff that Flex Algo represents a sub- topology 
consisting of the participating nodes, which we can also call a virtual 
network. In this specific virtual network that the corresponding flex 
algo calculation is applied.


2. For section three, why do we need one loopback address for 
one Flex-Algorithm? 


that's how you represent an algo specific path.

Can't we associate multiple Flex-Algorithms with one
loopback address, which means we want to reach the loopback address 
through different paths?


no. You need some data-plane separation. In SR it's a SID, here, given 
it's IP based, you need a separate IP prefix.





3. The second paragraph in section 3 does not describe Egress Node 
Procedures. This paragraph should be put in a seperate section.


4. I want to know the path for a specific IP Flex-Algorithm is 
calculated distributedly by each nodes paticipating this Flex-Algorithm 
or calculated centralized by an controller? 


it's a distributed calculation.

I wonder we can guarantee
the loop free  path with IP Flex-Algorithm especially when the path is 
calculated distributedly?


we MUST guarantee the consistency and it's done via FAD. Please look at 
the original FA draft:


https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/



thanks,
Peter



Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

*From:* Jeff Tantsura <mailto:jefftant.i...@gmail.com>
*Date:* 2020-12-04 09:18
*To:* Tony Li <mailto:tony1ath...@gmail.com>; Robert Raszuk
<mailto:rob...@raszuk.net>
*CC:* lsr <mailto:lsr@ietf.org>; Acee Lindem \(acee\)
<mailto:acee=40cisco@dmarc.ietf.org>
*Subject:* Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Anything else than IGP metric based SPT is considered TE. Looking
holistically - topology virtualization (or similar) could have been
a better name.

Cheers,
Jeff
On Dec 3, 2020, 4:25 PM -0800, Robert Raszuk , wrote:

Hi Tony,

The moment I hit "Send" I knew that this response may be coming as
it really depends what is one's definition of TE.

If indeed IGP TE is anything more then SPF - then sure we can call
it a TE feature.

However, while a very useful and really cool proposal, my point is
to make sure this is not oversold - that's all.

Best,
R.


On Fri, Dec 4, 2020 at 1:13 AM Tony Li mailto:tony1ath...@gmail.com>> wrote:


Hi Robert,


> However I really do not think that what Flexible Algorithm
offers can be compared or even called as Traffic Engineering
(MPLS or SR).
>
> Sure Flex Algo can accomplish in a very elegant way with
little cost multi topology routing but this is not full TE. It
can also direct traffic based on static or dynamic network
preferences (link colors, rtt drops etc ... ),  but again it
is not taking into account load of the entire network and IMHO
has no way of accomplish TE level traffic distribution.
>
> Just to make sure the message here is proper.


It’s absolutely true that FlexAlgo (IP or SR) has limitations.
There’s no bandwidth reservation. There’s no dynamic load
balancing. No, it’s not a drop in replacement for RSVP. No, it
does not supplant SR-TE and a good controller. Etc., etc., etc….

However I don’t feel that it’s fair to say that FlexAlgo can’t
be called Traffic Engineering.  After all TE is a very broad
topic. Everything that we’ve done that’s more sophisticated
than simple SPF falls in the area of Traffic Engineering. 
Link coloring and SRLG alone clearly fall into that bucket.


I’ll grant you that it may not have the right TE features for
your application, but that doesn’t mean that it’s not
sufficient for some.  Please don’t mislead people by saying
that it’s not Traffic Engineering.

Regards,
Tony


___
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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Aijun Wang]

Hi, Jeff:

 

Maybe I should add one more sentence to follow your statement, then the 
responses looks more consecutive:

 

Anything else than IGP metric based SPT is considered TE.But operator are 
expecting new TE solution that can meet the dynamic environment, not the static 
resource allocation. ---Static TE can’t meet the requirement of real world. 
If the LFA mechanism can only be achieved within each IP-FLEX algorithm, is it 
just another static resource allocation and prefix assignment method?

 

Are the above statement true or acceptable?

 

 

Best Regards

 

Aijun Wang

China Telecom

 

 

 

From: Jeff Tantsura  
Sent: Friday, December 4, 2020 11:45 AM
To: Aijun Wang 
Cc: Tony Li ; Robert Raszuk ; lsr 
; Acee Lindem (acee) 
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

 

Hi Aijun,

 

How’s my response triggered yours?

Where do you see my talking about static vs dynamic TE?

It you are looking for a philosophical angle - perhaps we could talk about 
centralized vs distributed TE and complexity of each one.

 

Regards,

Jeff





On Dec 3, 2020, at 19:13, Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:



Hi, Jeff:

 

Static TE can’t meet the requirement of real world.

If the LFA mechanism can only be achieved within each IP-FLEX algorithm, is it 
just another static resource allocation and prefix assignment method?

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>  mailto:lsr-boun...@ietf.org> > On Behalf Of Jeff Tantsura
Sent: Friday, December 4, 2020 9:18 AM
To: Tony Li mailto:tony1ath...@gmail.com> >; Robert 
Raszuk mailto:rob...@raszuk.net> >
Cc: lsr mailto:lsr@ietf.org> >; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org> >
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

 

Anything else than IGP metric based SPT is considered TE. Looking holistically 
- topology virtualization (or similar) could have been a better name.

 

Cheers, 

Jeff

On Dec 3, 2020, 4:25 PM -0800, Robert Raszuk mailto:rob...@raszuk.net> >, wrote:




Hi Tony, 

 

The moment I hit "Send" I knew that this response may be coming as it really 
depends what is one's definition of TE. 

 

If indeed IGP TE is anything more then SPF - then sure we can call it a TE 
feature. 

 

However, while a very useful and really cool proposal, my point is to make sure 
this is not oversold - that's all. 

 

Best,
R.

 

 

On Fri, Dec 4, 2020 at 1:13 AM Tony Li mailto:tony1ath...@gmail.com> > wrote:


Hi Robert,


> However I really do not think that what Flexible Algorithm offers can be 
> compared or even called as Traffic Engineering (MPLS or SR).
>
> Sure Flex Algo can accomplish in a very elegant way with little cost multi 
> topology routing but this is not full TE. It can also direct traffic based on 
> static or dynamic network preferences (link colors, rtt drops etc ... ),  but 
> again it is not taking into account load of the entire network and IMHO has 
> no way of accomplish TE level traffic distribution.
>
> Just to make sure the message here is proper.


It’s absolutely true that FlexAlgo (IP or SR) has limitations. There’s no 
bandwidth reservation. There’s no dynamic load balancing. No, it’s not a drop 
in replacement for RSVP. No, it does not supplant SR-TE and a good controller. 
Etc., etc., etc….

However I don’t feel that it’s fair to say that FlexAlgo can’t be called 
Traffic Engineering.  After all TE is a very broad topic. Everything that we’ve 
done that’s more sophisticated than simple SPF falls in the area of Traffic 
Engineering.  Link coloring and SRLG alone clearly fall into that bucket.

I’ll grant you that it may not have the right TE features for your application, 
but that doesn’t mean that it’s not sufficient for some.  Please don’t mislead 
people by saying that it’s not Traffic Engineering.

Regards,
Tony




___
Lsr mailing list
Lsr@ietf.org <mailto:Lsr@ietf.org> 
https://www.ietf.org/mailman/listinfo/lsr

___
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

[Gyan Mishra]

Hi Ron

IP Flex Algo provides one half of the puzzle control plane framework,
however just as Flex Algo built for SR is instantiated on SR data plane, I
remember you had mentioned an IPV6 data plane “non SR” based framework
possible a new RH would be used for the loose or strict path instantiation.


We were going to discuss that question I had on the original thread on IP
flex algo  but we didn’t get to it.

For IP flex algorithm as this is the main architecture document for the
technology feature should it reference the data plane instantiation of the
path.

I guess it could be done with a separate draft but I think as this would
serve the architecture framework I think maybe the perfect spot.

Kind Regards

Gyan

On Fri, Dec 4, 2020 at 12:28 AM Gyan Mishra  wrote:

>
> +1 for IP flex algo for operators toolbox
>
> Thanks
>
> On Thu, Dec 3, 2020 at 10:54 PM Jeff Tantsura 
> wrote:
>
>> I’m very much in favor of being able to provide a number of technologies
>> that help operators with different requirements and constraints to provide
>> their services in a most optimized way, hence my support for flex-algo,
>> either labeled or not as a technology on the dynamic spectrum of the
>> solution space.
>> One can achieve similar results on a single topology with a centralized
>> controller, there are trade-offs in either, extremities on either side are
>> counterproductive .
>>
>> Regards,
>> Jeff
>>
>> On Dec 3, 2020, at 17:47, Gyan Mishra  wrote:
>>
>> 
>>
>>
>>
>> In fact the concept of traffic engineering has been around for a long
>> time using simple IGP metric manipulation to steer traffic using the IGP.
>>
>> I had designed in my past life a costing algorithm where you use highest
>> bandwidth links and lowest latency as the crow flies point A to point B
>> such that you take the highest bandwidth lowest latency path based on a
>> formula for path instantiation.  This is the essence of flex algo basically
>> an engineered algorithm algo xyz for a sub routing instance instantiation.
>>
>> This concept works well for global table or single routing instance,
>> however if you have multiple VPNs and you want to realize per VPN coloring
>> capabilities it is much different then use of flex algo with a single IGP
>> global table routing following a single algo or multiple sub set algo’s.
>>
>> That’s where RSVP TE PCALC path computation and bandwidth and link
>> attributes came into play in an MPLS context.
>>
>> However, now trying to expand traditional RSVP TE to provide per VRF VPN
>> mapping and coloring is now a daunting painful and non scalable solution.
>> Now requires with RSVP static routes and VRF next hop rewrite to map each
>> VPN to a different color steered statically to a different loopback egress
>> PE iBGP next hop then the default iBGP global table next hop.
>>
>> That’s where the advent of SR with SR-TE now fills that much needed gap
>> of per VRF coloring to build the same as we had in the RSVP world loose
>> path prefix sid or strict path adjacency sid path instantiation now done
>> via centralized controller.
>>
>> The gap where flex algo comes into play is unique but I think is a tool
>> on the operator toolbox which prior to IP flex algo provided additional
>> steering granularity and path instantiation control used in conjunction
>> with SR-TE.
>>
>> The gap IP flex algo fills is internet providers global table routing
>> being able to create logical traffic steering constructs where MPLS or SR
>> does not exist.
>>
>> So that is a huge much needed gap as not all operators on the public core
>> have MPLS or SR and would like an alternative.
>>
>> This could be used in both core and data center space as well IP based
>> infrastructure.
>>
>> RSVP TE and SR have their niche and now IP flex algo fills yet another
>> somewhat mutually exclusive niche.
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Thu, Dec 3, 2020 at 8:18 PM Jeff Tantsura 
>> wrote:
>>
>>> Anything else than IGP metric based SPT is considered TE. Looking
>>> holistically - topology virtualization (or similar) could have been a
>>> better name.
>>>
>>> Cheers,
>>> Jeff
>>> On Dec 3, 2020, 4:25 PM -0800, Robert Raszuk , wrote:
>>>
>>> Hi Tony,
>>>
>>> The moment I hit "Send" I knew that this response may be coming as it
>>> really depends what is one's definition of TE.
>>>
>>> If indeed IGP TE is anything more then SPF - then sure we can call it a
>>> TE feature.
>>>
>>> However, while a very useful and really cool proposal, my point is to
>>> make sure this is not oversold - that's all.
>>>
>>> Best,
>>> R.
>>>
>>>
>>> On Fri, Dec 4, 2020 at 1:13 AM Tony Li  wrote:
>>>

 Hi Robert,


 > However I really do not think that what Flexible Algorithm offers can
 be compared or even called as Traffic Engineering (MPLS or SR).
 >
 > Sure Flex Algo can accomplish in a very elegant way with little cost
 multi topology routing but this is not full TE. It can also direct traffic
 based on static or 

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Gyan Mishra]

+1 for IP flex algo for operators toolbox

Thanks

On Thu, Dec 3, 2020 at 10:54 PM Jeff Tantsura 
wrote:

> I’m very much in favor of being able to provide a number of technologies
> that help operators with different requirements and constraints to provide
> their services in a most optimized way, hence my support for flex-algo,
> either labeled or not as a technology on the dynamic spectrum of the
> solution space.
> One can achieve similar results on a single topology with a centralized
> controller, there are trade-offs in either, extremities on either side are
> counterproductive .
>
> Regards,
> Jeff
>
> On Dec 3, 2020, at 17:47, Gyan Mishra  wrote:
>
> 
>
>
>
> In fact the concept of traffic engineering has been around for a long time
> using simple IGP metric manipulation to steer traffic using the IGP.
>
> I had designed in my past life a costing algorithm where you use highest
> bandwidth links and lowest latency as the crow flies point A to point B
> such that you take the highest bandwidth lowest latency path based on a
> formula for path instantiation.  This is the essence of flex algo basically
> an engineered algorithm algo xyz for a sub routing instance instantiation.
>
> This concept works well for global table or single routing instance,
> however if you have multiple VPNs and you want to realize per VPN coloring
> capabilities it is much different then use of flex algo with a single IGP
> global table routing following a single algo or multiple sub set algo’s.
>
> That’s where RSVP TE PCALC path computation and bandwidth and link
> attributes came into play in an MPLS context.
>
> However, now trying to expand traditional RSVP TE to provide per VRF VPN
> mapping and coloring is now a daunting painful and non scalable solution.
> Now requires with RSVP static routes and VRF next hop rewrite to map each
> VPN to a different color steered statically to a different loopback egress
> PE iBGP next hop then the default iBGP global table next hop.
>
> That’s where the advent of SR with SR-TE now fills that much needed gap of
> per VRF coloring to build the same as we had in the RSVP world loose path
> prefix sid or strict path adjacency sid path instantiation now done via
> centralized controller.
>
> The gap where flex algo comes into play is unique but I think is a tool on
> the operator toolbox which prior to IP flex algo provided additional
> steering granularity and path instantiation control used in conjunction
> with SR-TE.
>
> The gap IP flex algo fills is internet providers global table routing
> being able to create logical traffic steering constructs where MPLS or SR
> does not exist.
>
> So that is a huge much needed gap as not all operators on the public core
> have MPLS or SR and would like an alternative.
>
> This could be used in both core and data center space as well IP based
> infrastructure.
>
> RSVP TE and SR have their niche and now IP flex algo fills yet another
> somewhat mutually exclusive niche.
>
> Kind Regards
>
> Gyan
>
> On Thu, Dec 3, 2020 at 8:18 PM Jeff Tantsura 
> wrote:
>
>> Anything else than IGP metric based SPT is considered TE. Looking
>> holistically - topology virtualization (or similar) could have been a
>> better name.
>>
>> Cheers,
>> Jeff
>> On Dec 3, 2020, 4:25 PM -0800, Robert Raszuk , wrote:
>>
>> Hi Tony,
>>
>> The moment I hit "Send" I knew that this response may be coming as it
>> really depends what is one's definition of TE.
>>
>> If indeed IGP TE is anything more then SPF - then sure we can call it a
>> TE feature.
>>
>> However, while a very useful and really cool proposal, my point is to
>> make sure this is not oversold - that's all.
>>
>> Best,
>> R.
>>
>>
>> On Fri, Dec 4, 2020 at 1:13 AM Tony Li  wrote:
>>
>>>
>>> Hi Robert,
>>>
>>>
>>> > However I really do not think that what Flexible Algorithm offers can
>>> be compared or even called as Traffic Engineering (MPLS or SR).
>>> >
>>> > Sure Flex Algo can accomplish in a very elegant way with little cost
>>> multi topology routing but this is not full TE. It can also direct traffic
>>> based on static or dynamic network preferences (link colors, rtt drops etc
>>> ... ),  but again it is not taking into account load of the entire network
>>> and IMHO has no way of accomplish TE level traffic distribution.
>>> >
>>> > Just to make sure the message here is proper.
>>>
>>>
>>> It’s absolutely true that FlexAlgo (IP or SR) has limitations. There’s
>>> no bandwidth reservation. There’s no dynamic load balancing. No, it’s not a
>>> drop in replacement for RSVP. No, it does not supplant SR-TE and a good
>>> controller. Etc., etc., etc….
>>>
>>> However I don’t feel that it’s fair to say that FlexAlgo can’t be called
>>> Traffic Engineering.  After all TE is a very broad topic. Everything that
>>> we’ve done that’s more sophisticated than simple SPF falls in the area of
>>> Traffic Engineering.  Link coloring and SRLG alone clearly fall into that
>>> bucket.
>>>
>>> I’ll grant you that it may 

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Jeff Tantsura]

I’m very much in favor of being able to provide a number of technologies that 
help operators with different requirements and constraints to provide their 
services in a most optimized way, hence my support for flex-algo, either 
labeled or not as a technology on the dynamic spectrum of the solution space.
One can achieve similar results on a single topology with a centralized 
controller, there are trade-offs in either, extremities on either side are 
counterproductive . 

Regards,
Jeff

> On Dec 3, 2020, at 17:47, Gyan Mishra  wrote:
> 
> 
> 
> 
> In fact the concept of traffic engineering has been around for a long time 
> using simple IGP metric manipulation to steer traffic using the IGP.  
> 
> I had designed in my past life a costing algorithm where you use highest 
> bandwidth links and lowest latency as the crow flies point A to point B such 
> that you take the highest bandwidth lowest latency path based on a formula 
> for path instantiation.  This is the essence of flex algo basically an 
> engineered algorithm algo xyz for a sub routing instance instantiation.  
> 
> This concept works well for global table or single routing instance, however 
> if you have multiple VPNs and you want to realize per VPN coloring 
> capabilities it is much different then use of flex algo with a single IGP 
> global table routing following a single algo or multiple sub set algo’s.
> 
> That’s where RSVP TE PCALC path computation and bandwidth and link attributes 
> came into play in an MPLS context.
> 
> However, now trying to expand traditional RSVP TE to provide per VRF VPN 
> mapping and coloring is now a daunting painful and non scalable solution.  
> Now requires with RSVP static routes and VRF next hop rewrite to map each VPN 
> to a different color steered statically to a different loopback egress PE 
> iBGP next hop then the default iBGP global table next hop.  
> 
> That’s where the advent of SR with SR-TE now fills that much needed gap of 
> per VRF coloring to build the same as we had in the RSVP world loose path 
> prefix sid or strict path adjacency sid path instantiation now done via 
> centralized controller.
> 
> The gap where flex algo comes into play is unique but I think is a tool on 
> the operator toolbox which prior to IP flex algo provided additional steering 
> granularity and path instantiation control used in conjunction with SR-TE.
> 
> The gap IP flex algo fills is internet providers global table routing being 
> able to create logical traffic steering constructs where MPLS or SR does not 
> exist.  
> 
> So that is a huge much needed gap as not all operators on the public core 
> have MPLS or SR and would like an alternative. 
> 
> This could be used in both core and data center space as well IP based 
> infrastructure.
> 
> RSVP TE and SR have their niche and now IP flex algo fills yet another 
> somewhat mutually exclusive niche.
> 
> Kind Regards 
> 
> Gyan
> 
>> On Thu, Dec 3, 2020 at 8:18 PM Jeff Tantsura  wrote:
>> Anything else than IGP metric based SPT is considered TE. Looking 
>> holistically - topology virtualization (or similar) could have been a better 
>> name.
>> 
>> Cheers,
>> Jeff
>>> On Dec 3, 2020, 4:25 PM -0800, Robert Raszuk , wrote:
>>> Hi Tony,
>>> 
>>> The moment I hit "Send" I knew that this response may be coming as it 
>>> really depends what is one's definition of TE. 
>>> 
>>> If indeed IGP TE is anything more then SPF - then sure we can call it a TE 
>>> feature. 
>>> 
>>> However, while a very useful and really cool proposal, my point is to make 
>>> sure this is not oversold - that's all. 
>>> 
>>> Best,
>>> R.
>>> 
>>> 
 On Fri, Dec 4, 2020 at 1:13 AM Tony Li  wrote:
 
 Hi Robert,
 
 
 > However I really do not think that what Flexible Algorithm offers can be 
 > compared or even called as Traffic Engineering (MPLS or SR).
 >
 > Sure Flex Algo can accomplish in a very elegant way with little cost 
 > multi topology routing but this is not full TE. It can also direct 
 > traffic based on static or dynamic network preferences (link colors, rtt 
 > drops etc ... ),  but again it is not taking into account load of the 
 > entire network and IMHO has no way of accomplish TE level traffic 
 > distribution.
 >
 > Just to make sure the message here is proper.
 
 
 It’s absolutely true that FlexAlgo (IP or SR) has limitations. There’s no 
 bandwidth reservation. There’s no dynamic load balancing. No, it’s not a 
 drop in replacement for RSVP. No, it does not supplant SR-TE and a good 
 controller. Etc., etc., etc….
 
 However I don’t feel that it’s fair to say that FlexAlgo can’t be called 
 Traffic Engineering.  After all TE is a very broad topic. Everything that 
 we’ve done that’s more sophisticated than simple SPF falls in the area of 
 Traffic Engineering.  Link coloring and SRLG alone clearly fall into that 
 bucket.
 
 I’ll grant you 

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Jeff Tantsura]

Hi Aijun,

How’s my response triggered yours?
Where do you see my talking about static vs dynamic TE?
It you are looking for a philosophical angle - perhaps we could talk about 
centralized vs distributed TE and complexity of each one.

Regards,
Jeff

> On Dec 3, 2020, at 19:13, Aijun Wang  wrote:
> 
> 
> Hi, Jeff:
>  
> Static TE can’t meet the requirement of real world.
> If the LFA mechanism can only be achieved within each IP-FLEX algorithm, is 
> it just another static resource allocation and prefix assignment method?
>  
>  
> Best Regards
>  
> Aijun Wang
> China Telecom
>  
> From: lsr-boun...@ietf.org  On Behalf Of Jeff Tantsura
> Sent: Friday, December 4, 2020 9:18 AM
> To: Tony Li ; Robert Raszuk 
> Cc: lsr ; Acee Lindem (acee) 
> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>  
> Anything else than IGP metric based SPT is considered TE. Looking 
> holistically - topology virtualization (or similar) could have been a better 
> name.
>  
> Cheers,
> Jeff
> On Dec 3, 2020, 4:25 PM -0800, Robert Raszuk , wrote:
> 
> Hi Tony,
>  
> The moment I hit "Send" I knew that this response may be coming as it really 
> depends what is one's definition of TE. 
>  
> If indeed IGP TE is anything more then SPF - then sure we can call it a TE 
> feature. 
>  
> However, while a very useful and really cool proposal, my point is to make 
> sure this is not oversold - that's all. 
>  
> Best,
> R.
>  
>  
> On Fri, Dec 4, 2020 at 1:13 AM Tony Li  wrote:
> 
> Hi Robert,
> 
> 
> > However I really do not think that what Flexible Algorithm offers can be 
> > compared or even called as Traffic Engineering (MPLS or SR).
> >
> > Sure Flex Algo can accomplish in a very elegant way with little cost multi 
> > topology routing but this is not full TE. It can also direct traffic based 
> > on static or dynamic network preferences (link colors, rtt drops etc ... ), 
> >  but again it is not taking into account load of the entire network and 
> > IMHO has no way of accomplish TE level traffic distribution.
> >
> > Just to make sure the message here is proper.
> 
> 
> It’s absolutely true that FlexAlgo (IP or SR) has limitations. There’s no 
> bandwidth reservation. There’s no dynamic load balancing. No, it’s not a drop 
> in replacement for RSVP. No, it does not supplant SR-TE and a good 
> controller. Etc., etc., etc….
> 
> However I don’t feel that it’s fair to say that FlexAlgo can’t be called 
> Traffic Engineering.  After all TE is a very broad topic. Everything that 
> we’ve done that’s more sophisticated than simple SPF falls in the area of 
> Traffic Engineering.  Link coloring and SRLG alone clearly fall into that 
> bucket.
> 
> I’ll grant you that it may not have the right TE features for your 
> application, but that doesn’t mean that it’s not sufficient for some.  Please 
> don’t mislead people by saying that it’s not Traffic Engineering.
> 
> Regards,
> Tony
> 
> 
> ___
> 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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Aijun Wang]

Hi, Jeff:

 

Static TE can’t meet the requirement of real world.

If the LFA mechanism can only be achieved within each IP-FLEX algorithm, is it 
just another static resource allocation and prefix assignment method?

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Jeff Tantsura
Sent: Friday, December 4, 2020 9:18 AM
To: Tony Li ; Robert Raszuk 
Cc: lsr ; Acee Lindem (acee) 
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

 

Anything else than IGP metric based SPT is considered TE. Looking holistically 
- topology virtualization (or similar) could have been a better name.

 

Cheers, 

Jeff

On Dec 3, 2020, 4:25 PM -0800, Robert Raszuk mailto:rob...@raszuk.net> >, wrote:



Hi Tony, 

 

The moment I hit "Send" I knew that this response may be coming as it really 
depends what is one's definition of TE. 

 

If indeed IGP TE is anything more then SPF - then sure we can call it a TE 
feature. 

 

However, while a very useful and really cool proposal, my point is to make sure 
this is not oversold - that's all. 

 

Best,
R.

 

 

On Fri, Dec 4, 2020 at 1:13 AM Tony Li mailto:tony1ath...@gmail.com> > wrote:


Hi Robert,


> However I really do not think that what Flexible Algorithm offers can be 
> compared or even called as Traffic Engineering (MPLS or SR).
>
> Sure Flex Algo can accomplish in a very elegant way with little cost multi 
> topology routing but this is not full TE. It can also direct traffic based on 
> static or dynamic network preferences (link colors, rtt drops etc ... ),  but 
> again it is not taking into account load of the entire network and IMHO has 
> no way of accomplish TE level traffic distribution.
>
> Just to make sure the message here is proper.


It’s absolutely true that FlexAlgo (IP or SR) has limitations. There’s no 
bandwidth reservation. There’s no dynamic load balancing. No, it’s not a drop 
in replacement for RSVP. No, it does not supplant SR-TE and a good controller. 
Etc., etc., etc….

However I don’t feel that it’s fair to say that FlexAlgo can’t be called 
Traffic Engineering.  After all TE is a very broad topic. Everything that we’ve 
done that’s more sophisticated than simple SPF falls in the area of Traffic 
Engineering.  Link coloring and SRLG alone clearly fall into that bucket.

I’ll grant you that it may not have the right TE features for your application, 
but that doesn’t mean that it’s not sufficient for some.  Please don’t mislead 
people by saying that it’s not Traffic Engineering.

Regards,
Tony



___
Lsr mailing list
Lsr@ietf.org <mailto:Lsr@ietf.org> 
https://www.ietf.org/mailman/listinfo/lsr

___
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

[Gyan Mishra]

In fact the concept of traffic engineering has been around for a long time
using simple IGP metric manipulation to steer traffic using the IGP.

I had designed in my past life a costing algorithm where you use highest
bandwidth links and lowest latency as the crow flies point A to point B
such that you take the highest bandwidth lowest latency path based on a
formula for path instantiation.  This is the essence of flex algo basically
an engineered algorithm algo xyz for a sub routing instance instantiation.

This concept works well for global table or single routing instance,
however if you have multiple VPNs and you want to realize per VPN coloring
capabilities it is much different then use of flex algo with a single IGP
global table routing following a single algo or multiple sub set algo’s.

That’s where RSVP TE PCALC path computation and bandwidth and link
attributes came into play in an MPLS context.

However, now trying to expand traditional RSVP TE to provide per VRF VPN
mapping and coloring is now a daunting painful and non scalable solution.
Now requires with RSVP static routes and VRF next hop rewrite to map each
VPN to a different color steered statically to a different loopback egress
PE iBGP next hop then the default iBGP global table next hop.

That’s where the advent of SR with SR-TE now fills that much needed gap of
per VRF coloring to build the same as we had in the RSVP world loose path
prefix sid or strict path adjacency sid path instantiation now done via
centralized controller.

The gap where flex algo comes into play is unique but I think is a tool on
the operator toolbox which prior to IP flex algo provided additional
steering granularity and path instantiation control used in conjunction
with SR-TE.

The gap IP flex algo fills is internet providers global table routing being
able to create logical traffic steering constructs where MPLS or SR does
not exist.

So that is a huge much needed gap as not all operators on the public core
have MPLS or SR and would like an alternative.

This could be used in both core and data center space as well IP based
infrastructure.

RSVP TE and SR have their niche and now IP flex algo fills yet another
somewhat mutually exclusive niche.

Kind Regards

Gyan

On Thu, Dec 3, 2020 at 8:18 PM Jeff Tantsura 
wrote:

> Anything else than IGP metric based SPT is considered TE. Looking
> holistically - topology virtualization (or similar) could have been a
> better name.
>
> Cheers,
> Jeff
> On Dec 3, 2020, 4:25 PM -0800, Robert Raszuk , wrote:
>
> Hi Tony,
>
> The moment I hit "Send" I knew that this response may be coming as it
> really depends what is one's definition of TE.
>
> If indeed IGP TE is anything more then SPF - then sure we can call it a TE
> feature.
>
> However, while a very useful and really cool proposal, my point is to make
> sure this is not oversold - that's all.
>
> Best,
> R.
>
>
> On Fri, Dec 4, 2020 at 1:13 AM Tony Li  wrote:
>
>>
>> Hi Robert,
>>
>>
>> > However I really do not think that what Flexible Algorithm offers can
>> be compared or even called as Traffic Engineering (MPLS or SR).
>> >
>> > Sure Flex Algo can accomplish in a very elegant way with little cost
>> multi topology routing but this is not full TE. It can also direct traffic
>> based on static or dynamic network preferences (link colors, rtt drops etc
>> ... ),  but again it is not taking into account load of the entire network
>> and IMHO has no way of accomplish TE level traffic distribution.
>> >
>> > Just to make sure the message here is proper.
>>
>>
>> It’s absolutely true that FlexAlgo (IP or SR) has limitations. There’s no
>> bandwidth reservation. There’s no dynamic load balancing. No, it’s not a
>> drop in replacement for RSVP. No, it does not supplant SR-TE and a good
>> controller. Etc., etc., etc….
>>
>> However I don’t feel that it’s fair to say that FlexAlgo can’t be called
>> Traffic Engineering.  After all TE is a very broad topic. Everything that
>> we’ve done that’s more sophisticated than simple SPF falls in the area of
>> Traffic Engineering.  Link coloring and SRLG alone clearly fall into that
>> bucket.
>>
>> I’ll grant you that it may not have the right TE features for your
>> application, but that doesn’t mean that it’s not sufficient for some.
>> Please don’t mislead people by saying that it’s not Traffic Engineering.
>>
>> Regards,
>> Tony
>>
>>
>> ___
> 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
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
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

[Jeff Tantsura]

Anything else than IGP metric based SPT is considered TE. Looking holistically 
- topology virtualization (or similar) could have been a better name.

Cheers,
Jeff
On Dec 3, 2020, 4:25 PM -0800, Robert Raszuk , wrote:
> Hi Tony,
>
> The moment I hit "Send" I knew that this response may be coming as it really 
> depends what is one's definition of TE.
>
> If indeed IGP TE is anything more then SPF - then sure we can call it a TE 
> feature.
>
> However, while a very useful and really cool proposal, my point is to make 
> sure this is not oversold - that's all.
>
> Best,
> R.
>
>
> > On Fri, Dec 4, 2020 at 1:13 AM Tony Li  wrote:
> > >
> > > Hi Robert,
> > >
> > >
> > > > However I really do not think that what Flexible Algorithm offers can 
> > > > be compared or even called as Traffic Engineering (MPLS or SR).
> > > >
> > > > Sure Flex Algo can accomplish in a very elegant way with little cost 
> > > > multi topology routing but this is not full TE. It can also direct 
> > > > traffic based on static or dynamic network preferences (link colors, 
> > > > rtt drops etc ... ),  but again it is not taking into account load of 
> > > > the entire network and IMHO has no way of accomplish TE level traffic 
> > > > distribution.
> > > >
> > > > Just to make sure the message here is proper.
> > >
> > >
> > > It’s absolutely true that FlexAlgo (IP or SR) has limitations. There’s no 
> > > bandwidth reservation. There’s no dynamic load balancing. No, it’s not a 
> > > drop in replacement for RSVP. No, it does not supplant SR-TE and a good 
> > > controller. Etc., etc., etc….
> > >
> > > However I don’t feel that it’s fair to say that FlexAlgo can’t be called 
> > > Traffic Engineering.  After all TE is a very broad topic. Everything that 
> > > we’ve done that’s more sophisticated than simple SPF falls in the area of 
> > > Traffic Engineering.  Link coloring and SRLG alone clearly fall into that 
> > > bucket.
> > >
> > > I’ll grant you that it may not have the right TE features for your 
> > > application, but that doesn’t mean that it’s not sufficient for some.  
> > > Please don’t mislead people by saying that it’s not Traffic Engineering.
> > >
> > > Regards,
> > > Tony
> > >
> > >
> ___
> 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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Robert Raszuk]

Hi,

I support adoption of this draft.

However I really do not think that what Flexible Algorithm offers can be
compared or even called as Traffic Engineering (MPLS or SR).

Sure Flex Algo can accomplish in a very elegant way with little cost multi
topology routing but this is not full TE. It can also direct traffic based
on static or dynamic network preferences (link colors, rtt drops etc ...
),  but again it is not taking into account load of the entire network and
IMHO has no way of accomplish TE level traffic distribution.

Just to make sure the message here is proper.

Thx,
R.

On Tue, Dec 1, 2020 at 10:13 PM Acee Lindem (acee)  wrote:

> This IP Flex Algorithm draft generated quite a bit of discussion on use
> cases and deployment prior to IETF 109 and there was generally support for
> WG adoption. This begins a two week WG adoption call. Please indicate your
> support or objection to WG adoption on this list prior to 12:00 AM UTC on
> December 16th, 2020. Also, review comments are certainly welcome.
>
> Thanks,
>
> Acee
>
>
>
> ___
> 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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Ketan Talaulikar (ketant)]

I support the WG adoption of this document. It covers an important piece of the 
FlexAlgorith solution space.

Thanks,
Ketan

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 02 December 2020 02:43
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee


___
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

[Aijun Wang]

Hello Parag:

 

From: Parag Kaneriya  
Sent: Thursday, December 3, 2020 2:08 PM
To: Aijun Wang ; '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

 

Hello Aijun,

 

Every router by default support algo 0.  When router support IP-FLEX algo
along with default algo, we need to be deterministic when there is conflict
of prefix advertise in both algo. This conflict might be due to mis config.
So when such condition arise, prefix belong to default algo should give
priority to be install in forwarding table. 

[WAJ] Why not prefer to the prefixes belong to the IP-FLEX?

And, let's consider its relation with BGP Prefixes. When the sub-topology
within the IP-FLEX is broken, because you don't support (BGP nexthop)
automatic fallback to the default algo,  traffic to these prefixes  that
advertised by the BGP will also be broken?

Is there any mechanism to support the automatic fallback from IP-FLEX to
default algo?   

 

Regards

Parag

 

Juniper Business Use Only

From: Lsr mailto:lsr-boun...@ietf.org> > On Behalf Of
Aijun Wang
Sent: Thursday, December 3, 2020 7:02 AM
To: 'Acee Lindem (acee)' mailto:acee=40cisco@dmarc.ietf.org> >; 'lsr' mailto:lsr@ietf.org> >
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

 

[External Email. Be cautious of content]

 

Hi, authors:

 

Want to confirm one thing:

Does the mechanism described in this draft support the automatic fallback
from "flex algorithm" to the "traditional least-cost algorithm"?  

That is to say, can one prefix exists both in the "flex algorithm" table and
"traditional least-cost algorithm" table, the router prefer to forwarding
the packet based on the former table, and if not hit, then lookup the latter
table?

 

>From the context of the document, the answer seems not, or even on the
contrary?

In cases where a prefix advertisement is received in both a IPv4

   Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability

   TLV, the IPv4 Prefix Reachability advertisement MUST be preferred

   when installing entries in the forwarding plane.

 

If so, what the value to deploy such flexible algorithm within the network?
>From my POV, the reason that we want to deploy such mechanism is that we
want to differentiate the path(result of flex algorithm) of some traffic
from that(result of traditional least-cost algorithm) of most other normal
traffic.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>
mailto:lsr-boun...@ietf.org> > On Behalf Of Acee
Lindem (acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr mailto:lsr@ietf.org> >
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

 

This IP Flex Algorithm draft generated quite a bit of discussion on use
cases and deployment prior to IETF 109 and there was generally support for
WG adoption. This begins a two week WG adoption call. Please indicate your
support or objection to WG adoption on this list prior to 12:00 AM UTC on
December 16th, 2020. Also, review comments are certainly welcome.

Thanks,

Acee

 

 

___
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

[Parag Kaneriya]

Hello Aijun,

Every router by default support algo 0.  When router support IP-FLEX algo along 
with default algo, we need to be deterministic when there is conflict of prefix 
advertise in both algo. This conflict might be due to mis config. So when such 
condition arise, prefix belong to default algo should give priority to be 
install in forwarding table.

Regards
Parag


Juniper Business Use Only
From: Lsr  On Behalf Of Aijun Wang
Sent: Thursday, December 3, 2020 7:02 AM
To: '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

[External Email. Be cautious of content]

Hi, authors:

Want to confirm one thing:
Does the mechanism described in this draft support the automatic fallback from 
"flex algorithm" to the "traditional least-cost algorithm"?
That is to say, can one prefix exists both in the "flex algorithm" table and 
"traditional least-cost algorithm" table, the router prefer to forwarding the 
packet based on the former table, and if not hit, then lookup the latter table?

>From the context of the document, the answer seems not, or even on the 
>contrary?
In cases where a prefix advertisement is received in both a IPv4
   Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability
   TLV, the IPv4 Prefix Reachability advertisement MUST be preferred
   when installing entries in the forwarding plane.

If so, what the value to deploy such flexible algorithm within the network? 
From my POV, the reason that we want to deploy such mechanism is that we want 
to differentiate the path(result of flex algorithm) of some traffic from 
that(result of traditional least-cost algorithm) of most other normal traffic.

Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem 
(acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr mailto:lsr@ietf.org>>
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee


___
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

[Gyan Mishra]

I support WG adoption.  This is a much needed traffic engineering
capability independent of MPLS.

Thanks

Gyan

On Wed, Dec 2, 2020 at 8:32 PM Aijun Wang  wrote:

> Hi, authors:
>
>
>
> Want to confirm one thing:
>
> Does the mechanism described in this draft support the automatic fallback
> from “flex algorithm” to the “traditional least-cost algorithm”?
>
> That is to say, can one prefix exists both in the “flex algorithm” table
> and “traditional least-cost algorithm” table, the router prefer to
> forwarding the packet based on the former table, and if not hit, then
> lookup the latter table?
>
>
>
> From the context of the document, the answer seems not, or even on the
> contrary?
>
> In cases where a prefix advertisement is received in both a IPv4
>
>Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability
>
>TLV, the IPv4 Prefix Reachability advertisement MUST be preferred
>
>when installing entries in the forwarding plane.
>
>
>
> If so, what the value to deploy such flexible algorithm within the
> network? From my POV, the reason that we want to deploy such mechanism is
> that we want to differentiate the path(result of flex algorithm) of some
> traffic from that(result of traditional least-cost algorithm) of most other
> normal traffic.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org  *On Behalf Of *Acee
> Lindem (acee)
> *Sent:* Wednesday, December 2, 2020 5:13 AM
> *To:* lsr 
> *Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms
> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>
>
>
> This IP Flex Algorithm draft generated quite a bit of discussion on use
> cases and deployment prior to IETF 109 and there was generally support for
> WG adoption. This begins a two week WG adoption call. Please indicate your
> support or objection to WG adoption on this list prior to 12:00 AM UTC on
> December 16th, 2020. Also, review comments are certainly welcome.
>
> Thanks,
>
> Acee
>
>
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
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

[Aijun Wang]

Hi, authors:

 

Want to confirm one thing:

Does the mechanism described in this draft support the automatic fallback from 
“flex algorithm” to the “traditional least-cost algorithm”?  

That is to say, can one prefix exists both in the “flex algorithm” table and 
“traditional least-cost algorithm” table, the router prefer to forwarding the 
packet based on the former table, and if not hit, then lookup the latter table?

 

>From the context of the document, the answer seems not, or even on the 
>contrary?

In cases where a prefix advertisement is received in both a IPv4

   Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability

   TLV, the IPv4 Prefix Reachability advertisement MUST be preferred

   when installing entries in the forwarding plane.

 

If so, what the value to deploy such flexible algorithm within the network? 
From my POV, the reason that we want to deploy such mechanism is that we want 
to differentiate the path(result of flex algorithm) of some traffic from 
that(result of traditional least-cost algorithm) of most other normal traffic.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
(acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

 

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.

Thanks,

Acee

 

 

___
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

[Yingzhen Qu]

I have read the draft and support its adoption.

Thanks,
Yingzhen

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Wednesday, December 2, 2020 at 9:49 AM
To: "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
Resent-From: 
Resent-Date: Wednesday, December 2, 2020 at 9:49 AM

Speaking as WG member:

I have read this draft and support adoption.

Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Tuesday, December 1, 2020 at 4:13 PM
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee

___
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

[Tarek Saad]

I read this draft and I support its adoption.

Regards,
Tarek


> On Dec 1, 2020, at 1:12 PM, Acee Lindem (acee) 
> 
>  wrote:

>

> This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
> and deployment prior to IETF 109 and there was generally support for WG 
> adoption. This begins a two week WG adoption call. Please indicate your 
> support or objection to WG adoption on this list prior to 12:00 AM UTC on 
> December 16th, 2020. Also, review comments are certainly welcome.

> Thanks,

> Acee





Juniper Business Use Only
___
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

[Acee Lindem (acee)]

Speaking as WG member:

I have read this draft and support adoption.

Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Tuesday, December 1, 2020 at 4:13 PM
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee

___
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

[Les Ginsberg (ginsberg)]

I support WG adoption.
This is another useful tool to support traffic engineering in real world 
deployments.

  Les


From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, December 01, 2020 1:13 PM
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee


___
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

[Jeff Tantsura]

Yes/support - very useful work!

Cheers,
Jeff
On Dec 1, 2020, 1:13 PM -0800, Acee Lindem (acee) 
, wrote:
> This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
> and deployment prior to IETF 109 and there was generally support for WG 
> adoption. This begins a two week WG adoption call. Please indicate your 
> support or objection to WG adoption on this list prior to 12:00 AM UTC on 
> December 16th, 2020. Also, review comments are certainly welcome.
> Thanks,
> Acee
>
> ___
> 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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Joel M. Halpern]

I have read this draft, and followed the discussion on the list.
This seems a useful and sensible piece of work.  I support adoption.

Yours,
Joel

On 12/1/2020 4:12 PM, Acee Lindem (acee) wrote:
This IP Flex Algorithm draft generated quite a bit of discussion on use 
cases and deployment prior to IETF 109 and there was generally support 
for WG adoption. This begins a two week WG adoption call. Please 
indicate your support or objection to WG adoption on this list prior to 
12:00 AM UTC on December 16^th , 2020. Also, review comments are 
certainly welcome.


Thanks,

Acee


___
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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Yan Filyurin]

Would very much support and appreciate adoption as well for same reasons.  It 
would be amazing to have that option to segment large backhaul networks without 
shims or encapsulations.  More exploration of what is described in section 8, 
in relationship to LFA would be of interest.

Yan

Viasat

> On Dec 1, 2020, at 4:29 PM, Tony Li  wrote:
> 
> 
> 
> I support adopting this draft.  Traffic engineering without MPLS?  Yes, 
> please.
> 
> Tony
> 
> 
>> On Dec 1, 2020, at 1:12 PM, Acee Lindem (acee) 
>> mailto:acee=40cisco@dmarc.ietf.org>> 
>> wrote:
>> 
>> This IP Flex Algorithm draft generated quite a bit of discussion on use 
>> cases and deployment prior to IETF 109 and there was generally support for 
>> WG adoption. This begins a two week WG adoption call. Please indicate your 
>> support or objection to WG adoption on this list prior to 12:00 AM UTC on 
>> December 16th, 2020. Also, review comments are certainly welcome.
>> Thanks,
>> Acee
>>  
>> ___
>> 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

___
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

[Tony Li]

I support adopting this draft.  Traffic engineering without MPLS?  Yes, please.

Tony


> On Dec 1, 2020, at 1:12 PM, Acee Lindem (acee) 
>  wrote:
> 
> This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
> and deployment prior to IETF 109 and there was generally support for WG 
> adoption. This begins a two week WG adoption call. Please indicate your 
> support or objection to WG adoption on this list prior to 12:00 AM UTC on 
> December 16th, 2020. Also, review comments are certainly welcome.
> Thanks,
> Acee
>  
> ___
> 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

[Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Acee Lindem (acee)]

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr