The MPLS WG Archive

[Giles Heron <giles@packetexchange.net>]

On Mon, 2002-06-03 at 10:26, neil.2.harrison@bt.com wrote:
> Ajay,  Let me take you back to the point of Shahram's orginal
> question.....which in essence, if I have understood it correctly, was 'what
> problem/application is LDP solving/addressing that cannot be done either (i)
> using IP directly or (ii) ER LSPs?'.....and which must also take a wider
> pro/con analysis of the implications of using LDP-LSPs vs ER-LSPs (or IP
> directly).
> 
> Please also see below.   Regards, Neil
> 
> Ajay Simha wrote 01 June 2002 04:15
>  
> > The point is MPLS effectively decouples the forwarding 
> > portion from the
> > routing.
> NH=> Well I agree, this is vital and it's what is needed.  And it's
> something we in Telco-land have known/used for years, ie decoupling of the
> traffic carrying data-plane and its control-plane (both its own data-plane,
> where appropriate, and its routing and signalling protocols).  But LDP does
> nothing more than instantiate labels per hop that are locked to the IGP.
> That is (i) they take the same SPF routes as the IGP would use for IP
> fowarding and (ii) the LSPs change as the IGP changes.  I would argue this
> is not a required behaviour for applications where LSPs are long-holding
> and/or must not be affected by ad hoc routing changes or failures of routing
> protocols (eg VPNs).  Further, because LDP is so tightly coupled to the IGP
> then one has to introduce 'layer violations' to make it work a bit better,
> eg Load-balancing using IP-level hashing......its hard to take seriously
> anyone claiming this is MPLS label forwarding when one has to look at the
> client/IP level (which it may not always be, ie XoverMPLS) to make
> switching/forwarding decisions.
[rest snipped]

not at all.

The decision as to what set of outbound interfaces to use to forward the
packet is made entirely using MPLS.

The decision as to how to hash traffic over that set of outbound
interfaces may be made entirely using MPLS (e.g. by using the next label
in the stack - if present), or may be made using information from the
next protocol layer.  Note that load balancing is an entirely local and
value-added behaviour.

Note also that load balancing using information from the next protocol
layer is a common technique in clns networks.  Many "layer 3" Ethernet
switches support IP-based load-balancing when switching traffic at
"layer 2".

Giles

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================