Subject: MPLS Performance analysis.....

From: Martin Cooper <[email-masked]>
Date: Wed, 31 May 2000 17:03:47 +0100

Sean Doran <[email-masked]> writes:

> Several people write:
> 
> > [lots of commentary about how wonderful MPLS is at making forwarding fast]
> 
> You are analysing the performance of MPLS using the wrong metric.
> I think MPLS performs exactly as intended.
> Ipsilon basically died, and not even Nokia could revive it.
> UUNET found a new layer-2 religion, essentially killing backbone ATM.
> Many companies are distracted from actually learning how to do IP routing.
> 
> Score: MPLS 3, Rest Of World 0.

As a relative newcomer to the church of MPLS (I have read
the prolific works-in-progress of AWD at any rate...), it
seems to me that the alleged performance benefits are not
so much supposed to be found in the label-switching over
packet switching paradigm-shift per se, but in the de-
coupling of end-to-end path-selection from the extremely
dynamic hop-by-hop routing information, and the more
stable re-routing of end-to-end constraint-based paths
thus enabled (but without ATMs slow-moving standardisation
process and bandwidth-overhead related baggage).

On the other hand, destination-prefix based IP routing
is quintessentially a hop-by-hop algorithm that doesn't
concern itself with end-to-end constraint-based path-
selection bar a few TOS bits, so maybe you care not
about CBPS?

M.

---

From: Sean Doran <[email-masked]>
Date: 31 May 2000 21:02:19 +0200

Martin Cooper <[email-masked]> writes:

> the de-coupling of end-to-end path-selection from the
> extremely dynamic hop-by-hop routing information

MPLS is a condensation of a GRE-like data-in-IP
encapsulation header, plus some related control planes to
lay out an SSR (strict source route) across a routed,
packet-switched network.

Perhaps it would be more precise to describe it as an
encapsulation header which is regenerated at each hop,
rather like a GRE-like packet whose header on the "head
end" (or ingress) router has an destination address of a
loopback address on an immediate neighbour router.  This
second router in the path removes the encapsulation header
and then re-encapsulates the data in a new GRE-like header
with a loopback address of the next router towards the
"tail end" (or egress) router, which will actually process
the data part.

Now use RSVP to coordinate the choice from a number of
loopback addresses to build a path out of a concatenation
of these tunnels, and tadah, you get a nastygram from one
of the high priests of MPLS that you have just reinvented
MPLS only with alot of extra bytes of overhead per packet.

When you point that the IP overhead lets one choose
between doing SSR ER and two different modes of LSR ER 
(both of which require router cooperation -- one mode
requires the decap-reencap dance above, the other merely
processing of the LSRR option), you may end up in a nasty
fight, being reminded that one of the reasons people don't
like ATM is that there is lots of overhead.

Of course, the model for VPNs is relatively little traffic
at much higher than normal cost compared to best-efforts
Internet transit connectivity, so the overhead doesn't
seem to matter much.  Also, not everyone needs to do
heavy duty TE on huge-volume traffic, and thus can choose
the operational overhead of deploying MPLS versus the
per-packet overhead of a GRE-like encapsulation header.

Another neat detail that annoys MPLS folks is that
if you do not keep your encapsulation header's IP ttl
tiny, you don't have to do an RSVP song and dance or
play the pre-provisioned-back-up-path game, and suchlike.
Great for VPNs, where you don't really need to do ER at
all, you just want to isolate the inside data from the
routers in the "core".

> the more stable re-routing of end-to-end
> constraint-based paths thus enabled

You are emulating a circuit-switched network on a
packet-switched one, no matter how you slice things;
if your underlying logical layer in a hybrid MPLS/IP
core changes, both MPLS and IP have to reconverge,
and this is generally not so ships-in-the-night (i.e., 
typically MPLS is reliant upon the topology discovery
protocol IP uses).  Extra stability here can only come
through a time-to-converge trade-off.

As some else said: MPLS is L3, not L2.

> is quintessentially a hop-by-hop algorithm 

How is MPLS any different?

>(but without ATMs slow-moving standardisation

Ah, you're new to the IETF, too?  Welcome!

        Sean.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 31 May 2000 15:29:37 -0400

Sean> you get a nastygram from one of the high priests of MPLS that you have
Sean> just reinvented  MPLS only  with alot of  extra bytes of  overhead per
Sean> packet.

I  think that  what the  nastygram would  actually say  is that  you haven't
really invented or reinvented anything  yet, but that when you actually work
out all the details, you will not only find that your encapsulation overhead
is  five times  as  large, but  that you  end  up with  no less  operational
overhead and probably with considerably more.

But of course, time will tell ...

---

From: "Brijesh Kumar" <[email-masked]>
Date: Wed, 31 May 2000 16:09:31 -0400

In his previous message, Sean Doran writes

> -----Original Message-----

You are absolutely right.

When MPLS work started the enhancing the speed of IP route look up was a key
motivator behind the technology.  IP route look up speed no longer being an
issue in core gateways, it doesn't really matter if you provision your
source routes using CR-LDP for certain traffic (or whatever else you have),
or by going to each router in the network and creating suitable entries
(manually or auto-magically under the control of a TE process) in the
routers so that a particular class of traffic goes over a statically
configured path. If there are no  traffic engineering requirements, as you
rightly pointed out, MPLS will not bring any additional benefits that can't
be provided using other technologies. But the core assumption is, lots of TE
is required.

Cheers,

--brijesh

---

From: Jeremy Lawrence <[email-masked]>
Date: Thu, 01 Jun 2000 11:58:59 +1000

At 16:09 05/31/2000 -0400, Brijesh Kumar wrote:
[...]

>motivator behind the technology.  

Not really, except in the mind of certain marketers who yelled
"[Company X] is only doing MPLS because they can't get their
routers working fast enough". Company X, in the meantime, knew
that MPLS was only a marginal performance improvement over a
good IPv4 longest-prefix match implementation. :)

There is one grain of truth in that fast IPv6 longest-prefix match
algorithms are harder to come by, and MPLS was considered as
a solution to that problem.

Jeremy