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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 1 Dec 2020 21:12:52 +0000

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

---

From: Tony Li <[email-masked]>
Date: Tue, 1 Dec 2020 13:29:36 -0800

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

Tony

> On Dec 1, 2020, at 1:12 PM, Acee Lindem (acee) <acee=[email-masked]> wrote:
> 
> _______________________________________________
> Lsr mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>

---

From: Yan Filyurin <[email-masked]>
Date: Tue, 1 Dec 2020 17:00:20 -0500

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 <[email-masked]> wrote:
> 
> 
> 
>> On Dec 1, 2020, at 1:12 PM, Acee Lindem (acee) <acee=[email-masked] <mailto:acee=[email-masked]>> wrote:
>> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 1 Dec 2020 17:21:53 -0500

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

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 1 Dec 2020 14:39:08 -0800

Yes/support - very useful work!

Cheers,
Jeff

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 1 Dec 2020 23:47:17 +0000

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

  Les

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

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 3 Dec 2020 09:31:32 +0800

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: [email-masked] <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr <[email-masked]>
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Thanks,

Acee

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 2 Dec 2020 22:39:46 -0500

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 <[email-masked]> wrote:

> 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?
>
>
>
> 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:* [email-masked] <[email-masked]> *On Behalf Of *Acee
> Lindem (acee)
> *Sent:* Wednesday, December 2, 2020 5:13 AM
> *To:* lsr <[email-masked]>
> *Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms
> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>
>
>
> 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
>
>
>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Parag Kaneriya <[email-masked]>
Date: Thu, 3 Dec 2020 06:07:32 +0000

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 <[email-masked]> On Behalf Of Aijun Wang
Sent: Thursday, December 3, 2020 7:02 AM
To: 'Acee Lindem (acee)' <acee=[email-masked]>; 'lsr' <[email-masked]>
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?

Best Regards

Aijun Wang
China Telecom

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

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 3 Dec 2020 15:06:53 +0800

Hello Parag:

From: Parag Kaneriya <[email-masked]> 
Sent: Thursday, December 3, 2020 2:08 PM
To: Aijun Wang <[email-masked]>; 'Acee Lindem (acee)'
<acee=[email-masked]>; 'lsr' <[email-masked]>
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

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

Hi, authors:

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?

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: [email-masked] <mailto:[email-masked]>
<[email-masked] <mailto:[email-masked]> > On Behalf Of Acee
Lindem (acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr <[email-masked] <mailto:[email-masked]> >
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Thanks,

Acee

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 3 Dec 2020 07:11:55 +0000

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

Thanks,
Ketan

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

---

From: Peter Psenak <[email-masked]>
Date: Thu, 3 Dec 2020 10:06:27 +0100

Hi Aijun,

On 03/12/2020 02:31, Aijun Wang wrote:
> Does the mechanism described in this draft support the automatic 
> fallback from “flex algorithm” to the “traditional least-cost algorithm”?

no.

> forwarding the packet based on the former table, and if not hit, then 

no.

>     when installing entries in the forwarding plane.

above text is to handle an error case and only associate the prefix with 
the single algo - e.g. algo 0.

thanks,
Peter

> 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:[email-masked] <[email-masked]> *On Behalf Of *Acee 
> Lindem (acee)

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 4 Dec 2020 00:58:42 +0100

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.

---

From: Tony Li <[email-masked]>
Date: Thu, 3 Dec 2020 16:13:38 -0800

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

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 4 Dec 2020 01:24:44 +0100

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 <[email-masked]> wrote:

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

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 3 Dec 2020 17:18:15 -0800

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 <[email-masked]>, 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.
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 3 Dec 2020 20:46:38 -0500

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 <[email-masked]>
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
>> > However I really do not think that what Flexible Algorithm offers can
>> be compared or even called as Traffic Engineering (MPLS or SR).
>> >
-- 

*Gyan Mishra*

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 4 Dec 2020 11:13:10 +0800

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: [email-masked] <[email-masked]> On Behalf Of Jeff Tantsura
Sent: Friday, December 4, 2020 9:18 AM
To: Tony Li <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: lsr <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Cheers, 

Jeff

On Dec 3, 2020, 4:25 PM -0800, Robert Raszuk <[email-masked] <mailto:[email-masked]> >, wrote:

Hi Tony, 

Best,
R.

On Fri, Dec 4, 2020 at 1:13 AM Tony Li <[email-masked] <mailto:[email-masked]> > wrote:

Hi Robert,

Regards,
Tony

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 3 Dec 2020 19:44:33 -0800

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 <[email-masked]> wrote:
> 
> 
> Hi, Jeff:
>

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 3 Dec 2020 19:54:01 -0800

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 <[email-masked]> 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 <[email-masked]> wrote:
> Gyan Mishra
> Network Solutions Architect 
> M 301 502-1347
> 13101 Columbia Pike 
> Silver Spring, MD
>

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 4 Dec 2020 12:26:53 +0800

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

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? I wonder we can guarantee the loop free  path with IP Flex-Algorithm especially when the path is calculated distributedly?

Best Regards,
Zhenqiang Li

[email-masked]
 
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

Best,
R.

Hi Robert,

Regards,
Tony

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 4 Dec 2020 00:28:34 -0500

+1 for IP flex algo for operators toolbox

Thanks

On Thu, Dec 3, 2020 at 10:54 PM Jeff Tantsura <[email-masked]>
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
>
> 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.
>
>> However, while a very useful and really cool proposal, my point is to
>> make sure this is not oversold - that's all.
>>
>> Best,
>> R.
>>
>>
>>> 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
> *M 301 502-134713101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g> *Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g>
>
> --

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 4 Dec 2020 00:43:34 -0500

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 <[email-masked]> 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.
>>
>> 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
>>>> 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.
>>>>

*Gyan Mishra*

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 4 Dec 2020 14:56:42 +0800

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 <[email-masked]> 
Sent: Friday, December 4, 2020 11:45 AM
To: Aijun Wang <[email-masked]>
Cc: Tony Li <[email-masked]>; Robert Raszuk <[email-masked]>; lsr <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Hi Aijun,

Regards,

Jeff

On Dec 3, 2020, at 19:13, Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Jeff:

 

Best Regards

Aijun Wang

China Telecom

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

Cheers, 

Jeff

Hi Tony, 

Best,
R.

Hi Robert,

Regards,
Tony

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 4 Dec 2020 08:36:38 +0100

Hi,

Adjusting subject to reflect topic.

Wow .. I did not think this will start such a debate :)

