The MPLS WG Archive

[Ajay Simha <asimha@cisco.com>]

On Mon, 3 Jun 2002, Eric Osborne wrote:

>EO:
>EO:> > LDP lets you easily integrate IP and ATM; call it cell mode, call it
>EO:> > LC_ATM, call it IP+ATM (I'm not sure which terms are cisco
>EO:> > marketing-speak and which are standardized).  It's not immediately
>EO:> > clear to me how you could do that with IP while using the existing ATM
>EO:> > switch hardware and with only a control-plane upgrade.
>EO:> >
>EO:> > Perhaps I've missed something, but I've not seen a response to my last
>EO:> > email that pointed this out, so until someone demonstrates otherwise,
>EO:> > I'm going to keep pointing it out. :)
>EO:>
>EO:> You are absolutely right. IP forwarding can't be used for ATM-LSRs. But
>EO:> since most ATM hardware can't do VC-merge, you can't use LDP in a mp2p
>EO:> fashion on ATM-LSRs. Therefore there is no scalability advantage in using LDP
>EO:> vs. RSVP-TE or CR-LDP. So why use LDP which can't even do TE, instead of CR-LDP or RSVP-TE?
>EO:>
>EO:
>EO:I'll have to defer on the ability of available HW to do vc-merge,
>EO:since ATM is not my strong point.  I know some vendors have HW that
>EO:does it.

Actually VC merge is not a must if the LSR request seperate labels - one per
request it gets from the upstream neighbor.

