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

[Robert Raszuk]

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> 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
>
>