+1 for IP flex algo for operators toolbox Thanks
On Thu, Dec 3, 2020 at 10:54 PM Jeff Tantsura <[email protected]> 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 <[email protected]> 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 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 > <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
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
