Subject: RE: [mpls] mpls vs IPv6

From: "Peter Ashwood-Smith" <[email-masked]>
Date: Tue, 12 Oct 2004 08:05:18 -0400

You are correct that many of the original motivations for MPLS are no
longer really valid.
Forwarding speed as you point out is less relevant; Encapsulation can be
done other ways such that MPLS would only be required at the service level; 

  The one thing that you cannot easily do without label substitution
forwarding is non shortest path forwarding. If you ever want a subset of
your traffic to diverge from the routes IP would give, you either have to:

   A) use source routing (stateless).
   B) use label substitution (statefull).
   C) Create multiple instances of another hop-by-hop protocol i.e multiple
forwarding tables and a way to figure out which one to use, i.e. DHCP/flow
etc. could key which table .. 

  This is of course true regardless of the address size or how QOS is
implemented per hop. Right now B) seems the most practical option although
with bandwidth getting cheaper by the nanosecond it can't be long before new
forms of A) arrive.

  Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, October 12, 2004 4:26 AM
To: Marc Binderberger; Jung Janos
Cc: [email-masked]
Subject: Re: [mpls] mpls vs IPv6

May I be bold enough to ask the reason MPLS was ever
deployed?

some more queries inline.>

--- Marc Binderberger <[email-masked]> wrote:

> Hello,
> 
> > With MPLS I can create MPLS VPNs, QoS can
> (really?) be
> > granted to packet flows, and routing is more
> faster.
> 
> Forget about the "faster". Today the forwarding
> happens either in
> hardware and is wire-speed for IPv4/IPv6 as well. Or
> it's the same 
> underlying mechanism in software, e.g. the "CEF"
> table in Cisco 
> routers.
> 

And how many such end addresses are there? Do we need
to throw out the existing gear to move to IPv6?

> QoS for MPLS is in first place the same as for
> IPv4/IPv6. You have 3 
> bits, like the (old) IPv4 Precedence. In theory more
> QoS information 
> could be coded in the label, of course.
> 
> > IPv6 has the "Flow label" field wich makes routing
> faster
> 
> again, the "faster" doesn't matter with today's
> ASICs in place.
> 

But then tomorrow's ASICs will be faster than today's
so why not wait for tomorrow :)) till they are built
??

> > and has less header overhead than ipv4 (or
> mpls+ipv4)
> 
> n*4+20 vs. 40 - less overhead?
> 
> > And i think flow label could have the same use as
> > the mpls label value...
> >
> > How is MPLS to IPv6 related?
> 
> as already answered: the same as MPLS to IPv4.
> Well, there is always a difference between theory
> and implementation. 
> MPLS needs LDP (and RSVP depending on what you do),
> LDP uses IP UDP and 
> TCP. Although informations within are "TLV" coded
> and thus expandable I 
> haven't seen any IPv6-based LDP on my Cisco so far.
> Read: you may have 
> IPv4 to run protocols like LDP to finally run MPLS
> carrying IPv6 
> packets.
> 
> > Are they technologies that have nothing to do with
> each other?
> 
>  From a generic point of view: correct.
> 
> > Or MPLS can bring new functionalities to IPv6
> networks (like to IPv4), 
> > and
> > so mpls+ipv6 would have a sense?
> 
> exactly. Hope I don't start a religious war now but
> look upon IPv6 as 
> an IPv4 with larger addresses, a more structured
> approach to "ip 
> options", avoiding fragmentation (on transit
> routers) and such. In 
> short: more addresses ;-)
> 

> Same as for IPv4: TE capabilities, allows you to
> integrate ATM into 
> your IP packet network, [...].
> 
But why woould I need ATM then?

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Loa Andersson <[email-masked]>
Date: Tue, 12 Oct 2004 15:30:36 +0200

All,

here we go again ;)

It is one of the "popular" misconceptions that mpls ever
was intended to improve node capacity.

