Re: Death by extension header (was:RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt)
Toerless Eckert <tte@cs.fau.de> Mon, 13 July 2020 19:33 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988983A03FF for <ipv6@ietfa.amsl.com>; Mon, 13 Jul 2020 12:33:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.118
X-Spam-Level:
X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmhvMhzgUUmg for <ipv6@ietfa.amsl.com>; Mon, 13 Jul 2020 12:33:56 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0213A0744 for <6man@ietf.org>; Mon, 13 Jul 2020 12:33:56 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A8F6C548068; Mon, 13 Jul 2020 21:33:51 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A1426440043; Mon, 13 Jul 2020 21:33:51 +0200 (CEST)
Date: Mon, 13 Jul 2020 21:33:51 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Tom Herbert <tom@herbertland.com>
Cc: Fernando Gont <fgont@si6networks.com>, "6man@ietf.org" <6man@ietf.org>, Fernando Gont <fernando@gont.com.ar>
Subject: Re: Death by extension header (was:RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt)
Message-ID: <20200713193351.GD38490@faui48f.informatik.uni-erlangen.de>
References: <DM6PR05MB6348708352E1EE4421A61D63AE650@DM6PR05MB6348.namprd05.prod.outlook.com> <CALx6S34e21BLHRfx+p7agrzzDsx-M-XxB6cZQnWc-d0wqSesRQ@mail.gmail.com> <20200710183228.GV42197@faui48f.informatik.uni-erlangen.de> <6fc66168-f04c-c23e-856c-5a61e1a28f5f@gont.com.ar> <CALx6S37T_7JYW=93iOhaHaq_Kw1CsaFc37sjT3Bo4Sx_wtbfqQ@mail.gmail.com> <c1ecb592-6e99-0dca-90c5-51a19b893af5@si6networks.com> <CALx6S36m75249_Gk33n-6ZEahfod6hi5snD0u07ZjCPhH0fj7Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CALx6S36m75249_Gk33n-6ZEahfod6hi5snD0u07ZjCPhH0fj7Q@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_09x0-eE9NluQVq2nm_T5qBVUhI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jul 2020 19:34:00 -0000
On Mon, Jul 13, 2020 at 11:53:08AM -0700, Tom Herbert wrote: > Wrt byte length, the most interesting limit with regards to routers is > when the aggregate length of the header chain exceeds the size of the > parsing buffer in the device. As I understand it common lengths of > parsing buffers are 128, 256, or 512 bytes. That might suggest the > default minimum should be 128 bytes or maybe 256 bytes. That is, we > would expect that routers should be able to process IP header, > extension headers, and first four bytes of transport header (e.g. to > get ports for ECMP) fit in the parsing buffer in the first N bytes of > the packet. We can narrow this down if the standard is followed such > that routers only process the IPv6 and HBH headers, intermediate > destinations in a routing header only process headers through the > routing header, and end hosts process all options. Indeed, the parsing depth is a key criteria. There is also the question of how high the cost of rewrites in the packet header is. That is much less clear to me. Programming languages like P4 make it look as if you could arbitrarily reshuffle headers, but the compiled code might expose extremely different performance output based on the amount of rewrites. For example, when we do PE-P-PE designs, we typically create a new additional encap to minimize lookup depth for P nodes. And the overhead of this is particularily big for IPv6. Leander headers or reordering header fields might be a better cost effective option going forward. Hard to say. Would be great to collect researched data points. Cheers Toerless > Tom > > > > Thanks, > > -- > > Fernando Gont > > SI6 Networks > > e-mail: fgont@si6networks.com > > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- --- tte@cs.fau.de
- Death by extension header (was:RE: New Version No… Ron Bonica
- Re: Death by extension header (was:RE: New Versio… Tom Herbert
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- RE: Death by extension header (was:RE: New Versio… Ron Bonica
- Re: Death by extension header (was:RE: New Versio… Tom Herbert
- Re: Death by extension header (was:RE: New Versio… Warren Kumari
- RE: Death by extension header (was:RE: New Versio… Ron Bonica
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- Re: Death by extension header (was:RE: New Versio… Fernando Gont
- Re: Death by extension header (was:RE: New Versio… Fernando Gont
- Re: Death by extension header (was:RE: New Versio… Tom Herbert
- Re: Death by extension header (was:RE: New Versio… Fernando Gont
- Re: Death by extension header (was:RE: New Versio… Tom Herbert
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- Re: Death by extension header (was:RE: New Versio… Tom Herbert
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- Re: Death by extension header Fernando Gont
- Re: Death by extension header (was:RE: New Versio… Fernando Gont
- Re: Death by extension header Tom Herbert
- RE: Death by extension header (was:RE: New Versio… Ron Bonica
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- RE: Death by extension header (was:RE: New Versio… Pengshuping (Peng Shuping)
- Re: Death by extension header (was:RE: New Versio… Gyan Mishra
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- RE: Death by extension header (was:RE: New Versio… Jakob Heitz (jheitz)
- Re: Death by extension header (was:RE: New Versio… Tom Herbert
- Re: Death by extension header Joel M. Halpern
- Re: Death by extension header (was:RE: New Versio… Robert Raszuk
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- Re: Death by extension header (was:RE: New Versio… Toerless Eckert
- Re: Death by extension header (was:RE: New Versio… Gyan Mishra
- Re: Death by extension header (was:RE: New Versio… Jeff Tantsura
- Re: Death by extension header Brian E Carpenter
- Re: Death by extension header (was:RE: New Versio… Gyan Mishra
- Re: Death by extension header Toerless Eckert
- Re: Death by extension header (was:RE: New Versio… Philip Homburg
- Re: Death by extension header Nick Hilliard
- Re: Death by extension header (was:RE: New Versio… Robert Raszuk
- Re: Death by extension header Toerless Eckert
- Re: Death by extension header Toerless Eckert