The MPLS WG Archive

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

Eric,

> -----Original Message-----
> From: Eric Osborne [mailto:eosborne@cisco.com]
> Sent: Monday, June 03, 2002 10:01 AM
> To: neil.2.harrison@bt.com
> Cc: asimha@cisco.com; mpls@UU.NET; ppvpn@ppvpn.francetelecom.com
> Subject: Re: Basic LDP Question
> 
> 
> 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. :)

You are absolutely right. IP forwarding can't be used for ATM-LSRs. But
since most ATM hardware can't do VC-merge, you can't use LDP in a mp2p
fashion on ATM-LSRs. Therefore there is no scalability advantage in using LDP
vs. RSVP-TE or CR-LDP. So why use LDP which can't even do TE, instead of CR-LDP or RSVP-TE?

> 
> LDP is also being used as the signaling 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.

The remote peering mode of LDP is useful, but you could use BGP or even RSVP-TE/CR-LDP too with the same scalability level. The question was regarding the mp2p mode of LDP not the p2p remote peering.

-Shahram

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