The MPLS WG Archive

[Erblichs <erblichs@earthlink.net>]

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

> Peter Ashwood-Smith wrote:
> 
>   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: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org]
> 
> Sent: Tuesday, October 12, 2004 4:26 AM
> To: Marc Binderberger; Jung Janos
> Cc: mpls@ietf.org
> 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 <marc@sniff.de> 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
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
> 
>     ---------------------------------------------------------------
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls