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