Subject: RE: Use of LDP for VPNs

From: Nhat Thanh Hoang <[email-masked]>
Date: Thu, 12 Apr 2001 16:13:20 +0200

Hi, Eduard

In a simple VPN topology, RSVP-TE and CR-LDP between PEs might be good
enough to provide traffic engineering, path protection and tunneling
mechanism for building a reliable MPLS-VPN. In a complex and large number of
PEs, RSVP-TE and CR-LDP between PEs is too messy thereby hard to manage and
not scalable. A good management tool can mitigate these problems, I think.

Today, RSVP-TE and CR-LDP can never replace LDP and vice versa.

Cheers,

/Nhat Thanh 

-----Original Message-----
From: Metz, Eduard [mailto:[email-masked]]
Sent: den 12 april 2001 15:10
To: 'HANSEN CHAN'
Cc: [email-masked]
Subject: RE: Use of LDP for VPNs

Yes, in most cases there is no need for contraint routed paths. 

In these cases I do not see the point of (potentially manually) creating LSP
through RSVP/TE or CR-LDP between PEs, when LDP does this automatically.
Contraint routed LSPs only add to operational complexity here (maintaining
LSPs, adding PEs), with no further added value ...

cheers,
	Eduard

> -----Original Message-----
> From: HANSEN CHAN [mailto:[email-masked]]
> Sent: 12 April 2001 14:07
> To: [email-masked]
> Subject: Re: Use of LDP for VPNs
> 
> 
> Dave,
> 
> > In Bora's scenario, every router treats its own local 
> addresses as /32
> > FECs and sends out unsolicited label mappings for these.  
> They propagate
> > to the rest of the MPLS cloud.  Now, every router has a 
> label for every
> > address of every MPLS router.  A full-mesh of LSPs has set itself up
> > with no manual intervention.
> 
> Your explanation is interesting. In other word, the full-mesh 
> of LSP is
> topology-driven. I thought the idea of topology-driven is abandonned.
> 
> Is topology-driven the actual way used to establish those 
> PE-to-PE LSPs in
> real implementation or real network today?
> 
> Cheers,
> Hansen
> 
>

---

From: David Charlap <[email-masked]>
Date: Thu, 12 Apr 2001 10:40:13 -0400

Nhat Thanh Hoang wrote:
> 
> In a simple VPN topology, RSVP-TE and CR-LDP between PEs might be
> good enough to provide traffic engineering, path protection and
> tunneling mechanism for building a reliable MPLS-VPN. In a complex
> and large number of PEs, RSVP-TE and CR-LDP between PEs is too messy
> thereby hard to manage and not scalable. A good management tool can
> mitigate these problems, I think.

CR-LDP and RSVP-TE do not mandate the use of explicit route objects.  If
they are not used, then the LSP setup follows the routing table, just
like LDP.  The only difference being that the ingress nodes must know
the endpoints of the LSPs.  This overhead is rather minor, since the
addresses of the endpoints can be fetched directly from routing
protocols (like BGP).

LDP is no different on systems where unsolicited label distribution is
not configured.

Unsolicited operation makes things setup faster, but it doesn't really
affect the overall complexity of the network.  IMO, it makes things more
complex for transit and egress routers.  ERO computation only adds
complexity to ingress routers.

-- David

---

From: Eric Rosen <[email-masked]>
Date: Thu, 12 Apr 2001 10:48:38 -0400

David> CR-LDP and RSVP-TE do not  mandate the use of explicit route objects.
David> If they are  not used, then the LSP setup  follows the routing table,
David> just like LDP.  The only difference being that the ingress nodes must
David> know the endpoints of the LSPs.

I believe  that RSVP-TE  will only set  up point-to-point LSPs,  whereas LDP
sets up  multipoint-to-point LSPs.  The  difference in state at  the transit
nodes would thus seem to be considerable. 

David> Unsolicited  operation  makes things  setup  faster,  but it  doesn't
David> really affect the  overall complexity of the network.   IMO, it makes
David> things more complex for transit and egress routers.

