Re: Question about use of RSVP in Production Networks
Dan Wing <dwing@cisco.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 KAA20387; 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-00081h-8j; 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 1BvdFy-0003uv-Ak; Fri, 13 Aug 2004 10:42:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvLLv-0002km-1I for ietf@megatron.ietf.org; Thu, 12 Aug 2004 15:35:07 -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 PAA26195 for <ietf@ietf.org>; Thu, 12 Aug 2004 15:35:05 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvLQw-0002Xz-9p for ietf@ietf.org; Thu, 12 Aug 2004 15:40:18 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 12 Aug 2004 12:37:09 -0700
Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7CJYXD2014087; Thu, 12 Aug 2004 12:34:33 -0700 (PDT)
Received: from [192.168.1.100] (sjc-vpn3-891.cisco.com [10.21.67.123]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA14856; Thu, 12 Aug 2004 12:34:32 -0700 (PDT)
Message-ID: <411BC646.2070605@cisco.com>
Date: Thu, 12 Aug 2004 12:34:30 -0700
From: Dan Wing <dwing@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dean Anderson <dean@av8.com>, ietf@ietf.org
References: <DCxSc.1330792$%F1.349469@rtp-news.cisco.com>
In-Reply-To: <DCxSc.1330792$%F1.349469@rtp-news.cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 13 Aug 2004 10:42:07 -0400
Subject: Re: Question about use of RSVP in Production Networks
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Content-Transfer-Encoding: 7bit
Dean Anderson wrote: > 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 isn't a fault of RSVP, the protocol. Rather, it's a fault of insufficient authorization for a requested flow. > 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. Enterprises have WANs (ATM, FR, MPLS) which do have congestion problems. Even within a LAN it's possible to have congestion problems (PC backups, database replication). > 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. RSVP only needs to be enabled on the links that might become congested, such as an enterprise's WAN links. It usually doesn't need to be enabled on a non-bandwidth-constrained LAN. -d > 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 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Question about use of RSVP in Production Networks Fleischman, Eric
- hop-by-hop and router alert options [Re: Question… Pekka Savola
- Re: hop-by-hop and router alert options [Re: Ques… Masataka Ohta
- Re: hop-by-hop and router alert options [Re: Ques… Martin Stiemerling
- Re: hop-by-hop and router alert options Iljitsch van Beijnum
- Re: hop-by-hop and router alert options [Re: Ques… Florian Weimer
- Re: hop-by-hop and router alert options [Re: Ques… Bob Hinden
- Re: Question about use of RSVP in Production Netw… Dean Anderson
- RE: Question about use of RSVP in Production Netw… Ping Pan
- Re: hop-by-hop and router alert options [Re: Ques… David R Oran
- Re: hop-by-hop and router alert options [Re: Ques… Pekka Savola
- Re: hop-by-hop and router alert options [Re: Ques… David R Oran
- Re: hop-by-hop and router alert options [Re: Ques… Melinda Shore
- Re: hop-by-hop and router alert options [Re: Ques… Pekka Savola
- Re: hop-by-hop and router alert options [Re: Ques… James M. Polk
- RE: Question about use of RSVP in Production Netw… Fleischman, Eric
- RE: Question about use of RSVP in Production Netw… John Loughney
- Re: Question about use of RSVP in Production Netw… Bob Natale
- Re: Question about use of RSVP in Production Netw… Dan Wing
- RE: Question about use of RSVP in Production Netw… Bob Natale
- RE: Question about use of RSVP in Production Netw… Tony Hain
- RE: Question about use of RSVP in Production Netw… Fleischman, Eric
- RE: Question about use of RSVP in Production Netw… Dean Anderson