Hehe I somehow sensed you are going to say that .. and yes I hope I did not sound like someone saying that TE all together is useless - after all I still remember delivering TE tutorial in Nanogs :)
But as always we should at least try to aim to use rigth tools for the job. So node-link protection - my take is use LFA. With SR and sparse topology got for TI-LFA. Hope you meant such "TE" and not one hop RSVP-TE LSPs :) To move flows out of the shortest path - oh yes - in fact I am deploying one global project now with live-live which only requirement is that 2nd live should not go over SPF path. And guess what - none of the TE code in any vendor can do it ! Clearly I do not want to build two topologies as if I would my primary live stream would get limited room. So I am doing that with OTT TE ... if you like to know more ping me offline. I am not sure if I can say in public what two software solutions I am using for it :) Moving elephants is indeed always fun ! Typically it started with TV channels now there is more of those animals. Yes you need TE for that. Most sexy of the day is SR .. but I would also consider Vector Routing if you want to do that in control plane only. Cheers, R. On Tue, Apr 30, 2019 at 11:52 PM <[email protected]> wrote: > Hey Robert, > > > > Common you know better than me there are cases where TE is inevitable (to > get that node-link protection over there, to move the PW out of the > shortest path, to move one of the elephant flows from the overloaded leaf > to spine link to another, etc... Sometimes “throwing more BW at the > problem” isn’t the optimal (or most cost efficient) solution. > > > > Yes I agree that MPLS has nothing to do with TE, hence I specifically > avoided suggesting any technology or solution for getting me TE capability > in IP :) > > Remember when we used to do “no ip source-route” or “ip option ignore” … > > > > adam > > > > *From:* Robert Raszuk <[email protected]> > *Sent:* Tuesday, April 30, 2019 4:27 PM > *To:* [email protected] > *Cc:* Mark Tinka <[email protected]>; Cisco NSPs < > [email protected]> > *Subject:* Re: [c-nsp] Seamless MPLS interacting with flat LDP domains > > > > Hey Adam, > > > > > Get me the TE capability and then I might consider switching. > > > > You hit the nail on its head :) ... And in fact with mpls hammer too ! ;) > > > > See this is what anyone I talk with says - how do I do TE ? /* Then I ask > how much TE do you need and they stop talking about it as TE is really at > the end of the day a sign of weak bandwidth provisioning model and > workaround for it */. > > > > *But MPLS LDP transport has zero in common with RSVP-TE or SR-MPLS TE.* *Just > like MPLS label used as demux in L3VPN or L2VPN has nothing in common with > similar 20 bit MPLS label used for transport. Not you, but many folks do > not get this huge overload of pretty orthogonal MPLS label use cases at > various layers. It has never been "all or nothing". * > > > > If you need TE (full, dense or sparse) use any of the above technology and > the fact that you are engineering IP packets vs MPLS LDP packets does not > make it any different. In fact most of TE classification engines handle > much easier IP then MPLS :) so one can argue that TE with IP flows is > easier. > > > > See the crux of the history is that we rolled out tag switching then MPLS > transports simply due to the fact that at that time 1998-1999 platforms did > not support line rate of any IP encapsulation (ex: GRE). And encapsulation > was necessary to hide L3VPN packets with overlapping addresses in your > core. Recall GSRs where only Engine 0 LCs could do it as all processing > was done in LC CPU ? :) > > > > Now some vendors heavily invested in their hardware to do MPLS switching > and naturally they will protect their investments. Business reasons not > technology. In fact some gave up on deep IPv6 header support as they > believed that all they need is N x 20 bit juggling. But this is not about > religion to move back to pure IP transport. It is about making the network > summarization work again - without need for more hacks and layers - which > this "seamless mpls" is a pure 999,9 example of :) > > > > Best, > R. > > > > > > > > > > > > On Tue, Apr 30, 2019 at 5:04 PM <[email protected]> wrote: > > > Robert Raszuk > > Sent: Tuesday, April 30, 2019 3:01 PM > > > > Yes Mark ... numerous both in WAN and DC space. > > > > In fact entire Contrail was based on L3VPN over UDP/IP too. > Unfortunately, > And they were soooo close in getting the right answer. (much better than > the > VXLAN bunder -and all the stupid extensions to that in order to attempt to > match what comes naturally with L2VPNs using MPLS) > So yes even with Contrail I'd still need to have PEs at the edge of the DCs > doing stitching between "DC MPLS" and MPLS-CORE MPLS (and doing > recirculation at PFE "tunnel-services" -so much for vendor support). > With no prospect of simple and automated end to end traffic-engineering > from > a DC to other DCs/Eyeballs/Internet-Edge > Not mentioning I could have had a single SDN controller... > > > So is EVPN in > > number of real life deployments. > > > > All vendors support it too, but their marketing is scared that they will > loose > > $$$ as it will open much easier market penetration by new vendors so they > > like to keep you tight to LDP :) > > > Get me the TE capability and then I might consider switching. > > adam > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