To me this is actually very simple. Flex Algo is still IMO an SPF with
additional two new factors:

* You have ability to exclude links or nodes from your computation
* You run traditional SPF based on any metric (static or dynamic) you can
imagine

Did I miss something?

Yes the above will allow you to steer traffic other then based on the IGP
metric, but as you all recall when we started to deploy MPLS-TE Cariden was
claiming that they can accomplish TE without MPLS too by properly adjusting
IGP metrics while observing traffic demands.

Cheers,
Robert

---

From: Peter Psenak <[email-masked]>
Date: Fri, 4 Dec 2020 10:18:14 +0100

Zhenqiang,

On 04/12/2020 05:26, [email-masked] wrote:
> 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
> ------------------------------------------------------------------------
> [email-masked]
> 
>     *From:* Jeff Tantsura <mailto:[email-masked]>
>     *Date:* 2020-12-04 09:18
>     *To:* Tony Li <mailto:[email-masked]>; Robert Raszuk
>     <mailto:[email-masked]>
>     *CC:* lsr <mailto:[email-masked]>; Acee Lindem \(acee\)
>     <mailto:acee=[email-masked]>
>     *Subject:* Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
>     holistically - topology virtualization (or similar) could have been
>     a better name.
> 
>     Cheers,
>     Jeff
>>     The moment I hit "Send" I knew that this response may be coming as
>>     it really depends what is one's definition of TE.
>>
>>     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 <[email-masked]
>>     <mailto:[email-masked]>> 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.
>>         >
>>         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
>>
>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 4 Dec 2020 12:23:22 +0000

From: Lsr <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Friday, December 4, 2020 at 2:37 AM
To: lsr <[email-masked]>, Tony Li <[email-masked]>
Cc: Jeff Tantsura <[email-masked]>, Gyan Mishra <[email-masked]>, Aijun Wang <[email-masked]>, "Acee Lindem (acee)" <acee=[email-masked]>
Subject: [Lsr] Flexible Algorithm - TE or not TE

Hi,

To TE or not to TE – that is the question…

You guys obviously have more time on your hands than myself but feel free to continue 😉

Thanks,
Acee

To me this is actually very simple. Flex Algo is still IMO an SPF with additional two new factors:

* You have ability to exclude links or nodes from your computation
* You run traditional SPF based on any metric (static or dynamic) you can imagine

Did I miss something?

Yes the above will allow you to steer traffic other then based on the IGP metric, but as you all recall when we started to deploy MPLS-TE Cariden was claiming that they can accomplish TE without MPLS too by properly adjusting IGP metrics while observing traffic demands.

Cheers,
Robert

---

From: Tony Li <[email-masked]>
Date: Fri, 4 Dec 2020 07:49:05 -0800

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

---

From: <[email-masked]>
Date: Mon, 7 Dec 2020 11:22:48 +0100

Hi,

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

Stephane

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

Thanks,

Acee

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 7 Dec 2020 09:37:33 -0800

Zhenqiang,

please see inline

Cheers,
Jeff

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
[email-masked]

From: Jeff Tantsura
Date: 2020-12-04 09:18

