Subject: RE: initiating a discussion on mpls singaling protocols

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Tue, 23 Jul 2002 15:33:28 +0530

Apply the refresh reduction procedures to the scenario taking into account
the amount of state you need to store for summary refresh, triggers, refresh
msgs , ACKs/NACKs and associated back off mechanisms in RSVP-TE. Sure, you
might be able to manage but are you efficient considering that you could do
the same thing easily with CR LDP.

Vijay

-----Original Message-----
From: sailendra mahanty [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 12:38 PM
To: 'Vijayanand C - CTD, Chennai.'
Cc: [email-masked]
Subject: RE: initiating a discussion on mpls singaling protocols

Hello Vijay,

I agree in a stable scenario (LSPs not going ON and OFF)
CR-LDP is more scaleable than RSVP-TE because of it(CRLDP)'s hard
state approach.
if n LSPs are configured with CR-LDP it's
	1 Hello and 1 KA per hold time per pair of neighbour
	n Label Req (not present in DU) and n Label Map per pair of
neighbour
if n LSPs are configured with RSVP-TE it's
	n Path per hold time per pair of neighbour
	n Resv per hold time per pair of neighbour

The scalability issue of RSVP-TE can be resolved by refresh reduction.

But the concern is when significant LSPs, X(say) going ON and OFF.
With CR-LDP implementation it's
	X Label withdraw and X Release per pair of neighbour
with RSVP-TE also it's
	X Path Tear and X Resv Tear per pair of neighbour
	OR X Path err and X Resv err per pair of neighbour

To me both the implementations looks more or less same. Am i missing some
thing.

Regards,
-sailendra

-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 12:09 PM
To: [email-masked]
Subject: RE: initiating a discussion on mpls singaling protocols

CR LDP willbe more stable in this situation. RSVP-TE uses a soft state
approach while CR LDP uses hard states and cleaner way of maintaining and
communicating changes

VIjay

-----Original Message-----
From: sailendra mahanty [mailto:[email-masked]]
Sent: Monday, July 22, 2002 8:33 PM
To: 'David Charlap'; 'Vijayanand C - CTD, Chennai.'
Cc: 'IETF MPLS List'
Subject: RE: initiating a discussion on mpls singaling protocols

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

Vijayanand C - CTD, Chennai. wrote:
> 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 ?

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

***************************************************************************
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.
***************************************************************************

***************************************************************************
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: David Charlap <[email-masked]>
Date: Tue, 23 Jul 2002 11:44:42 -0400

> the same thing easily with CR LDP.

You are forgetting about the overhead of the TCP protocol, which has to 
do all the same things to ensure reliable message delivery.  This 
overhead must be added to CR-LDP, since it uses TCP.  It is not added to 
RSVP-TE, which works over raw sockets.

The fact that overhead is hidden in a different protocol layer doesn't 
mean it doesn't exist.

-- David