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

[Robert Raszuk]

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 <adamv0025 at netconsultings.com> 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 <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> 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
>
>