Cheers,
Jeff

Best,
R.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 9 Dec 2020 10:10:29 +0000

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:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr <[email-masked]>
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

---

From: Peter Psenak <[email-masked]>
Date: Wed, 9 Dec 2020 11:45:05 +0100

Jimmy,

On 09/12/2020 11:10, Dongjie (Jimmy) wrote:
> 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:[email-masked]] *On Behalf Of *Acee Lindem (acee)

---

From: Parag Kaneriya <[email-masked]>
Date: Wed, 9 Dec 2020 10:46:08 +0000

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 <[email-masked]> On Behalf Of Dongjie (Jimmy)
Sent: Wednesday, December 9, 2020 3:40 PM
To: Acee Lindem (acee) <acee=[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Hi authors,

Best regards,
Jie

---

From: Huzhibo <[email-masked]>
Date: Wed, 9 Dec 2020 10:50:51 +0000

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: Peter Psenak <[email-masked]>
Date: Wed, 9 Dec 2020 12:15:44 +0100

Zhibo,

On 09/12/2020 11:50, Huzhibo wrote:
> 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

---

From: Huzhibo <[email-masked]>
Date: Wed, 9 Dec 2020 12:05:49 +0000

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:[email-masked]] 
Sent: Wednesday, December 9, 2020 7:16 PM
To: Huzhibo <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Zhibo,

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.

> Flex-Algo path computation?

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

thanks,
Peter
> 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

---

From: Peter Psenak <[email-masked]>
Date: Wed, 9 Dec 2020 13:43:52 +0100

Hi Zhibo,

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

that is correct.

thanks,
Peter

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 9 Dec 2020 12:52:03 +0000

Hi Peter,

> Sent: Wednesday, December 9, 2020 6:45 PM
> To: Dongjie (Jimmy) <[email-masked]>; Acee Lindem (acee)
> <acee=[email-masked]>; lsr <[email-masked]>

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.

> 
> > 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?
> 

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.

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

Best regards,
Jie

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 9 Dec 2020 13:01:47 +0000

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:[email-masked]]
Sent: Wednesday, December 9, 2020 6:46 PM
To: Dongjie (Jimmy) <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; lsr <[email-masked]>
Subject: RE: WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Regards
Parag

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

Hi authors,

Best regards,
Jie

---

From: Peter Psenak <[email-masked]>
Date: Wed, 9 Dec 2020 14:05:41 +0100

Hi Jimmy,

On 09/12/2020 13:52, Dongjie (Jimmy) wrote:
> " 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: >

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.

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

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

not really, see above.

thanks,
Peter

---

From: <[email-masked]>
Date: Thu, 10 Dec 2020 10:13:02 +0800 (CST)

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,

that is correct.
 
thanks,
Peter

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 10 Dec 2020 12:03:33 +0800

Hello Peter,

follow-up questions with [Zhenqiang].

