RE: Question about use of RSVP in Production Networks

I am interested in learning about any production sites using RSVP-TE as well. 

-----Original Message-----
From: Bob Natale [mailto:Bob.Natale@AppliedSNMP.com]
Sent: Thursday, August 12, 2004 3:00 PM
To: Fleischman, Eric; Dean Anderson
Cc: ietf@ietf.org
Subject: Re: Question about use of RSVP in Production Networks

Hi,

Were Eric's question and Dean's answer limited to RSVP strictly,
or would RSVP-TE deployments be of interest?  If the latter, then
what about emerging deployments of architectures that use RSVP-TE,
such as MPLS, GMPLS, and ASON?  (Or are none of the news releases
true? ;-)

Cordially,
BobN

---- Original message ----
>Date: Wed, 11 Aug 2004 18:37:31 -0400 (EDT)
>From: Dean Anderson <dean@av8.com>  
>Subject: Re: Question about use of RSVP in Production Networks  
>To: "Fleischman, Eric" <eric.fleischman@boeing.com>
>Cc: ietf@ietf.org
>
>RSVP is a idea that doesn't cut the mustard in the real world. There 
are 
>several show-stopper problems with RSVP.
>
>1) somewhat like multicast, anyone using RSVP is vulnerable to others
>mis-using or mis-configuring RSVP. ISPs several AS's away can really 
screw
>up things for other ISPs. Because of this, it is unwise to deploy it
>because it requires too much trust in other ISPs.
>
>That relegates RSVP to the enterprise Lan, where it usually isn't 
needed.  
>Remember, RSVP is only useful if you have a congestion problem and 
need to
>choose which packets to discard.  If you have no congestion problem, 
then
>you have no need of RSVP. However, having a congestion problem also 
opens
>the question of the nature of the congestion and what is the best way 
to
>deal that problem.  I was involved in a study done by Genuity and 
Cisco in
>which the congestion problem was found to most often involve the tail
>circuit--the link between the customer and the ISP.  The best solution 
for
>this problem was found to be low latency queuing, not RSVP.
>
>2) Unlike multicast, every hop end-to-end must use RSVP for it to be 
>useful. An RSVP tunnel is useless.
>
>3) RSVP doesn't detect certain kinds of problems that are important. 
For
>example, a mid-span failure is not visible to RSVP.
>
>While RSVP is important research, it is not a widely deployable
>technology.
>
>What I-D's are you encountering that depend on RSVP?
>
>		--Dean
>
>On Tue, 10 Aug 2004, Fleischman, Eric wrote:
>
>> I am aware of some use of RSVP in labs but I am not aware of any use 
of
>> RSVP in production networks (i.e., real life networks people connect 
to
>> the Internet with). Simultaneously, I am encountering I-Ds and other
>> work planning to use RSVP. This possible disconnect concerns me.
>> Therefore, I would appreciate being educated by anybody using RSVP in
>> production settings. Would you please let me know how many devices, 
what
>> applications, and how successful these deployments (if any) are? 
Thank
>> you.
>> 
>> 
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf
>> 
>
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf
>_______________________________________________
>This message was passed through ietf_censored@carmen.ipv6.cselt.it, 
which is a sublist of ietf@ietf.org. Not all messages are passed. 
Decisions on what to pass are made solely by IETF_CENSORED ML 
Administrator (ietf_admin@ngnet.it)

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf