The MPLS WG Archive

["Vijayanand C - CTD, Chennai." <vijayc@ctd.hcltech.com>]

what about the advantages of using the peer model facilitated by MPLS to get
IP across ATM/FR networks with best effort( no traff engg.) for which the
unsolicited mode of LDP is more useful ?

Vijay

-----Original Message-----
From: Eric Osborne [mailto:eosborne@cisco.com]
Sent: Tuesday, June 04, 2002 3:05 AM
To: Ajay Simha
Cc: Eric Osborne; Shahram Davari; neil.2.harrison@bt.com; mpls@UU.NET;
ppvpn@ppvpn.francetelecom.com
Subject: Re: Basic LDP Question


On Mon, Jun 03, 2002 at 02:49:37PM -0400, Ajay Simha wrote:
> 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.

Right, but then Sharam's got a point; if you're not merging, LDP and
RSVP look a lot alike.



eric

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