If you go back to the problem statement from IETF 38
(Memphis April -97) you will find that there were
four items in the problem state node performance
was not one of them. Network performance were, but
that had nothing to do with the throughput of the
routers (nodes) but with the ability to load more
traffic on to the network. A couple of meetings later
we extended the "performance" conceot and started to
call it "internet traffic engineering".

I remember people coming up to me in Memphis and
Munich (and later) trying to explain that routers did
forward at line speed and consequently mpls was not
needed. They were rather surprised when I agreed on
the line speed, but pointed out that mpls were not
intended to solve that non-problem.

/Loa

Peter Ashwood-Smith wrote:

>    C) Create multiple instances of another hop-by-hop protocol i.e 
> multiple forwarding tables and a way to figure out which one to use, 
> i.e. DHCP/flow etc. could key which table ..
> 
> implemented per hop. Right now B) seems the most practical option 
> although with bandwidth getting cheaper by the nanosecond it can't be 
> long before new forms of A) arrive.
> 
>   Peter
> 
> 
> ------------------------------------------------------------------------
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

---

From: Erblichs <[email-masked]>
Date: Tue, 12 Oct 2004 12:25:43 -0700

Group, et al,

	I would like to remind people that MPLS can not
	be used without IP, however IP can be used without
	MPLS.

	IPvX is a end to end forwarding environment where
	MPLS is only a router to router forwarding
	environment.

	MPLS, is normally associated within a domain
	so that the edge routers need specialized
	features; i.e. translate IP headers into lables.

	Since routers within the MPLS doamin don't need the
	edge router capability, I would expect that this
	non feature could minimally reduce the cost.

	FYI, it may just be me, I haven't seen a
	non core router able to have a full window of
	echo size (ping) pkts/segs that could transit
	at 10Gb/sec over all of its interfaces at the
	same time at wire-speed. Yes, this is a worse
	case test. Now lets have multicast dsts.

	IMO, a still important item that has been overlooked
	is the convergence time of some of the larger link-state
	environments and/or the newer wireless paths. I think
	that the label distribution mechanisms within MPLS
	probably are more efficient and can set up the
	paths quicker. This relates to fewer delays and
	lost pkts while routing environments are somewhat 
	chaotic.

	Also, the link state protocols (ISIS and OSPF)
	assume that ONE path is preferred, and this translates
	to adding single entries for a dst in the forwarding
	table.

	With MPLS, it is possible to have numerous
	paths to a dst where non-equal paths exist. This
	would allow a set of equal dst pkts (FEC) to traverse
	different paths based on different characteristics.
	These characteristics could be different ISP
	origination src addrs, bandwidth, delay, priority,
	SLAs, etc.

	Lastly, I am not sure that routing can NOT be "faster"
	in a MPLS environment. If I would be able to separate
	flows and label them, I should be able to know when
	a grouping of pkts is such that buffers in later
	routers would reach RED or tail-drop and later
	result in a congestion avoidance (CA) state if
	a transport protocol like TCP was involved. Yes,
	this presuposes that the bottleneck was within the
	MPLS domain and that I would prefer and capable to
	buffer up extended data flows vs allowing CA
	to occur.

	However, if the MPLS was sufficently faster in
	forwarding, I would expect that when a a sufficient 
	number of in-flight pkts/segments occurs when exiting 
	the MPLS domain that this would "back-up" and force CA
	in IP/TCP environments.

	Mitchell Erblich
	------------------

>   You are correct that many of the original motivations for MPLS are
> no longer really valid.
> Forwarding speed as you point out is less relevant; Encapsulation can
> be done other ways such that MPLS would only be required at the
> service level;
> 
> forwarding is non shortest path forwarding. If you ever want a subset
> of your traffic to diverge from the routes IP would give, you either
> have to:
> 
>     ---------------------------------------------------------------

---

From: David Charlap <[email-masked]>
Date: Tue, 12 Oct 2004 16:17:50 -0400

