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 <hayabusa...@gmail.com> 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 <jefftant.i...@gmail.com> 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 <rob...@raszuk.net>, 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 <tony1ath...@gmail.com> 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 >>> Lsr@ietf.org >>> https://www.ietf.org/mailman/listinfo/lsr >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > -- > > > Gyan Mishra > Network Solutions Architect > M 301 502-1347 > 13101 Columbia Pike > Silver Spring, MD >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
