[c-nsp] Rant: ASR1000 MPLS (not) load-balancing

[Robert Raszuk]

First most of the ASICs or NPs you get do just fine LEM or LPM at their
line rate. And while processing wise they may be more cycles to do LPM your
invoice amount for box is still the same :) I guess one vendor tried to do
pure LEM box ... but you know the story there.

Then consider smart LPMs like Arista FlexRoute .. the advantages of LEM
here are getting very marginal for the significant cost of control plane
complexity.

Best,
R.

On Thu, Jan 2, 2020 at 4:19 PM Saku Ytti <saku at ytti.fi> wrote:

> On Thu, 2 Jan 2020 at 17:08, Robert Raszuk <robert at raszuk.net> wrote:
>
> > But for me from the perspective of number of years passed by I think
> using MPLS transport is just a one big mistake.
>
> Pistols at dawn, I drank the kool aid and it's good.
>
> > MPLS for service demux is great, but I really see no advantages in using
> LDP or even concept of global labels for transport. IP transport be it IPv4
> or IPv6 offers  much more advantages, native summarization UDP or flow
> label adds a lot of entropy while MPLS service label can still sit happy
> behind.
>
> We need tunneling, that much is clear, what the tunnel bytes exactly
> are, is not very interesting to me, as long as there are as few of
> them as possible. Toy idea from some 6 years back
> https://ytti.fi/mplsv2.txt
>
> > If you need TE - it seems pretty trivial to do that with either IPv6 or
> IPv4 encapsulation too.
>
> I see no upside. Exact match MPLS is on-chip LEM, which is cheap, this
> is good, tunneling should be exact match LEM lookup. IP is LPM, it's
> fundamentally more expensive. Not to mention too many bytes, so you
> need more overspeed for given edge rate.
> Minimum amount of excess bytes, LEM table lookup, these are
> fundamental requirements for ideal tunneling mechanism, tunneling is
> needed. If it's MPLS or what ever is not important, but IP is
> blatantly worse.
>
> --
>   ++ytti
>