[c-nsp] Seamless MPLS interacting with flat LDP domains

[adamv0025 at netconsultings.com]

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 <robert at raszuk.net> 
Sent: Tuesday, April 30, 2019 4:27 PM
To: adamv0025 at netconsultings.com
Cc: Mark Tinka <mark.tinka at seacom.mu>; Cisco NSPs <cisco-nsp at puck.nether.net>
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 <adamv0025 at netconsultings.com <mailto:adamv0025 at netconsultings.com> > 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