The MPLS WG Archive

[richard.spencer@bt.com]

Mitchell,

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

This doesn't help anyone if your generalisations are incorrect.

> 	Yes, LDP leans routes, however, the LDP keeps
> 	the same routes until explicitly torn down.

LDP is a signalling protocol used to signal MPLS labels associated with FECs, it does not learn routes. Routes are learned via a dynamic routing protocol, e.g. OSPF, or may be statically configured. LDP keeps labels (not routes) until a next hop changes, e.g. following link loss, routing protocol session loss, router failure, or if a better next-hop becomes available, etc.
 	
> 	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. 

I don't understand the relevance of this statement. Are you suggesting that if the routing protocol is unstable then LDP somehow improves things? If so how? Bearing in mind that LDP tracks the IGP, i.e. if the IGP next hop changes then so does the LDP LSP.

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

I don't understand this statement at all. If the routers are in the MPLS domain and not OSPF enabled then are they running another routing protocol or are they statically configured? Obviously if there are less routers in an OSPF domain then it is likely to converge faster, but what has this got to do with MPLS or LDP?

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

Faster in what respect?
What is it that is more efficient?
What does higher achievable bandwidth mean?

This statement has no value unless qualified with the specific MPLS techniques/protocols used. For example, fast failover is dependant on the protocols used and how they are deployed, just because an network uses MPLS does not automatically mean that it is recovers from failure faster than an IP network. 
	
> 	And i'm a little confused:
> 
> 	  * Are you saying that that a strict MPLS LSP
> 	  path can be duplicated with OSPF? 

OSPF is a dynamic routing protocol where paths/routes change following topology changes so obviously paths/routes are not strict, they are dynamic. However, the story doesn't end there, if you are configuring strict LSPs for TE purposes then IGP metric tuning can be used to engineer the network to use bandwidth efficiently, as can ECMP. The primary reasons for using TE tunnels is to support per tunnel CAC and to support FRR.

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

No, I do not believe David said that. He simply said that you don't have to use MPLS to do this, reading the sentence before the one you quote tells you this, i.e. "In conventional forwarding, this requires the packet to carry an encoding of its route along with it ("source routing"). 

Regards,
Richard

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

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