The notion that a router should set up routes automatically, without waiting
for path setup signalling, is not exactly a novel notion in IP networks.

---

From: Eric Gray <[email-masked]>
Date: Thu, 12 Apr 2001 10:54:54 -0400

David,

    With respect to the differences between LDP and CR-LDP,
your analysis is accurate, but slightly misleading.  CR-LDP, if
used with a /32 FEC and no ERO _is_ LDP with ordered control
and downstream on demand (unless you are also using traffic
parameters - which is not practical without ERO).  Thus, the
observation that "LDP is no different" is unsurprising.  :-)

--
Eric Gray

---

From: David Charlap <[email-masked]>
Date: Thu, 12 Apr 2001 10:59:02 -0400

Eric Rosen wrote:
>> 
>> CR-LDP and RSVP-TE do not mandate the use of explicit route
>> objects.  If they are not used, then the LSP setup follows the
>> routing table, just like LDP.  The only difference being that the
>> ingress nodes must know the endpoints of the LSPs.
> 
> I believe that RSVP-TE will only set up point-to-point LSPs, whereas
> LDP sets up multipoint-to-point LSPs.  The difference in state at 
> the transit nodes would thus seem to be considerable.

RSVP-TE can do multipoint-to-point.  If the extended tunnel ID is zero,
then all senders using the same endpoint and tunnel ID will be in the
same session.  If SE style reservations are used, all paths in the
session (from the ingress routers to the egress router) will share
resources.  A router that is capable of label-merging can choose to send
the same label to all previous-hop routers in the session, effectively
combining two (or more) RSVP paths into a single LSP.

-- David

---

From: Eric Rosen <[email-masked]>
Date: Fri, 13 Apr 2001 10:59:47 -0400

David> RSVP-TE  can do multipoint-to-point.   If the  extended tunnel  ID is
David> zero, then all senders using the  same endpoint and tunnel ID will be
David> in the same session.  If SE style reservations are used, all paths in
David> the  session (from  the ingress  routers to  the egress  router) will
David> share  resources.  A  router  that is  capable  of label-merging  can
David> choose  to send the  same label  to all  previous-hop routers  in the
David> session, effectively combining two (or more) RSVP paths into a single
David> LSP.

Yes, good  point.  I overlooked that  because, as far  as I know, no  one is
actually doing this. 

Even  used  in  this  manner,  though,  RSVP cannot  achieve  the  level  of
efficiency achievable with LDP,  if Downstream Unsolicited and Liberal Label
Retention are used.

---

From: Rajiv Papneja <[email-masked]>
Date: Sat, 14 Apr 2001 13:12:20 -0400 (EDT)

Hi Eric,

  Please read the inline:

On Fri, 13 Apr 2001, Eric Rosen wrote:

>Eric> Yes, good  point.  I overlooked that  because, as far  as I know,
 Eric>no one is actually doing this. 
> 
>Eric> Even  used  in  this  manner,  though,  RSVP cannot  achieve  the
 Eric> level  of efficiency achievable with LDP,  if Downstream
 Eric> Unsolicited and Liberal Label Retention are used. 

 Eric,

    Can you please elaborate the efficiency part. Thanks.

  Regards,
   -Rajiv 

********************************
Rajiv Papneja (GRA)
Advanced Internet Laboratory
George Mason University,
G10, Johnson Center,
Fairfax, VA 22030-4444
Tel: 703.993.4703
email: [email-masked]
********************************

---

From: Eric Gray <[email-masked]>
Date: Mon, 16 Apr 2001 07:53:27 -0400

Rajiv,

    Different Eric, but I'll take a whack at a short answer.

    RSVP-TE does not have a mechanism for 'independent
control' LSP setup and - while you could use RSVP-TE to
support a 'liberal retention' like mode of operation - nobody
that I know of would contemplate doing so irrespective of
their opinion of the scalability of RSVP in the general case.

--
Eric Gray