Re: hop-by-hop and router alert options [Re: Question about use of RSVP in Production Networks]

Martin Stiemerling <stiemerling@netlab.nec.de> Wed, 11 August 2004 13:15 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 JAA02530; Wed, 11 Aug 2004 09:15:53 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1But27-0007J4-B2; Wed, 11 Aug 2004 09:20:50 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Busom-0004nt-5p; Wed, 11 Aug 2004 09:07:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BushQ-00037u-UK for ietf@megatron.ietf.org; Wed, 11 Aug 2004 08:59:25 -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 IAA01329 for <ietf@ietf.org>; Wed, 11 Aug 2004 08:59:23 -0400 (EDT)
Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BusmB-0006x6-In for ietf@ietf.org; Wed, 11 Aug 2004 09:04:20 -0400
Received: from [10.1.1.109] (marseille.netlab.nec.de [195.37.70.15]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 557531BAC4D; Wed, 11 Aug 2004 14:58:50 +0200 (CEST)
Date: Wed, 11 Aug 2004 14:58:51 +0200
From: Martin Stiemerling <stiemerling@netlab.nec.de>
To: Pekka Savola <pekkas@netcore.fi>, ietf@ietf.org
Message-ID: <C247C5A2924B780EE4DE8B5D@[10.1.1.109]>
In-Reply-To: <Pine.LNX.4.44.0408111448190.24098-100000@netcore.fi>
References: <Pine.LNX.4.44.0408111448190.24098-100000@netcore.fi>
X-Mailer: Mulberry/3.1.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: 7bit
Subject: Re: hop-by-hop and router alert options [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: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: 7bit


--On Mittwoch, 11. August 2004 14:58 Uhr +0300 Pekka Savola 
<pekkas@netcore.fi> wrote:

| 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.
|
| I'd be interested about this as well, but also in more general.
|
| I'd be in favor of deprecating the IP router alert option completely.
| Effectively this affects RSVP and MLD *).  I'd want to similarly do
| away with the IPv6 Hop-by-Hop options.  At the very least, I'd like to
| prevent further standardization of these options.

Hmm, NSIS protocol suite (new protocol that does path-coupled QoS signaling 
ala RSVP and firewall/NAT signaling) relies on the use of router alert 
options for the initial NSIS peer discovery process.  Is there any other 
proposal to get a discovery mechanism like router alert options without the 
disadvantages of this option?

  Martin

|
| The justification is simple: any "magic" packets which all routers on
| the path must somehow examine and process seems a very dubious concept
| when we want to avoid DoS attacks etc. on the core equipment which
| must run on hardware: effectively this means that either these are
| ignored in any case (nullifying the use of such options), or put on a
| "slow path" (causing a potential for DoS).  IMHO, it seems just simply
| bad protocol design to require such behaviour.
|
| I'm interested what others think about this.. :)
|
| *) MLD should be relatively straight-forward to re-design (just send
| the MLD reports to a link-local address which the router is
| listening), or just keep it as is for now.  RSVP can probably thrown
| away without many tears.
|
| --
| Pekka Savola                 "You each name yourselves king, yet the
| Netcore Oy                    kingdom bleeds."
| Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
|
|
| _______________________________________________
| 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