Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <163CD364-2975-467A-8925-F114FFD9C422@employees.org>
Date: Fri, 6 Sep 2019 07:14:29 -0700
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: <E00B6159-2771-42D8-B5E8-7750E0B828DE@strayalpha.com>
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>
To: Ole Troan <otroan@employees.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/fFzJnJPOvHupbNaQ9VlbEGYScLM>
Subject: Re: [Int-area] Discussion about Section 6.1 in
 draft-ietf-intarea-frag-fragile
Precedence: list

Comments below.=20

> On Sep 5, 2019, at 11:33 PM, Ole Troan <otroan@employees.org> wrote:
>=20
> Bob, et al,
>=20
> I have two issues with this text.
>=20
> 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.

>=20
> 2) Paragraph 4:
>   "The risks of IP fragmentation can also be mitigated
>   through the use of encapsulation, e.g., by transmitting IP fragments
>   as payloads."
>=20
>   This seems like proposing new unspecified solutions with it's own =
set
>   of considerations.

Specific widely-deployed methods are mentioned elsewhere in the doc, =
including GRE and UDP.

>   IP fragmentation is a general solution to all hosts,
>   encapsulation is certainly not in every host,

Actually, it is - unless you=E2=80=99re claiming hosts don=E2=80=99t =
support UDP.

> and has different
>   properties with regards to NAT traversal etc.

If by =E2=80=9Cdifferent=E2=80=9D you mean =E2=80=9Cmuch more likely to =
succeed=E2=80=9D, agreed.

> vAlso if encapsulation
>   was the answer, other segmentation / reassembly that were tunnel
>   specific could be developed.

It is and is widely used - IPsec tunnels over UDP, e.g.

>  Regardless this also amounts of hand-waving
>   and doesn't seem to offer any advice that can be heeded now.
>   And of course encapsulation can also exacerbate the problem
>   by increasing packet size.

Yes, it makes the fragments smaller, which may be additional =
effort/performance impact, but it completely hides its impact on =
successful forwarding.

---=