The MPLS WG Archive

[Eric Osborne <eosborne@cisco.com>]

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

I'll have to defer on the ability of available HW to do vc-merge,
since ATM is not my strong point.  I know some vendors have HW that
does it.

Without VC merge, you could use RSVP or LDP.  But even with VC merge,
you could use RSVP between directly connected neighbors on every link
and you wouldn't need LDP there, either.

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

I don't think RSVP is appropriate for service label signalling in this
case.

Sure, one could use BGP, but there's all sorts of things to consider
there, too.  We could use BGP between every pair of directly connected
neighbors (a la rfc3107) and not use LDP there, either.  But we don't;
BGP and LDP are different.

Why are you trying to get rid of LDP?  It certainly seems like
that...:)



eric

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