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

Tschofenig Hannes <hannes.tschofenig@siemens.com> Wed, 11 August 2004 13:01 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 JAA01431; Wed, 11 Aug 2004 09:01:41 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BusoP-0006zH-Fg; Wed, 11 Aug 2004 09:06:37 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Busgo-00031G-5c; Wed, 11 Aug 2004 08:58:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BusZS-0001dg-0v for ietf@megatron.ietf.org; Wed, 11 Aug 2004 08:51:10 -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 IAA00895 for <ietf@ietf.org>; Wed, 11 Aug 2004 08:51:08 -0400 (EDT)
Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuseB-0006oH-Ec for ietf@ietf.org; Wed, 11 Aug 2004 08:56:04 -0400
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id i7BCp40T009185; Wed, 11 Aug 2004 14:51:04 +0200
Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i7BCogNW027337; Wed, 11 Aug 2004 14:50:52 +0200
Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <P8C2SD7C>; Wed, 11 Aug 2004 14:50:42 +0200
Message-ID: <2A8DB02E3018D411901B009027FD3A3F046864BA@mchp905a.mch.sbs.de>
From: Tschofenig Hannes <hannes.tschofenig@siemens.com>
To: 'Pekka Savola' <pekkas@netcore.fi>, ietf@ietf.org
Date: Wed, 11 Aug 2004 14:50:08 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Subject: RE: hop-by-hop and router alert options [Re: Question about use o f 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: 92df29fa99cf13e554b84c8374345c17

hi pekka, 

if you want to discover nodes somewhere along the path (between a particular
source and a destination address) then you have a limited number of choices.
the router alert option is one option and certainly not better or worse than
other options. 

do you have a suggestion how to accomplish the same functionality (as
required by rsvp or similar protocols) in a better fashion?

ciao
hannes
 

> 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.
> 
> 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