ietf
[Top] [All Lists]

RE: Question about use of RSVP in Production Networks

2004-08-12 22:20:56
I am interested in learning about any production sites using RSVP-TE as well. 

-----Original Message-----
From: Bob Natale [mailto:Bob(_dot_)Natale(_at_)AppliedSNMP(_dot_)com]
Sent: Thursday, August 12, 2004 3:00 PM
To: Fleischman, Eric; Dean Anderson
Cc: ietf(_at_)ietf(_dot_)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(_at_)av8(_dot_)com>  
Subject: Re: Question about use of RSVP in Production Networks  
To: "Fleischman, Eric" <eric(_dot_)fleischman(_at_)boeing(_dot_)com>
Cc: ietf(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
This message was passed through 
ietf_censored(_at_)carmen(_dot_)ipv6(_dot_)cselt(_dot_)it, 
which is a sublist of ietf(_at_)ietf(_dot_)org(_dot_) Not all messages are 
passed. 
Decisions on what to pass are made solely by IETF_CENSORED ML 
Administrator (ietf_admin(_at_)ngnet(_dot_)it).

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf


<Prev in Thread] Current Thread [Next in Thread>