The MPLS WG Archive

[Eric Osborne <eosborne@cisco.com>]

On Mon, Jun 03, 2002 at 11:26:06AM +0100, 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).


LDP lets you easily integrate IP and ATM; call it cell mode, call it
LC_ATM, call it IP+ATM (I'm not sure which terms are cisco
marketing-speak and which are standardized).  It's not immediately
clear to me how you could do that with IP while using the existing ATM
switch hardware and with only a control-plane upgrade.

Perhaps I've missed something, but I've not seen a response to my last
email that pointed this out, so until someone demonstrates otherwise,
I'm going to keep pointing it out. :)

LDP is also being used as the signalling protocol for p2p services, a
la the Martini draft.  IP alone can't easily do this, as you need not
only a label to transport across the IGP, but also a service label so
that the edge can demux to the proper l2 circuit.  You could do
something involving destination protocol type/port as a demux header,
but that'd be non-trivial forwarding hardware.



eric



> 
> 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.
> 
> > This makes MPLS a service enabler.
> NH=> I don't agree that *LDP* makes MPLS a 'service-enabler'.  Considered
> against a VPN service, the behaviour noted above is not what is needed.  Now
> take the fact that QoS (a pkt forwarding attribute) and survivability (an
> LSP attribute) need decoupling so that per VPN QoS/availability SLAs can be
> defined/measured (independent of other VPNs) and look what LDP does to
> that.....it mangles then both so they can't be decoupled, and now VPN
> QoS/survivability behaviour is no longer independent on a per VPN basis.
> Again this is not the required behaviour for VPNs.
> 
> > For instance I 
> > did not see anyone
> > mention things like QoS transparency that MPLS can achieve.
> NH=> How can you claim this in view of the above observations?  Further, on
> what basis are you discussing QoS?  That is, unless you can automatically
> fault-manage MPLS I fail to see how anyone has any basis on which to discuss
> QoS with any conviction......you have to define availability 1st, since QoS
> metrics *only* have relevance to the up-state, and availability is dependent
> of having defects defined.  So where are the defects defined and where is
> availability defined?....once you can point at these then we can
> meaningfully discuss QoS, but not before.
>  
> > Sure you can
> > monkey around with IP to make IP have everything that MPLS 
> > has.
> NH=> No, you have to monkey around with LDP (eg load-balancing) because it
> does not provide sufficient decoupling from IP behaviour as I noted above.
> 
> > May be even a
> > fixed length tag and call it something else :).
> > 
> > Why do it when this extension already exists as an IETF based 
> > standards where
> > folks like us can debate issues and come up with solutions 
> > that are acceptable
> > to most?
> NH=> I have no problems with people defining solution's for a restricted
> perspective of the problem-space if that is all they need/want from MPLS,
> just so long as they don't try to stop others defining solutions which have
> a more general application.  I have a strong sense that some people want to
> do this....and therein lies the real problem IMO. 
> > 
> > -ajay
> > 
> > 
> > >:Robert Raszuk writes:
> > >:
> > >: > Currently deployed hardware & software.
> > >:
> > >:your current router hardware can't do many other things either, like
> > >:learning mac addresses.  so when you re-spin it, you could 
> > also consider
> > >:adding real support for ip tunneling for those who don't like the
> > >:complexity of mpls control plane.
> > >:
> > >:-- juha
> > >:
> > 
> > -- 
> >