Subject: Re: Basic LDP Question

From: Eric Osborne <[email-masked]>
Date: Sun, 2 Jun 2002 11:33:44 -0400

On Fri, May 31, 2002 at 11:41:35AM -0700, Shahram Davari wrote:
> Vijay,
> 
> I know all this. The question was: 
> 
> "Why use LDP instead of IP?". 
> 
> If you have an answer please provide.

(coming back from vacation)
Another answer that I haven't seen here is the ability to do cell-mode
MPLS with ATM.  That's one of the original MPLS applications, and LDP
certainly helps with that.

eric

> 
> -Shahram
> 
> > -----Original Message-----
> > From: Vijay Bollapragada [mailto:[email-masked]]
> > Sent: Friday, May 31, 2002 2:34 PM
> > To: Shahram Davari
> > Cc: [email-masked]'; [email-masked]'
> > Subject: RE: Basic LDP Question
> > 
> > 
> > On Fri, 31 May 2002, Shahram Davari wrote:
> > 
> > > Vijay,
> > 
> > > But LDP does not give you the TE ability. So why use LDP?
> > 
> > Agreed, that LDP does not give the ability to do TE, I only 
> > said use MPLS
> > in the core, not necassarily LDP :-) but in any case, Here is 
> > what 2547
> > draft says about using LDP for the top label..
> > 
> > Section 4.3.2
> > 
> > "All that matters for the VPN architecture is that some label switched
> > path between the router and its BGP next hop exists.  
> > However, to ensure
> > interoperability  among systems which implement this VPN architecture,
> > all such systems must support LDP [MPLS-LDP]."
> > 
> > Of course, once could use many other mechanisms to get the vpn_labeled
> > packet from one edge PE to another edge PE, Interoperability 
> > is the key
> > here.
> > 
> > Thanks,
> > Vijay
> > 
> > 
> > 
> > > 
> > > > -----Original Message-----
> > > > From: Vijay Bollapragada [mailto:[email-masked]]
> > > > Sent: Friday, May 31, 2002 2:06 PM
> > > > To: Shahram Davari
> > > > Cc: [email-masked]'; [email-masked]'
> > > > Subject: Re: Basic LDP Question
> > > > 
> > > > 
> > > > In the 2547 case, typically u have 2 labels, the vpn_label 
> > > > (bottom label)
> > > > and the top label is the label to get the packet to the far 
> > > > end PE, Now,
> > > > LDP is used for this top label.
> > > > 
> > > > I think u are questioning why use LDP for this bottom_label 
> > > > and why not
> > > > simply encapsulate the MPLS packet in IP to get the packet to 
> > > > the next_hop
> > > > PE. If this is your Q, You are absolutely correct and 
> > this is what the
> > > > following draft talks about
> > > > 
> > > > http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-gre-ip
> > > > -2547-01.txt
> > > > 
> > > > IMHO, this is certainly do-able but MPLS in the core give us 
> > > > the ability
> > > > to do things like Traffic Enginnering
> > > 
> > > 
> > > -Shahram
> > > 
> > >  which are quite a challenge over
> > > > pure IP.
> > > > 
> > > > Thanks,
> > > > Vijay
> > > > 
> > > > 
> > > > 
> > > > On Fri, 31 May 2002, Shahram Davari wrote:
> > > > 
> > > > > Hi,
> > > > > 
> > > > > What problem a mp2p LDP-based MPLS network is trying to 
> > > > solve (like the one used in RFC2547) that can't be done with 
> > > > pure IP forwarding?
> > > > > 
> > > > > Note: Don't tell me fast forwarding, because we can do fast 
> > > > IP lookup as well.
> > > > > 
> > > > > Yours,
> > > > > Shahram
> > > > > 
> > > > > 
> > > > 
> > > 
> >

---

From: Shahram Davari <[email-masked]>
Date: Sun, 2 Jun 2002 15:33:04 -0700

Ajay,

> From: Ajay Simha [mailto:[email-masked]]
> Sent: Friday, May 31, 2002 11:15 PM
> To: [email-masked]
> Cc: [email-masked]; Shahram Davari; 'Giles Heron'; 'Yakov Rekhter';
> [email-masked]'; [email-masked]'
> On Fri, 31 May 2002 [email-masked] wrote:
> 
> The point is MPLS effectively decouples the forwarding 
> portion from the
> routing.

LDP does not decouple routing from forwarding.

-Shahram

---

From: "Nick Tingle" <[email-masked]>
Date: Fri, 31 May 2002 15:11:40 -0700

I believe another concern with VPNs over IP vs. MPLS is packets leaking out of
the provider network, due to, e.g. transient routing problems. Presumably this
can also be fixed with filtering.

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Friday, May 31, 2002 12:09 PM
> To: Vijay Bollapragada
> Cc: Shahram Davari; [email-masked]'; [email-masked]'
> packet spoofing is quite easy to prevent by a single access list at
> ingress to other providers that drops a packet if its source address
> belongs to the network that is used for the loopback interfaces that
> terminate the ip tunnels at the pes.
>
> what comes to subscriber links, we, and any reasonable service provider,
> of course always check that the source addresses belong to the
> subscribers.
>
> -- juha
>
>

---

From: "Stiedl, Alexander" <[email-masked]>
Date: Mon, 3 Jun 2002 09:17:28 +0200

Yakov Rekhter wrote:
>>1.  Efficient encapsulation of VPN traffic
>>2.  Ability to run VPN on current hardware
>>
>>There are probably other reasons as well...
> 
> One of the "other reasons" is straightforward protection against
packet 
> spoofing.

