The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-May> msg00386



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

MPLS Performance analysis.....

  • From: Martin Cooper <mjc@cooper.org.uk>
  • Date: Wed, 31 May 2000 20:42:31 +0100
  • Cc: mpls@UU.NET

Sean Doran <smd@ebone.net> writes:

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

I must say that I visualise TE-tunnels as a lot of GRE
tunnels with static routes on each router nailing the
next-hops down, and with a control plane to change the
statics for provisioning.

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

Assuming Cisco kit though, don't IP packets with options
get punted by CEF to the process-switching path, or am I
thinking of non-CEF IOS versions?

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

I'm not sure I buy this -- are you sure that's how it
works? I was under the impression the hop-by-hop path
of a tunnel was somehow nailed down at each hop (like
you might want to with an EBGP-multihop peering route)
to prevent routing instabilities ripping up your pre-
established paths?

> How is MPLS any different?

Well, given the above uncertainty? Certainly it sounds
a bit unstable if the TE-tunnels have to rely on local
routing-table convergence before they can be used for
traffic.

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

Rough consensus and working code so I hear...
sounds good if that's really how it works... :-)

M.