The MPLS WG Archive

[Erblichs <erblichs@earthlink.net>]

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

David Charlap wrote:
> 
> Erblichs wrote:
> >
> >       I would like to remind people that MPLS can not
> >       be used without IP, however IP can be used without
> >       MPLS.
> 
> 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.
> 
> >       IPvX is a end to end forwarding environment where
> >       MPLS is only a router to router forwarding
> >       environment.
> 
> 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.
> 
> >       MPLS, is normally associated within a domain
> >       so that the edge routers need specialized
> >       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.
> 
> >       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.
> 
> 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.
> 
> >       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.
> 
> 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.
> 
> >       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.
> 
> 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.
> 
> >       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.
> 
> 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
> 
> _______________________________________________
> 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