More straightforward than an IP firewall?

Lars
-- 
Lars Eggert <[email-masked]>           USC Information Sciences Institute

---

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Tue, 4 Jun 2002 13:15:23 +0530

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:[email-masked]]
Sent: Tuesday, June 04, 2002 3:05 AM
To: Ajay Simha
Cc: Eric Osborne; Shahram Davari; [email-masked]; [email-masked];
[email-masked]
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:
> 
> --

---

From: Nabil Seddigh <[email-masked]>
Date: Tue, 04 Jun 2002 15:08:22 -0400

Discussion regarding spoofing, header overhead, hw availability etc 
all appear to be ancillary arguments made in hindsight.

It seems to me that LDP's emergence a number of years ago could be
attributed primarily to the need for alternatives to the 
longest prefix match route lookup. The latter was typically 
software-based and relatively "slow". This doesn't appear to be
as much of a concern anymore - at least this is what the chip 
& NP vendors would have us believe :) 

Best,
Nabil Seddigh

> 
> Hi,
> 
> What problem a mp2p LDP-based MPLS network is trying to solve (like the one used in RFC2547) that can't be done with pure IP forwarding?
> 
> Note: Don't tell me fast forwarding, because we can do fast IP lookup as well.
> 
> Yours,
> Shahram

---

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 4 Jun 2002 15:37:35 -0400

sorry if somebody has already mentioned the following point.
I have not read all the emails on this thread.

If IP over IP is used instead of MPLS tunnels, doesn't it
rule out the retrofitted L2 switches (ATM/FR switches) as P devices?

/himanshu

> From: Nabil Seddigh [mailto:[email-masked]]
> Sent: Tuesday, June 04, 2002 3:08 PM
> To: Shahram Davari

---

From: [email-masked]
Date: Thu, 6 Jun 2002 17:34:41 +0100

Thanks Giles.....some good points in your full response.  Few minor remarks
below on snipped extract below.

regards, Neil

Giles Heron wrote 06 June 2002 16:13
<snipped>

> I'm not convinced that you need to "merge" the CVs.  If the 
> frequency is
> relatively low you can just allow them all through to the 
> sink which can
> check that it gets packets from all PEs to which it has a 
> label mapping
> learned with LDP?  Remember that if each PE sends the same 
> frequency of
> packets into each LSP this will create the same number of CV 
> packets at
> the sink as would a mesh of TE tunnels.
NH=> This is indeed 1 possibility.  However, changing the frequency of CV
generation is not without implications wrt defect entry/exit criteria.
There are 4 directions to consider wrt  connectivity defects: p2p=>p2p,
p2p=>mp2p, mp2p=>p2p and mp2p=>mp2p.  The more variability on CV rate the
more complex this gets.  Taking just 1 example of 1 particular
direction......suppose 1 LSP had a CV rate of 1/min and another 1/s.  If the
1/min CV LSP was mismerging into the 1/s CV LSP, starting at some point T,
then we would get a cycle of:
-	declare dMismerge after T+3s
-	clear dMismerge after T+6s
-	declare dMismerge after T+63s
-	etc
Further, mismerge from mp2p closer to root than leaf would generate higher
'bad' CV rate....so this would be yet another variable.
So changing CV rate is a possibility, but it would need to be done in a
consistent way across all LSPs IMO and there would still be difficulties
with mp2p depending on from which point on the mp2p tree the leaking was
occurring.
> 
> But yes, hashing is an issue.  I don't think we have an adequate
> solution for this yet :(  The problem is that without knowing a-priori
> what the hashing algorithm in your network is you have no way 
> to know if
> you have hit all possible hashed paths.
NH=> Agreed.  Architecturally the effect of hashing is doing something like:
terminate the LSPs, go up the stack, make a decision of forwarding direction
and then come back down the stack to new LSPs.  So its like have inv-muxing
subnetworks......and each of these trails ought to monitored in its own
right (since they too may malfunction independently).
> 
> Which is one of the reasons why I would advocate testing using
> client-layer tools, or in their absence external probes which 
> can inject
> real traffic into the network (the other reason is that 
> errors may occur
> in the adaptation function at the edges rather than in the core, and
> MPLS OAM will fail to catch these - in fact I have seen more of these
> events than MPLS FIB errors, probably because most of the processing
> complexity is at the edge?)
NH=> I agree problems are certainly not restricted to faulty LSPs.  But one
of the things to bear in mind here is that we want the flexibility to use
the same LSPs constructs for a whole range of client layer signals and
applications....so we need some method of fault-management that is
common/simple to MPLS alone.  But I agree, we also need higher level tools
specific to the actual protocol carried (esp if it has no fault-management
of its own defined).
> 
> > -	note that for both L2 and L3 VPNs there is a single p2p 
> hop above
> > the mp2p entity and run CV on that
> 
> I don't think this is true with L3 VPNs.  They merge at the VPN level,
> don't they? (using mBGP a 2547 PE will likely advertise the same VPN
> label to all peers for a given prefix?)
NH=> Yes this is quite true.  But they are subtley different IMO.  In mp2p
there really is traffic merging post a given P LSR with a common label.  In
the top-level LSPs its more of a "converge" at the PE rather than a merge,
ie there is no subsequent common label at the LSP level.  So I think it
ought to be possible to have a simple CV flow on these.  Now how that would
get configured is a different question.
<snipped>