> 	be used without IP, however IP can be used without

This is not entirely true.  Although MPLS is almost always used in 
conjunction with IP, it doesn't have to be.  For instance:

- LSPs can be configured instead of signaled (much like how PVCs are
   configured on ATM switches.)

- Routing/topology information may be distributed using a non-IP routing
   protocol, like IS-IS.  (Although IS-IS is usually used to distribute
   IP topology information, it uses ISO addresses, not IP addresses.)

- Although today's MPLS signaling protocols (LDP and RSVP-TE) are both
   tied to IP addressing, there is no reason why a non-IP signaling
   protocol couldn't be developed for setting up LSPs.  (For that matter,
   RSVP-TE could even be extended to allow signaling over non-IP networks
   (it would only require new C-Types for the SESSION, SENDER_TEMPLATE
   and FILTER_SPEC objects and a few new subobjects for the
   EXPLICIT_ROUTE and RECORD_ROUTE classes.)

- Non-IP traffic may be (and sometimes is already) carried in LSPs.  In
   RSVP-TE, the layer-3 protocol is signaled in the SESSION_ATTRIBUTES
   object.  For layer-2 LSPs, an extra label (Martini or PWE3) may be
   used to identify the traffic.

> 	MPLS is only a router to router forwarding

Conventionally, yes.  But there's no technical reason why a host 
couldn't drive LSP creation.  It isn't done because there isn't any need 
for this, not because of any technical problems.

> 	features; i.e. translate IP headers into lables.

Domain?  What exactly do you mean by this?  In the IP/internet world, a 
domain is a DNS term that has no applicability to routing/signaling.

In the ATM world, it refers to a group of routers that share routing 
information together.  The closest IP analog to an ATM domain would be 
an autonomous system (AS).

Although MPLS networks typically do not span across ASs, they can, in 
theory.  There is ongoing work to develop practical ways to make this a 
practical reality.

You are correct, however, that LERs (LSP edge routers) need the 
capability to push/pop labels onto/from unlabeled packets.

> 	non feature could minimally reduce the cost.

