Subject: Re: initiating a discussion on mpls singaling protocols

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Mon, 22 Jul 2002 18:09:21 +0530

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:[email-masked]]
Sent: Friday, July 19, 2002 7:30 PM
To: Vijayanand C - CTD, Chennai.
Cc: Jean Philippe Vasseur; [email-masked]
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:[email-masked]]
> Sent: Friday, July 19, 2002 6:03 PM
> To: Vijayanand C - CTD, Chennai.
> Cc: MPLS wg; [email-masked]
> 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:[email-masked]]
> >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.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 22 Jul 2002 09:04:03 -0400

>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

         Difficulty of  implementation is of little concern at this point 
in the
game. The point is that customers want to pay for these features so
vendors that want to sell routers will implement whatever their customers
tell them to.

         --Tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.

---

From: David Charlap <[email-masked]>
Date: Mon, 22 Jul 2002 10:00:14 -0400

> state approach scale effectively ?

If refresh reduction (RFC 2961) is implemented, it will scale just as 
well as any other approach will.

Keep in mind that CR-LDP's seeming similicity is hiding all of the 
overhead inherent in using TCP for reliable delivery of control-plane 
packets.

-- David

---

From: "sailendra mahanty" <[email-masked]>
Date: Mon, 22 Jul 2002 20:32:45 +0530

When hundreds of thousands of LSPs going ON and OFF, CRLDP implementation
may have scalability issues. As CRLDP implementation has to pay for this
with Label withdraw/release message when RSVP has to pay for this with
path/resv tear messages.

-sailendra

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of David
Charlap
Sent: Monday, July 22, 2002 7:30 PM
To: IETF MPLS List
Subject: Re: initiating a discussion on mpls singaling protocols

-- David

***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

---

From: "Nagabhushana Ramaswamy Nadig" <[email-masked]>
Date: Mon, 22 Jul 2002 18:56:12 +0400 (RET)

> vendors that want to sell routers will implement whatever their customers

Of Course we never have an issue with this, after all money is what can
have a final say in any business. But at the service level what is that, that
makes RSVP-TE a better option!! That being the case we "have" to look at
the other aspects of ease of implementation (which may be insignificant
today, but I am not sure we may still have some implementations in
future), support for future enhancements, and the whole lot of product
life cycle management issues.

Just my thought....
regards
Bhushana

---

From: Zafar Ali <[email-masked]>
Date: Tue, 23 Jul 2002 11:35:14 -0400

>with Label withdraw/release message when RSVP has to pay for this with

Furthermore, the CPU and control bandwidth usage matters more in the 
transit case, than in steady state case.

Thanks

Regards... Zafar

---

From: "Marty Borden" <[email-masked]>
Date: Tue, 23 Jul 2002 11:53:47 -0400

I am in favor of the proposal of progressing rsvp-te as standards track
and making cr-ldp as informational.
marty