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

Ole Troan <otroan@employees.org> Tue, 03 September 2019 21:22 UTC

Return-Path: <otroan@employees.org>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCA81200B6; Tue, 3 Sep 2019 14:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9WfkQWS_YvV; Tue, 3 Sep 2019 14:22:03 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64527120052; Tue, 3 Sep 2019 14:22:03 -0700 (PDT)
Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:c078:25d5:41c9:cf20:c136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id CCFCA4E11B87; Tue, 3 Sep 2019 21:22:02 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 505F81B6B160; Tue, 3 Sep 2019 23:22:00 +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 <otroan@employees.org>
In-Reply-To: <09d0dc428430407f8154f40d47a417dc@boeing.com>
Date: Tue, 3 Sep 2019 23:22:00 +0200
Cc: Bob Hinden <bob.hinden@gmail.com>, Tom Herbert <tom@herbertland.com>, Joel Halpern <joel.halpern@ericsson.com>, "draft-ietf-intarea-frag-fragile@ietf.org" <draft-ietf-intarea-frag-fragile@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, IESG <iesg@ietf.org>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <67823455-8FCB-4C9E-8B78-41F2E99BDC21@employees.org>
References: <156751558566.9632.10416223948753711891.idtracker@ietfa.amsl.com> <B7C5DF29-92B2-477B-9C30-F47E338038EE@strayalpha.com> <efabc7c9f72c4cd9a31f56de24669640@boeing.com> <9331E721-F7F8-4C22-9BE4-E266726B3702@gmail.com> <7bfbaf5fa12c4a9bac3e46ece5dfdcde@boeing.com> <0BF34BFA-5F30-4EE1-9F5E-18D9ECA8D424@gmail.com> <CALx6S37xhhS5ezhJu6-HQmftwY9cBzuCxeaW9thTbKBa2hizcw@mail.gmail.com> <A8A10E03-6EEC-4F60-A213-7D66084BA754@gmail.com> <09d0dc428430407f8154f40d47a417dc@boeing.com>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/EriQu7vveK10dt05APYzTv3NZPg>
Subject: Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 21:22:05 -0000

Fred,

>> 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.
Outer fragmentation will look like any other fragmented packet, albeit that the tunnel tail now has to reassemble. At speeds typically much higher than a typical end host.
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".

In summary, I don't think the text can say very much more than what it already does.

Cheers,
Ole