And I remember reading you Nanog TE tutorial as my introduction to TE :)
I see you mentioned SR on couple of occasions below, in light of MPLSoIP I assume you mean the IPv6 variant. However then we venture onto thin ice in terms of efficiency arguments because once could fit 4 MPLS labels behind IPv4 header and still be within the bounds of a simple IPv6 header -not to mention v6 extension headers. But I take your point about aggregation in light of the OP’s question, if case being a small FIB boxes in the access then aggregation makes a difference indeed. adam From: Robert Raszuk <[email protected]> Sent: Tuesday, April 30, 2019 11:03 PM To: [email protected] Cc: Mark Tinka <[email protected]>; Cisco NSPs <[email protected]> Subject: Re: [c-nsp] Seamless MPLS interacting with flat LDP domains 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] <mailto:[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] <mailto:[email protected]> > Sent: Tuesday, April 30, 2019 4:27 PM To: [email protected] <mailto:[email protected]> Cc: Mark Tinka <[email protected] <mailto:[email protected]> >; Cisco NSPs <[email protected] <mailto:[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] <mailto:[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/
