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

Ole Troan <otroan@employees.org> Wed, 04 September 2019 15:39 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 2F3FB1200FA; Wed, 4 Sep 2019 08:39:36 -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 9VpKsliO9Wrp; Wed, 4 Sep 2019 08:39:34 -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 800411200F4; Wed, 4 Sep 2019 08:39:34 -0700 (PDT)
Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:c078:bc56:dd51:6a5d:33a8]) (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 D3A0B4E11A78; Wed, 4 Sep 2019 15:39:33 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id B23661B813C6; Wed, 4 Sep 2019 17:39:31 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <47aafc6dbef24b2ba76b81f95dbbedcb@boeing.com>
Date: Wed, 4 Sep 2019 17:39:31 +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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <33291336-AB76-4B16-832F-AF493113D522@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> <67823455-8FCB-4C9E-8B78-41F2E99BDC21@employees.org> <1f5edd49236649929599820764dedb4e@boeing.com> <D80F747F-6F23-45C9-AE8B-5C059C5AC8DE@employees.org> <47aafc6dbef24b2ba76b81f95dbbedcb@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/apJvvW-gDy0zDfU_vFTfziNF5DA>
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 15:39:36 -0000

Fred,

>> Is that not the exact definition of outer fragmentation?
> 
> No. I am talking about outer header (OH) followed by tunnel header (TH) followed
> by inner packet (IP). Recipe:
> 
>  1) wrap the IP in a TH to create a tunnel packet (TP)
>  2) fragment the TP
>  3) encapsulate each tunnel fragment in an independent OH
>  4) send each outer packet (OP). These will look like ordinary
>       unfragmented IP packets, but will contain a tunnel fragment

Right you might as well define your own tunnel fragmentation then.
And it will have a lot less overhead. Doing "segmentation" at what would be layer 4 (or 3.5) isn't what we are trying to discourage here.

Cheers,
Ole