Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

Ole Troan <otroan@employees.org> Fri, 06 September 2019 16:03 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 B0B99120026; Fri, 6 Sep 2019 09:03:20 -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=unavailable 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 YOodzaGF4sVr; Fri, 6 Sep 2019 09:03:14 -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 7EC261200E9; Fri, 6 Sep 2019 09:03:14 -0700 (PDT)
Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:c078:7ca7:62aa:16a8:5548]) (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 6FFF54E11B0A; Fri, 6 Sep 2019 16:03:13 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 4919D1BB30E9; Fri, 6 Sep 2019 18:03:11 +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: <939AFA6F-4C75-4532-82DE-77D14ABC41ED@strayalpha.com>
Date: Fri, 6 Sep 2019 18:03:11 +0200
Cc: Bob Hinden <bob.hinden@gmail.com>, "int-area@ietf.org" <int-area@ietf.org>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, IESG <iesg@ietf.org>, Joel Halpern <joel.halpern@ericsson.com>, "draft-ietf-intarea-frag-fragile@ietf.org" <draft-ietf-intarea-frag-fragile@ietf.org>, Suresh Krishnan <suresh@kaloom.com>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5C51DCDC-4031-47D9-A28E-812D0E66EE35@employees.org>
References: <efabc7c9f72c4cd9a31f56de24669640@boeing.com> <2EB90A57-9BBD-417C-AEDB-AFBFBB906956@gmail.com> <CAHw9_iKozCAC+8TGS0fSxVZ_3pJW7rnhoKy=Y3AxLqWEXvemcA@mail.gmail.com> <4C8FE1C4-0054-4DA1-BC6E-EBBE78695F1B@gmail.com> <BYAPR05MB5463F112A3FFA8CE6378F3D3AEBB0@BYAPR05MB5463.namprd05.prod.outlook.com> <ab0d5600-d71c-9f0b-2955-64074e040bc6@strayalpha.com> <E770BEF0-D901-4CD0-96E6-C626B560DCD6@gmail.com> <163CD364-2975-467A-8925-F114FFD9C422@employees.org> <E00B6159-2771-42D8-B5E8-7750E0B828DE@strayalpha.com> <3764D860-BC6F-441A-86EF-59E1742D7654@employees.org> <939AFA6F-4C75-4532-82DE-77D14ABC41ED@strayalpha.com>
To: Joe Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/PhaF_TRWMm-xGH0Zhujj4sN6v3c>
Subject: Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
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: Fri, 06 Sep 2019 16:03:21 -0000

Joe,

edited to focus on the two added "recommendation sentences".

>>>> 1) It introduces something new and undescribed in paragraph 2.
>>>> "unless they also include mechanisms to detect that IP fragmentation isn't working
>>>> reliably."
>>>> That seems like hand-waving to me. Suggest deleting.
>>> 
>>> Fragmentation success or failure is directly testable. Any feedback mechanism will work and specific ones are mentioned elsewhere (PLPMTUD).
>>> 
>>> This differs from ICMP black-holing in path MTU detection.
>> 
>> Can you please point me to where in the PLPMTUD document testing for IP fragmentation is described?
> 
> Any feedback mechanism will detect when fragmentation - or anything else - prevents delivery.

Any pointer to such a mechanism in any IETF protocol?
Would be interesting to get transport/application perspective on this.
But unless there is a reference I would claim this is hand-waving.

[...]

> If you fragment and put the result inside GRE or UDP, the impact of the fragment (interfering with flow-based multi path routing, nat traversal, etc) is overcome.

Sure, but that only applies to tunnels that go end to end. And any development of new tunnel mechanisms don't need to depend on IP fragmentation.
This is essentially link-layer (the tunnel provides a new link layer) fragmentation and reassembly.
It would anyway have to do that to deal with IPv4 DF=1 and IPv6.

This document should not recommend IP in UDP in IP encapsulation to achieve end to end IP fragmentation for new applications.

If this paragraph has to be there it would be more accepting to have it in the "Legacy protocols" parapgraph above.

  Legacy protocols that depend upon IP fragmentation SHOULD be updated
  to break that dependency.  However, in some cases, there may be no
  viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP-
  in-IP encapsulation).  Applications and protocols cannot necessarily
  know or control whether they use lower layers or network paths that
  rely on such fragmentation.  In these cases, the protocol will
  continue to rely on IP fragmentation but should only be used in
  environments where IP fragmentation is known to be supported.
  The risks of IP fragmentation can also be mitigated	
  through the use of encapsulation, e.g., by transmitting IP fragments	
  as payloads.

Cheers,
Ole