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

Fernando Gont <fgont@si6networks.com> Thu, 05 September 2019 14:37 UTC

Return-Path: <fgont@si6networks.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 E3C0C1200F7; Thu, 5 Sep 2019 07:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 no-xRA0oMMoC; Thu, 5 Sep 2019 07:37:26 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE4B1200EF; Thu, 5 Sep 2019 07:37:25 -0700 (PDT)
Received: from [192.168.1.14] (ppp-94-69-228-25.home.otenet.gr [94.69.228.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 90AB18622D; Thu, 5 Sep 2019 16:37:23 +0200 (CEST)
To: Tom Herbert <tom@herbertland.com>
Cc: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, Ole Troan <otroan@employees.org>, Bob Hinden <bob.hinden@gmail.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>
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> <4461d66b-797c-4a14-b721-b6089221f1e1@si6networks.com> <CALx6S34hZX+OdT5yyw3Jh-iHZ3mRNsFuHXsaZnpZHevGaGifrg@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Openpgp: preference=signencrypt
Message-ID: <df9e008d-65bf-fcfd-1efb-0a762262dd87@si6networks.com>
Date: Thu, 05 Sep 2019 17:37:07 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CALx6S34hZX+OdT5yyw3Jh-iHZ3mRNsFuHXsaZnpZHevGaGifrg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/vEKn3HaMbypfzbQK0h19q0RWARU>
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: Thu, 05 Sep 2019 14:37:28 -0000

On 5/9/19 17:31, Tom Herbert wrote:
> On Wed, Sep 4, 2019 at 5:34 PM Fernando Gont <fgont@si6networks.com> wrote:
>>
>> On 4/9/19 18:26, Templin (US), Fred L wrote:
>>> Hi Ole,
>>>
>>>> -----Original Message-----
>>>> From: Ole Troan [mailto:otroan@employees.org]
>>>> Sent: Wednesday, September 04, 2019 7:37 AM
>>>> 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
>>>> Subject: Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)
>>>>
>>>> Fred,
>>>>
>>>> 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?
>>>
>>> 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
>>
>> This looks like a recent claim from the IAB that QUIC has shown that it
>> is possible to deploy new transport protocols on the Internet. -- when
>> quick employs UDP, and hence from the pov of the Internet, UDP is the
>> transport protocol.
>>
>> Same with your example: you are tunneling your fragments. The Internet
>> will not see fragments. *That* is why it would work.
>>
>> i.e., if you want fragmentation to not be fragile on the Internet, the
>> trick is that packets shouldn't look like fragmens ;-)
>>
> Fernando,
> 
> Sure, if we dress up protocols in UDP there is a greater probability
> they can traverse the Internet. But this doesn't always work and it's
> fallacious to think that unbiquitously solves the problem of protocol
> ossification.

I fully agree with that. In fact, encapsulating transport protocols in
UDP *circumvents* the problem -- it doesn't actually fix it.



>  I really wish the IAB would look at the issues of wide
> spread middlebox non-conformance-- this is the root problem and a
> fundamental deterrent to evolving the Internet IMO.

FWIW, I did ask about this in the context of EH-insertion on the IAB's
architecture list.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492