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 15:52 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 AFA111208CA; Wed, 4 Sep 2019 08:52:10 -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 YngXlhkouRHf; Wed, 4 Sep 2019 08:52:07 -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 863741208BA; Wed, 4 Sep 2019 08:52:07 -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 x84Fq5Vs022385; Wed, 4 Sep 2019 11:52:05 -0400
Received: from XCH16-07-12.nos.boeing.com (xch16-07-12.nos.boeing.com [144.115.66.114]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x84Fq1jV021815 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 4 Sep 2019 11:52:01 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-12.nos.boeing.com (144.115.66.114) 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 08:52:00 -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 08:52:00 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Bob Hinden <bob.hinden@gmail.com>
CC: Tom Herbert <tom@herbertland.com>, "int-area@ietf.org" <int-area@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>, "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//wU8wgAAZmpyAAAHqEIAAqL2AgAB4AjCAAIlsAP//jSEA
Date: Wed, 4 Sep 2019 15:52:00 +0000
Message-ID: <02cd931c463b48b2b05422c6c6919a4d@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> <3AF76A3A-E18D-4CC2-8FA8-6A465FD06E28@gmail.com> <25c7130ecf734692a4f6746141d96038@boeing.com> <243A9D20-8F03-4401-93D4-AF291A91B600@gmail.com>
In-Reply-To: <243A9D20-8F03-4401-93D4-AF291A91B600@gmail.com>
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: F7AF2E33526C37032DEC976D7E42AD6CDFA098D0177A3487F372A9DC2E2166F52000: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/4jLY-AqnepIQIx0CrG3-fgUeYv4>
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:52:17 -0000

Hi Bob,

> -----Original Message-----
> From: Bob Hinden [mailto:bob.hinden@gmail.com]
> Sent: Wednesday, September 04, 2019 8:29 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Bob Hinden <bob.hinden@gmail.com>om>; Tom Herbert <tom@herbertland.com>om>; int-area@ietf.org; IESG <iesg@ietf.org>rg>; Joel
> Halpern <joel.halpern@ericsson.com>om>; draft-ietf-intarea-frag-fragile@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,
> 
> > On Sep 4, 2019, at 7:23 AM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> >
> > Bob,
> >
> >> -----Original Message-----
> >> From: Bob Hinden [mailto:bob.hinden@gmail.com]
> >> Sent: Tuesday, September 03, 2019 5:08 PM
> >> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> >> Cc: Bob Hinden <bob.hinden@gmail.com>om>; Tom Herbert <tom@herbertland.com>om>; int-area@ietf.org; IESG <iesg@ietf.org>rg>; Joel
> >> Halpern <joel.halpern@ericsson.com>om>; draft-ietf-intarea-frag-fragile@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,
> >>
> >>> On Sep 3, 2019, at 2:10 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> >>>
> >>> Bob,
> >>>
> >>>> -----Original Message-----
> >>>> From: Bob Hinden [mailto:bob.hinden@gmail.com]
> >>>> Sent: Tuesday, September 03, 2019 1:57 PM
> >>>> To: Tom Herbert <tom@herbertland.com>
> >>>> Cc: Bob Hinden <bob.hinden@gmail.com>om>; Templin (US), Fred L <Fred.L.Templin@boeing.com>om>; int-area@ietf.org; IESG
> >>>> <iesg@ietf.org>rg>; Joel Halpern <joel.halpern@ericsson.com>om>; draft-ietf-intarea-frag-fragile@ietf.org; intarea-chairs@ietf.org
> >>>> Subject: Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)
> >>>>
> >>>> Tom,
> >>>>
> >>>>> On Sep 3, 2019, at 1:33 PM, Tom Herbert <tom@herbertland.com> wrote:
> >>>>>
> >>>>> Bob,
> >>>>>
> >>>>> I agree with Fred. Note, the very first line of the introduction:
> >>>>>
> >>>>> "Operational experience [Kent] [Huston] [RFC7872] reveals that IP
> >>>>> fragmentation introduces fragility to Internet communication”.
> >>>>
> >>>> Yes, that text in in the first paragraph of the Introduction
> >>>>>
> >>>>> This attempts to frame fragmentation as being generally fragile with
> >>>>> supporting references. However, there was much discussion on the list
> >>>>> about operational experience that demonstrates fragmentation is not
> >>>>> fragile. In particular, we know that fragmentation with tunnels is
> >>>>> productively deployed and has been for quite some time. So that is the
> >>>>> counter argument to the general statement that fragmentation is
> >>>>> fragile. With the text about tunneling included in the introduction I
> >>>>> believe that was sufficient balance of the arguments, but without the
> >>>>> text the reader could be led to believe that fragmentation is fragile
> >>>>> for everyone all the time which is simply not true and would be
> >>>>> misleading.
> >>>>
> >>>> Yes, but we are discussing some text from the Introduction that to my read didn’t say anything useful so I removed it.  The
> >> substantive
> >>>> text about tunneling in in Section 3.5.  The Introduction, is just the introduction.  The text was:
> >>>>
> >>>>  This document acknowledges that in some cases, packets must be
> >>>>  fragmented within IP-in-IP tunnels [I-D.ietf-intarea-tunnels].
> >>>>  Therefore, this document makes no additional recommendations
> >>>>  regarding IP-in-IP tunnels.
> >>>
> >>> Yes - good text that should be retained.
> >>>
> >>>> 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.
> >>
> >> I don’t know how to evaluate “tone” in an IETF specification.
> >>
> >> How about if I move this text to section 5.3?  I think that’s better than in the Introduction.
> >>
> >> The section would be:
> >>
> >>   5.3.  Packet-in-Packet Encapsulations
> >>
> >>   This document acknowledges that in some cases, packets must be
> >>   fragmented within IP-in-IP tunnels.  Therefore, this document makes no
> >>   additional recommendations regarding IP-in-IP tunnels.
> >>
> >>   In this document, packet-in-packet encapsulations include IP-in-IP
> >>   [RFC2003], Generic Routing Encapsulation (GRE) [RFC2784], GRE-in-UDP
> >>   [RFC8086] and Generic Packet Tunneling in IPv6 [RFC2473].  [RFC4459]
> >>   describes fragmentation issues associated with all of the above-
> >>   mentioned encapsulations.
> >>
> >>   The fragmentation strategy described for GRE in [RFC7588] has been
> >>   deployed for all of the above-mentioned encapsulations.  This
> >>   strategy does not rely on IP fragmentation except in one corner case.
> >>   (see Section 3.3.2.2 of RFC 7588 and Section 7.1 of RFC 2473).
> >>   Section 3.3 of [RFC7676] further describes this corner case.
> >>
> >>   See [I-D.ietf-intarea-tunnels] for further discussion.
> >
> > Paragraph #1 beginning "This document acknowledges" looks good, but then
> > why include paragraphs #2 and #3 since 'intarea-tunnels' is the place to discuss
> > IP-in-IP encapsulation. So, why not shorten Section 5.3 and have it as simply:
> >
> >   5.3.  Packet-in-Packet Encapsulations
> >
> >   This document acknowledges that in some cases, packets must be
> >   fragmented within IP-in-IP tunnels.  Therefore, this document makes no
> >   additional recommendations regarding IP-in-IP tunnels.
> >   See [I-D.ietf-intarea-tunnels] for further discussion.
> >
> 
> This text has been through IETF last call and IESG review, and as far as I can tell is factually correct.   Unless we want to repeat that,
> better to not remove it in my view.

The problem with traditional approaches to tunnel MTU is that they all try very
hard to avoid exceeding the MTU of the smallest link in the path between
ingress and egress. Some guess that the smallest link is 1500 minus encaps
(e.g., 1480), some get more conservative and call it 1400 "just in case", etc.
But, trying to sleuth out the size of the restricting link on the path is just
guesswork when we all know that the *only* guarantee is 1280. So, why
not cut right to the heart of the matter and proactively fragment to a
fragment size of 1280-encaps.

If you are willing to allow for fragmentation to a known safe size, then it frees
you from the paradox of how to plumb the path for the restricting link MTU
(which remember can change at any time if the path changes). It also allows
you to specify larger sizes for the tunnel MTU. For example, AERO sets the
tunnel MTU to 9180, and that size works no matter what path fluctuations
may occur thanks to tunnel fragmentation.

So, I say set the tunnel MTU to 9180 (same as ATM) and forget about the
legacy approaches that think the tunnel MTU has to be limited by the
MTU of the smallest link in the path.

Fred

> I will plan to include the new first paragraph in the next version.
> 
> Bob
>