This was a concern in the not-too-recent past.  Especially when using 
MPLS software to retrofit legacy ATM gear (interfaces on ATM switches 
typically don't have the capability to push/pop labels.)  Today, 
however, this is less of a concern, since all the major MPLS players are 
making hardware with this capability.

> 	lost pkts while routing environments are somewhat 

MPLS, in a signaled environment, relies on an IGP.

LDP allocates and distributes labels as routes are learned.

RSVP-TE can't set up an LSP until routing converges.  Either the ingress 
node must compute a path to the destination or all the transit nodes 
must be able to forward the Path messages to the destination using local 
route tables.

You can, of course, pre-configure LSPs to get around this, that 
undermines many of the benefits of MPLS.

> 	to adding single entries for a dst in the forwarding

Not necessarily.  Equal-cost multipath extensions are common in the 
non-MPLS world.  Providing alternate routing paths where they're not all 
equal cost is uglier, of course.

> 	origination src addrs, bandwidth, delay, priority,

You can do this without MPLS, but it requires all your routers to 
classify all the packets and classify them according to the same set of 
rules.  It's inefficient (and probably will limit your throughput) but 
it can be done.

The big deal about MPLS isn't that you can do anything new, but that all 
of the work in classifying the packets is focussed entirely in the edge 
router (where bandwidths are probably lower) so that the core (where 
bandwidth is higher) doesn't have to do this work.

-- David

---

From: Erblichs <[email-masked]>
Date: Tue, 12 Oct 2004 17:43:36 -0700

David and group,

	Yes, basicly we are on track.

	I was trying to generalize about arch and
	implimentations within the equiv of a 1 pager
	and and not try to write a book on the diffs.
	People can read all the RFCs if they want book 
	format!

	(Domain) MPLS domain is bounded by ingress / outgress
	label edge router (LER) where the LSP is not
	necessarily determined by the contents of the IP header.

	However...

	I don't see how a OSPF pkt could recv a
	different path (when only 1 best LS path exists)
	other than the best path chosen for it by the
	SPF algorithm.

	Same for IS-IS?

	Same for RIP?

	BGP probably could have unequal paths due to
	the different RIB, filters, etc..

	Yes, LDP leans routes, however, the LDP keeps
	the same routes until explicitly torn down.
	
	In a chaotic IP forwarding env, if the routes
	constantly change and the in-flight pkts/segments
	are backed by TCP, their will be constant 
	re-ordering of the segs. Most implimentations
	will respond with the re-ordering by seeing
	3 duplicate acks and will do un-necessary
	fast re-transmits / spurious rexmits. In addition
	to consuming bandwidth, convergence time, etc,
	at the the time of the fast re-xmit, most
	implimentations will assume congestion and back-off
	to maybe slow-start. 

	Also, If the routers that had the flapping routes
	were in the MPLS domain and not OSPF enabled, then the
	OSPF area would be less chaotic. The fewer routers
	participating in the OSPF area would tend to have
	faster initial database synchronizations, etc.
	Sorry, group, this is condensed book format.

	Bottom line, in my experience MPLS tends to be
	faster, more efficient, higher achieveable bandwidth,
	etc, in a number of different envs including chaotic
	ones.

	And i'm a little confused:

	  * Are you saying that that a strict MPLS LSP
	  path can be duplicated with OSPF? 

	  * Are you saying that the forwarding decisions
	  / advantages the 3rd bullet of MPLS in RFC 3031
	  is not true?
	"This can not be done with converntional forwarding,
	since the the identify of a packet's ingress router
	does not travel with the packet".

	Mitchell Erblich
	----------------

---

From: David Charlap <[email-masked]>
Date: Wed, 13 Oct 2004 10:16:15 -0400

Richard Spencer wrote many good comments which I won't duplicate in my 
reply.  Following are my comments.

> 	other than the best path chosen for it by the

SPF may select more than one path.  That's the whole point of ECMP - you 
use the topology learned by routing and select all of the shortest 
paths.  The forwarding system can choose to use this information to do 
load balancing.

> 	Same for IS-IS?

Yes.

> 	Same for RIP?

Yes, but for obvious reasons, the concept of a "path" (best or 
otherwise) isn't meaningful in a RIP network.

> 	the same routes until explicitly torn down.

Read it again.  It installs labels onto FECs.  It learns FECs from an 
independant routing protocol.

> 	  path can be duplicated with OSPF? 

Not with OSPF alone, but it can be done without MPLS.  That's the point 
of source routing.  (Admittedly, source routing is inefficient.  I don't 
think any forwarding chips today process this IP option.)

> 	does not travel with the packet".

Please read my statements in context.  I was referring to this staement 

>>>      origination src addrs, bandwidth, delay, priority,

Without MPLS, you can also have numerous paths to a destination with 
non-equal paths.  You use the same topology learned by routing (OSPF or 
ISIS - RIP doesn't learn any topologies) and run the SPF calculations on 
subsets of that topology, based on whatever packet classification 
filters you like.  This is the definition of CSPF.

As long as all of the routers have the same sets of filters/criteria 
configured, you'll get consistent routing, with different categories of 
packets going in different directions.

MPLS makes this job much easier (by eliminating the need for all your 
core routers to do all this clarrification), but it isn't the only way 
to get the job done.

-- David

---

From: Claus Gruber <[email-masked]>
Date: Wed, 13 Oct 2004 13:05:56 +0200

Hello group,

>	  path can be duplicated with OSPF? 
In OSPF and its extension ECMP (Equal Cost Multi Path) multiple paths 
towards one destination IP address are possible. The traffic is 
distributed equally. I.e. if there are three shortest paths (equal 
length) traffic is distributed 33%/33%/33% on outgoing interfaces. The 
traffic is distributed using a flow-based hash function ('per 
destination') to keep the ordering of packets of one flow (TCP problem) 
or in a round robin manner ('per packet').

Using the configurable OSPF link weights many MPLS paths can be 
duplicated with OSPF. However, MPLS has the advantage to distinguish 
packets (treat differently)  towards the same destination IP address 
that are entering the network at different edge routers. Additionally an 
unequal traffic distribution on multiple (not shortest) paths is possible.
(Note: A different routing for packets belonging to differnt type of 
service classes was included in OSPF v1 but is no longer included in 
OSPF v2 RFC)

With this, MPLS has an advantage considering traffic engineering. 
However, if a network operator optimizes the OSPF link metrics the 
difference is not that big for working traffic (without a failure). I 
did some optimizations both for ECMP and MPLS indicating this.

However, I think the main advantage of MPLS is the possibility for 
resilience. OSPF as well as IS-IS or RIB, ... are distributed protocols. 
In case of a network element failure it takes some time until failure 
notifications (LSAs) are broadcast and all routers have updated their 
forwarding table (with transient effects: loops).
When tuning timers it is however possible to reduce the convergence time 
of OSPF or IS-IS to some hundred milliseconds even for larger networks. 
I did simulations and I think SPRINT reported sub-second convergence 
times with patched Cisco routers already.

With MPLS one is able to prepare for a failure and establish backup 
paths in advance of possible failure patterns (e.g. Fast Reroute 
configuration). This is - at least to my knowledge - not possible with 
OSPF since it is a distributed protocol and there is only one valid 
forwarding table in a router. MPLS thus, is able to react locally and 
prepared (backup path already defined - "protection') upon failures 
which is of course faster (some tens of ms) than a distributed 
restoration approach.

The main advantage is the distribution of the backup traffic. After 
failure detection and rerouting new paths are calculated according to 
the old link metrics in OSPF. These metrics however were adapted for 
working traffic and might not be well fitted for the new (reduced) 
topology. MPLS backup paths can be chosen independently of the working 
paths (without a failure). Optimization results showed that MPLS has 
advantages considering required capacity.

And: A (good) optimization of link metrics and MPLS paths takes its 
time. In MPLS this can be performed offline for probable failure patterns.
If one might change an MPLS path this path is affected only. When 
changing OSPF link metrics routes towards different destinations are 
changed and cannot be changed only for one destination or for one 
ingress-egress relation. This makes optimization and TE more complex.

As a summary:

- MPLS has potentially shorter convergence times (allows local protection).
- Not much difference in TE for working traffic results (at least as far 
as I calculated and know)
- MPLS allows an independent traffic engineering for resilience issues 
(including failure patterns)
- Adaptive traffic engineering is possible without potentially changing 
a lot of routes towards multiple destinations.
- Forwarding is 'wire speed' both for IP and MPLS today.
- Virtual Private Networks (VPNs) are easy to deploy with MPLS.
- MPLS paths traversing multiple ASs are in development.
- MPLS Multicast is in development.

As a drawback: MPLS is an add-on technology and if not configured static 
a kind of IGP to detect topology is required. Paths have to be refreshed 
and additional switching tables are required in each router.

Sprint has some very nice white papers (to be found on their homepage): 
Summary: MPLS is good and has advantages - currently we can do what we 
need and want with tuned OSPF.

It depends on the requirements... but MPLS has many advantages.

Regards,
Claus

-- 

______________________________________________________________________

Claus Gruber
Institute of Communication Networks    Phone: +49 89 289 23508
Munich University of Technology        Fax:   +49 89 289 23523
Building 9, Room 1932                  mailto:[email-masked]
Arcisstr. 21, D-80290 Muenchen         http://www.lkn.ei.tum.de/~claus
______________________________________________________________________