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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Wed, 04 September 2019 13:43 UTC

Return-Path: <Fred.L.Templin@boeing.com>
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 385AC12010F; Wed, 4 Sep 2019 06:43:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Q2OQjmTSpqJl; Wed, 4 Sep 2019 06:43:52 -0700 (PDT)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C72120130; Wed, 4 Sep 2019 06:43:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x84DholH031778; Wed, 4 Sep 2019 09:43:50 -0400
Received: from XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x84Dhk3X031414 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 4 Sep 2019 09:43:46 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-10.nos.boeing.com (144.115.66.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Wed, 4 Sep 2019 06:43:44 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1713.004; Wed, 4 Sep 2019 06:43:44 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Ole Troan <otroan@employees.org>
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>
Thread-Topic: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)
Thread-Index: AQHVYleCBj1oQLuY7U2rnGqsdj7a9acaci8A//+QwwCAAJHEgP//wU8wgAAZmpyAAAHqEIAAel8AgACZknA=
Date: Wed, 04 Sep 2019 13:43:44 +0000
Message-ID: <1f5edd49236649929599820764dedb4e@boeing.com>
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> <67823455-8FCB-4C9E-8B78-41F2E99BDC21@employees.org>
In-Reply-To: <67823455-8FCB-4C9E-8B78-41F2E99BDC21@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: F9E61EE77471A20FE0B4031E3BBE3EC2B54C4698872F62D6D6A04C11917B69AD2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/_2XwSmvEaoJyBoeQO3J1Oa684r4>
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: Wed, 04 Sep 2019 13:43:56 -0000

Hi Ole,

> -----Original Message-----
> From: Ole Troan [mailto:otroan@employees.org]
> Sent: Tuesday, September 03, 2019 2:22 PM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> 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; int-area@ietf.org; IESG <iesg@ietf.org>; intarea-chairs@ietf.org
> Subject: Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)
> 
> 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.

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.

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

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

Thanks - Fred
fred.l.templin@boeing.com

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