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

[Gyan Mishra <[e-mail]>]

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 <[e-mail]> wrote:

>
> +1 for IP flex algo for operators toolbox
>
> Thanks
>
> On Thu, Dec 3, 2020 at 10:54 PM Jeff Tantsura <[e-mail]>
> 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 <[e-mail]> 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 <[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
>> <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>
>>
>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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