Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

Ole Troan <> Wed, 04 September 2019 14:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 408B11201C6; Wed, 4 Sep 2019 07:37:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yU97_wzjMAHB; Wed, 4 Sep 2019 07:37:12 -0700 (PDT)
Received: from ( [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 80038120100; Wed, 4 Sep 2019 07:37:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 705DE4E11A64; Wed, 4 Sep 2019 14:37:11 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 824951B7D732; Wed, 4 Sep 2019 16:37:08 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Ole Troan <>
In-Reply-To: <>
Date: Wed, 4 Sep 2019 16:37:08 +0200
Cc: Bob Hinden <>, Tom Herbert <>, Joel Halpern <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: "Templin (US), Fred L" <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Sep 2019 14:37:22 -0000


I removed the IESG from this list, as we seem to have drifted into a more general fragmentation discussion as opposed to discussing the exact changes to this draft.

>>>> Why is that more useful than what is in 3.5? If it’s not making a recommendation, why call this out in the introduction.  There are lot
>> of
>>>> other things it doesn’t make recommendations about that aren’t in the Introduction either.
>>> Because it sets a more appropriate tone and lets the reader know from the onset that
>>> fragmentation and encapsulation go hand in hand. And tunnel fragmentation avoids the
>>> issues raised by others in this thread.
>> While inner fragmentation ensures the fragment will reach the tunnel tail end, a tunnel endpoint will typically not reassemble that
>> fragment, so will generate fragments after the tunnel hop.
>> Inner fragmentation is only available on IPv4.
> Not true. For IPv6 packets, simply insert a GUE header or an RFC2473 header and
> fragment on that. The fragments will be reassembled by the tunnel tail end, then
> passed to the next hop as a whole IPv6 packet. The fragmentation footprint is
> therefore the same as the tunnel footprint.

Is that not the exact definition of outer fragmentation?

>> Outer fragmentation will look like any other fragmented packet,
> I am not talking about outer fragmentation.


>> albeit that the tunnel tail now has to reassemble. At speeds typically
>> much higher than a typical end host.
> Using iperf3, I can show fragmentation and reassembly at near line-rate on 10Gbps
> Ethernet gear. That seems pretty good to me. Which shows that implementers
> have taken IP fragmentation seriously and put in the hard work necessary to
> optimize the performance.

On what hardware?
10G is not at all very much, and given fragmentation you have large packets anyway.
You need to compare the forwarding performance unfragmented versus fragmented.
Then impact of out of order fragments. Fragment chains that don't reassemble, etc etc.
Proving that it performs (or not as I would claim) does require quite a bit of work.

>> Tunnels within a controlled domain may use fragmentation, although it still will have problems.
>> Which is why you see most tunnel specifications for controlled domains, state that the network MTU must be "well managed".
> We should be able to tunnel within any domain, be it controlled or over the open Internet.
> Inner fragmentation (with nested encapsulation if necessary) accomplishes that.

Sure, you can just slap a UDP header in between. It still be outer fragmentation, but you have hidden it from the intermediate network.
Then you might as well invent your own shim tunnel fragment header, and we could deprecate the IPv6 one. (slight smiley on that idea:)