The MPLS WG Archive

[Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>]

Vijay,
just because you mentioned hundreds of thousands of LSPs, here are my thoughts
why it makes sense to preserve CR-LDP: 

In Yokohame I presented the results of a comparison between four methods as to overcome the O(n**2)-problem
when VPNs shall be built using MPLS tunneling. By far, the best solution is to interconnect the n PEs with n-1 pairs
of mutually inverse-directed elementary LSPs, and then to build merging mp2p H-LSPs as to concatenate some of them
to different sink trees of LSPs.
 
However, these mp2p H-LSPs were to be built in Downstream-Unsolicited mode which requires LDP syntax !

Next, as to identify the (already existing) sub H-LSPs, which are to be concatenated and/or  are to be used
as Control-Plane tunnels, their LSP-IDs are to be known and dealt with. However, LSP-IDs are only provided by CR-LDP,
not by LDP.

And if they should be built using explicit routing, some little extensions to the  
ER-HOP TLV will do.   

It is easier to take the ingrediences from LDP and CR-LDP rather than from LDP and RSVP-TE.

Heinrich


-----Ursprüngliche Nachricht-----
Von: Vijayanand C - CTD, Chennai. [mailto:vijayc@ctd.hcltech.com]
Gesendet: Montag, 22. Juli 2002 14:39
An: sudheer@nayna.com
Cc: mpls@UU.NET
Betreff: Re: initiating a discussion on mpls singaling protocols


In a network where you need to handle hundreds of thousands of LSPs, with a
significant percentage of them going on and off frequently, would the soft
state approach scale effectively ?
By making the behaviour harder by introducing work arounds will we
losing/missing something or killing performance. I think a thorough
performance analysis has to be done on this between CR LDP and RSVP-TE
before coming to a conclusion purely based on numbers in a survey. Numbers
usually come from what the leaders do. 

Implementation ease - I meant, CR LDP is much easier to undestand, implement
and maintain than RSVP-TE( take into account RSVP+LSP_Tunneling + its addons
like Refresh reduction to make it scalable). Also if LDP exists, then CRLDP
is a small add on. Having LDP and CR LDP together and maintaining and
managing it is much easier than LDP+RSVP_TE.

Regards,
Vijay

-----Original Message-----
From: Sudheer Dharanikota [mailto:sudheer@nayna.com]
Sent: Friday, July 19, 2002 7:30 PM
To: Vijayanand C - CTD, Chennai.
Cc: Jean Philippe Vasseur; mpls@UU.NET
Subject: Re: initiating a discussion on mpls singaling protocols




"Vijayanand C - CTD, Chennai." wrote:

> The technical issues are stated in this and subsequent mails and can be
> restated as
> - scalability with efficiency and performance, esp in future GMPLS
networks

Why do you think sclability will be a big issue in the GMPLS networks?
Remeber GMPLS is meant for transport networks. The number of
active connections would be typically less than or equal to the current
number of data connections in a core.

>
> - Ease of implementation and maintenance. A more cleaner protocol than
> RSVP-TE

Ease of implemenatation if you start from the beginning. If you take an
initial
code base from a well-known site and modifying it is not a big deal. Or am I
missing something here?

- sudheer

>
> - Co-existence with LDP
>
> Regards,
> Vijay
>
> -----Original Message-----
> From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com]
> Sent: Friday, July 19, 2002 6:03 PM
> To: Vijayanand C - CTD, Chennai.
> Cc: MPLS wg; nagabhushana.ramaswamy@wipro.com
> Subject: RE: initiating a discussion on mpls singaling protocols
>
> At 11:00 19/07/2002 +0530, Vijayanand C - CTD, Chennai. wrote:
> >I agree with what Bhushana says.We need to look at it from the technical
> >merits apart from who supports RSVP-TE and who does'nt.
> >
> >I think RSVP-TE has become more popular not because of its technical
> >superiority over CR LDP but purely due to the push it has received from a
> >few leading vendors, who choose to use it since they already had RSVP.
The
> >support for RSVP-TE is not because of its technical merits but because of
> >the leading vendors choosing it causing others to meekly follow suit.
> >However, it is not too late to weigh its merits against CR LDP.
> >
> >CR LDP is much more cleaner and has lesser scalability issues. Also, when
> >one has LDP it is much easier to have CR LDP than extending RSVP for
> >RSVP-TE. CR LDP is specifically meant for TE in MPLS and hence is
> >advantageous.
>
> don't see the technical arguments there ...
>
> JP.
>
> > From an implementors point of view also,having been involved
> >in implementation of both the protocols, I feel CR LDP is much easier to
> >understand, implement and maintain. One also needs to look at other
> >performance issues, which may become critical in GMPLS, I wonder if
anyone
> >has checked it.
> >
> >
> >Regards,
> >Vijay
> >
> >-----Original Message-----
> >From: Nagabhushana Ramaswamy Nadig
> >[mailto:nagabhushana.ramaswamy@wipro.com]
> >Sent: Thursday, July 18, 2002 9:45 PM
> >To: MPLS wg
> >Subject: Re: initiating a discussion on mpls singaling protocols
> >
> >
> >This message uses a character set that is not supported by the Internet
> >Service.  To view the original message content,  open the attached
message.
> >If the text doesn't display correctly, save the attachment to disk, and
> then
> >open it using a viewer that can display the original character set.