-ajay
>EO:
>EO:Without VC merge, you could use RSVP or LDP.  But even with VC merge,
>EO:you could use RSVP between directly connected neighbors on every link
>EO:and you wouldn't need LDP there, either.
>EO:
>EO:> >
>EO:> > LDP is also being used as the signaling protocol for p2p services, a
>EO:> > la the Martini draft.  IP alone can't easily do this, as you need not
>EO:> > only a label to transport across the IGP, but also a service label so
>EO:> > that the edge can demux to the proper l2 circuit.  You could do
>EO:> > something involving destination protocol type/port as a demux header,
>EO:> > but that'd be non-trivial forwarding hardware.
>EO:>
>EO:> 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.
>EO:>
>EO:
>EO:I don't think RSVP is appropriate for service label signalling in this
>EO:case.
>EO:
>EO:Sure, one could use BGP, but there's all sorts of things to consider
>EO:there, too.  We could use BGP between every pair of directly connected
>EO:neighbors (a la rfc3107) and not use LDP there, either.  But we don't;
>EO:BGP and LDP are different.
>EO:
>EO:Why are you trying to get rid of LDP?  It certainly seems like
>EO:that...:)
>EO:
>EO:
>EO:
>EO:eric
>EO:
>EO:> -Shahram
>EO:>
>EO:> >
>EO:> >
>EO:> >
>EO:> > eric
>EO:> >
>EO:> >
>EO:> >
>EO:> > >
>EO:> > > Please also see below.   Regards, Neil
>EO:> > >
>EO:> > > Ajay Simha wrote 01 June 2002 04:15
>EO:> > >
>EO:> > > > The point is MPLS effectively decouples the forwarding
>EO:> > > > portion from the
>EO:> > > > routing.
>EO:> > > NH=> Well I agree, this is vital and it's what is needed.  And it's
>EO:> > > something we in Telco-land have known/used for years, ie
>EO:> > decoupling of the
>EO:> > > traffic carrying data-plane and its control-plane (both its
>EO:> > own data-plane,
>EO:> > > where appropriate, and its routing and signalling
>EO:> > protocols).  But LDP does
>EO:> > > nothing more than instantiate labels per hop that are
>EO:> > locked to the IGP.
>EO:> > > That is (i) they take the same SPF routes as the IGP would
>EO:> > use for IP
>EO:> > > fowarding and (ii) the LSPs change as the IGP changes.  I
>EO:> > would argue this
>EO:> > > is not a required behaviour for applications where LSPs are
>EO:> > long-holding
>EO:> > > and/or must not be affected by ad hoc routing changes or
>EO:> > failures of routing
>EO:> > > protocols (eg VPNs).  Further, because LDP is so tightly
>EO:> > coupled to the IGP
>EO:> > > then one has to introduce 'layer violations' to make it
>EO:> > work a bit better,
>EO:> > > eg Load-balancing using IP-level hashing......its hard to
>EO:> > take seriously
>EO:> > > anyone claiming this is MPLS label forwarding when one has
>EO:> > to look at the
>EO:> > > client/IP level (which it may not always be, ie XoverMPLS) to make
>EO:> > > switching/forwarding decisions.
>EO:> > >
>EO:> > > > This makes MPLS a service enabler.
>EO:> > > NH=> I don't agree that *LDP* makes MPLS a
>EO:> > 'service-enabler'.  Considered
>EO:> > > against a VPN service, the behaviour noted above is not
>EO:> > what is needed.  Now
>EO:> > > take the fact that QoS (a pkt forwarding attribute) and
>EO:> > survivability (an
>EO:> > > LSP attribute) need decoupling so that per VPN
>EO:> > QoS/availability SLAs can be
>EO:> > > defined/measured (independent of other VPNs) and look what
>EO:> > LDP does to
>EO:> > > that.....it mangles then both so they can't be decoupled,
>EO:> > and now VPN
>EO:> > > QoS/survivability behaviour is no longer independent on a
>EO:> > per VPN basis.
>EO:> > > Again this is not the required behaviour for VPNs.
>EO:> > >
>EO:> > > > For instance I
>EO:> > > > did not see anyone
>EO:> > > > mention things like QoS transparency that MPLS can achieve.
>EO:> > > NH=> How can you claim this in view of the above
>EO:> > observations?  Further, on
>EO:> > > what basis are you discussing QoS?  That is, unless you can
>EO:> > automatically
>EO:> > > fault-manage MPLS I fail to see how anyone has any basis on
>EO:> > which to discuss
>EO:> > > QoS with any conviction......you have to define
>EO:> > availability 1st, since QoS
>EO:> > > metrics *only* have relevance to the up-state, and
>EO:> > availability is dependent
>EO:> > > of having defects defined.  So where are the defects
>EO:> > defined and where is
>EO:> > > availability defined?....once you can point at these then we can
>EO:> > > meaningfully discuss QoS, but not before.
>EO:> > >
>EO:> > > > Sure you can
>EO:> > > > monkey around with IP to make IP have everything that MPLS
>EO:> > > > has.
>EO:> > > NH=> No, you have to monkey around with LDP (eg
>EO:> > load-balancing) because it
>EO:> > > does not provide sufficient decoupling from IP behaviour as
>EO:> > I noted above.
>EO:> > >
>EO:> > > > May be even a
>EO:> > > > fixed length tag and call it something else :).
>EO:> > > >
>EO:> > > > Why do it when this extension already exists as an IETF based
>EO:> > > > standards where
>EO:> > > > folks like us can debate issues and come up with solutions
>EO:> > > > that are acceptable
>EO:> > > > to most?
>EO:> > > NH=> I have no problems with people defining solution's for
>EO:> > a restricted
>EO:> > > perspective of the problem-space if that is all they
>EO:> > need/want from MPLS,
>EO:> > > just so long as they don't try to stop others defining
>EO:> > solutions which have
>EO:> > > a more general application.  I have a strong sense that
>EO:> > some people want to
>EO:> > > do this....and therein lies the real problem IMO.
>EO:> > > >
>EO:> > > > -ajay
>EO:> > > >
>EO:> > > >
>EO:> > > > >:Robert Raszuk writes:
>EO:> > > > >:
>EO:> > > > >: > Currently deployed hardware & software.
>EO:> > > > >:
>EO:> > > > >:your current router hardware can't do many other things
>EO:> > either, like
>EO:> > > > >:learning mac addresses.  so when you re-spin it, you could
>EO:> > > > also consider
>EO:> > > > >:adding real support for ip tunneling for those who
>EO:> > don't like the
>EO:> > > > >:complexity of mpls control plane.
>EO:> > > > >:
>EO:> > > > >:-- juha
>EO:> > > > >:
>EO:> > > >
>EO:> > > > --
>EO:> > > >
>EO:> >
>EO:

--