[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

[email-masked]
 
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,

 

 
yes they can.

not really, see above.
 
thanks,
Peter

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 10 Dec 2020 06:17:35 +0000

Zhenqiang -

In regards to:

<snip>
<end snip>

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 <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, December 09, 2020 8:04 PM
To: Peter Psenak <ppsenak=[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Hello Peter,

Best Regards,
Zhenqiang Li
________________________________
[email-masked]<mailto:[email-masked]>

From: Peter Psenak<mailto:ppsenak=[email-masked]>
Date: 2020-12-09 21:05
To: Dongjie (Jimmy)<mailto:[email-masked]>; Acee Lindem (acee)<mailto:acee=[email-masked]>; lsr<mailto:[email-masked]>
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:
>> To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee)
>> <acee=[email-masked]<mailto:acee=[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>

yes they can.

not really, see above.

thanks,
Peter

>>> *To:* lsr <[email-masked]<mailto:[email-masked]>>

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 10 Dec 2020 08:06:22 +0000

Hi Peter, 

> Sent: Wednesday, December 9, 2020 9:06 PM
> > " 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.
> 

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

> > 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"
> >
> > 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.
> 
> >
> plane,

---

From: Peter Psenak <[email-masked]>
Date: Thu, 10 Dec 2020 09:57:39 +0100

Zhenqiang,

On 10/12/2020 05:03, [email-masked] wrote:
> [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
>     *From:* Peter Psenak <mailto:ppsenak=[email-masked]>
>     *Date:* 2020-12-09 21:05
>     *To:* Dongjie (Jimmy) <mailto:[email-masked]>; Acee Lindem
>     (acee) <mailto:acee=[email-masked]>; lsr
>     <mailto:[email-masked]>
>      >>> Here is one comment following the previous discussion on the
>     mail list
>      >>> and the IETF meeting.
>      >>>
>      > " 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.
>      > 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"
>      >
>      > 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.
>      >

---

From: Peter Psenak <[email-masked]>
Date: Thu, 10 Dec 2020 10:04:31 +0100

Hi Jimmy,

On 10/12/2020 09:06, Dongjie (Jimmy) wrote:
> 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.
> 

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.

> 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 Fle…

absolutely not.

thanks,
Peter

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 10 Dec 2020 12:02:31 +0000

Hi Peter, 

> Sent: Thursday, December 10, 2020 5:05 PM
> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm)
> In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
> 
> Hi Jimmy,
> 
> >>>>> participation information, there is no separate TLV for IPv4 or
> >>>>> IPv6 Flex-Algo participation.
> >>>>
> >>>> the draft clearly says:
> >>>>
> >> IPv6 address advertised with Flex-Algo 128, it will not prune the
> >> nodes which participate in Flex-Algo 128 for IPv4 only from the
> > 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.
> >
> > - This node does NOT advertise IPv6 Flex-Algo reachability for FA 128. It may
> advertise normal IPv6 reachability in MT 2.
> >

OK, more precisely, this node cannot be used as the destination of a path in MT 2 with FA 128.

> 
> The node participates in MT2 and FA 128, as such it is reachable in MT2 in 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.

Agree that it can be used as a transit node, if its Flex-Algo participation is for both AFs.

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

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. 

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? 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

> >>>>> 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
> >> 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
> >>> 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.
> >>
> >>>
> >>>>> *From:*Lsr [mailto:[email-masked]] *On Behalf Of *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

---

From: Peter Psenak <[email-masked]>
Date: Thu, 10 Dec 2020 14:21:37 +0100

Hi Jimmy,

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

> 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

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 11 Dec 2020 08:17:27 +0000

Hi Peter, 

> Sent: Thursday, December 10, 2020 9:22 PM
> > "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

---

From: Peter Psenak <[email-masked]>
Date: Fri, 11 Dec 2020 10:13:10 +0100

Hi Jimmy,

> Let me elaborate with an example:

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 11 Dec 2020 10:15:57 +0100

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.

---

From: Huzhibo <[email-masked]>
Date: Fri, 11 Dec 2020 09:39:51 +0000

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:[email-masked]] On Behalf Of Peter Psenak
Sent: Friday, December 11, 2020 5:13 PM
To: Dongjie (Jimmy) <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; lsr <[email-masked]>
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:
>> always participate in a Flex-Algo for both IPv4 and IPv6, and for all 
>> the topologies it joins.
>>>
>> design, and whether some flexibility (e.g. AF specific or topology 
>> specific) would be useful in some cases.
>>>
>>
>> participation signaling. Please note that SRv6 support is signaled 
>> independently of FA participation.
>>>
>> 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.
> 

Option 1 is the right one, given the way things are defined. And honestly I do not see a need to change it.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Fri, 11 Dec 2020 10:58:31 +0100

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

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 11 Dec 2020 10:05:18 +0000

Hi Robert,

Please see inline:

From: Robert Raszuk [mailto:[email-masked]]
Sent: Friday, December 11, 2020 5:16 PM
To: Dongjie (Jimmy) <[email-masked]>
Cc: Peter Psenak <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Hi Jie,

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

---

From: Huzhibo <[email-masked]>
Date: Fri, 11 Dec 2020 10:06:52 +0000

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:[email-masked]] 
Sent: Friday, December 11, 2020 5:59 PM
To: Huzhibo <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Acee Lindem (acee) <[email-masked]>; lsr <[email-masked]>
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

>>> always participate in a Flex-Algo for both IPv4 and IPv6, and for 
>>> all the topologies it joins.
>>>>
>>> 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.
>>
>>> clarify how to prune the nodes which participate in the same 
>>> Flex-Algo for SR-MPLS only? Thanks.
>>>>
>>>> Best regards,
>>>> Jie
>>
>>
>>
>

---

From: Peter Psenak <[email-masked]>
Date: Fri, 11 Dec 2020 11:11:16 +0100

Zhibo,

>      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…

because FA has the concept of application and participation. That is 
however not equal to dataplane type.

thanks,
Peter

---

From: Huzhibo <[email-masked]>
Date: Fri, 11 Dec 2020 10:19:36 +0000

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:[email-masked]] 
Sent: Friday, December 11, 2020 6:11 PM
To: Huzhibo <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Acee Lindem (acee) <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Zhibo,

>      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…

because FA has the concept of application and participation. That is however not equal to dataplane type.

thanks,
Peter

> To: Huzhibo <[email-masked]>; Dongjie (Jimmy) 
> <[email-masked]>; Acee Lindem (acee) <[email-masked]>; lsr 
> <[email-masked]>
>> 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

---

From: Peter Psenak <[email-masked]>
Date: Fri, 11 Dec 2020 11:26:19 +0100

Zhibo,

>      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