Re: Question about use of RSVP in Production Networks

Bob Natale <Bob.Natale@AppliedSNMP.com> Fri, 13 August 2004 14:52 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20390; Fri, 13 Aug 2004 10:52:36 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvdVI-00081i-Dk; Fri, 13 Aug 2004 10:58:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvdFz-0003x0-Di; Fri, 13 Aug 2004 10:42:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvNey-0005zZ-U4 for ietf@megatron.ietf.org; Thu, 12 Aug 2004 18:02:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11365 for <ietf@ietf.org>; Thu, 12 Aug 2004 18:02:54 -0400 (EDT)
Received: from omr5.netsolmail.com ([216.168.230.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvNk0-0007qM-1H for ietf@ietf.org; Thu, 12 Aug 2004 18:08:09 -0400
Received: from ms1.netsolmail.com (IDENT:mirapoint@[216.168.230.167]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7CM0Luo015559; Thu, 12 Aug 2004 18:00:21 -0400 (EDT)
Received: from ms1.netsolmail.com (localhost.netsolmail.com [127.0.0.1]) by ms1.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BXU96719; Thu, 12 Aug 2004 18:00:20 -0400 (EDT)
Message-Id: <200408122200.BXU96719@ms1.netsolmail.com>
Received: from 64.254.114.114 by ms1.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with HTTP/1.1; Thu, 12 Aug 2004 18:00:20 -0400
Date: Thu, 12 Aug 2004 18:00:20 -0400
From: Bob Natale <Bob.Natale@AppliedSNMP.com>
To: "Fleischman, Eric" <eric.fleischman@boeing.com>, Dean Anderson <dean@av8.com>
X-Mailer: Webmail Mirapoint Direct 3.2.2-GA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 13 Aug 2004 10:42:07 -0400
Cc: ietf@ietf.org
Subject: Re: Question about use of RSVP in Production Networks
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Bob.Natale@AppliedSNMP.com
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Content-Transfer-Encoding: 7bit

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