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

[Gyan Mishra <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>, 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> 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