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> Thu, 05 September 2019 15:17 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 309531200F5; Thu, 5 Sep 2019 08:17:42 -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 egI58oFHm-2w; Thu, 5 Sep 2019 08:17:39 -0700 (PDT)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 8A5F0120019; Thu, 5 Sep 2019 08:17:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x85FHa9Q030648; Thu, 5 Sep 2019 11:17:37 -0400
Received: from XCH16-07-11.nos.boeing.com (xch16-07-11.nos.boeing.com [144.115.66.113]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x85FHR7G029439 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 5 Sep 2019 11:17:27 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-11.nos.boeing.com (144.115.66.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Thu, 5 Sep 2019 08:17:26 -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; Thu, 5 Sep 2019 08:17:26 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Fernando Gont <fgont@si6networks.com>, Tom Herbert <tom@herbertland.com>, Bob Hinden <bob.hinden@gmail.com>
CC: "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//wU8wgAAXiWGAAALCEIAAgfGAgACWxRCAARG4gIAAl5Zw
Date: Thu, 5 Sep 2019 15:17:26 +0000
Message-ID: <a4ea8ea336af482ab7ce19339a6d26d8@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> <4219167a-9375-ec11-95f1-5de8890acf1d@si6networks.com> <a350be1628c44ced925545d09458e827@boeing.com> <273bac52-6b75-55a1-4938-b39623385b3c@si6networks.com> <0c07dda545e94847b09012f0464d0f9d@boeing.com> <69007a2d-3bc7-ed79-7fdc-1dbe4a7ddfa5@si6networks.com>
In-Reply-To: <69007a2d-3bc7-ed79-7fdc-1dbe4a7ddfa5@si6networks.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: AF6E22BAEE3BDF4509E1B2471334C692EED2166E5462B318B162D0CACC8942F12000: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/5yqGEQCJom8MqMieo1YqRRBZYjw>
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 15:17:43 -0000

Fernando,

The ingress uses IPv6 fragmentation per the letter of RFC8200 and conveys those
fragments over the underlying internetwork (e.g., the Internet) to the egress which
then gets to reassemble. If there are multiple independent internetworks lined up
in succession, there may be many re-encapsulating "waypoints" on the path. But,
only the final egress reassembles - again, per RFC8200.

The appearance of the fragments on the underlying internetwork(s) does not
matter - as long as the letter of RFC8200 is upheld, it is none other than good old
IPv6 fragmentation/reassembly.

Fred

> -----Original Message-----
> From: Fernando Gont [mailto:fgont@si6networks.com]
> Sent: Wednesday, September 04, 2019 4:04 PM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>om>; Tom Herbert <tom@herbertland.com>om>; Bob Hinden
> <bob.hinden@gmail.com>
> Cc: 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)
> 
> On 4/9/19 16:46, Templin (US), Fred L wrote:
> > Hi Fernando,
> >
> >> -----Original Message-----
> >> From: Fernando Gont [mailto:fgont@si6networks.com]
> >> Sent: Tuesday, September 03, 2019 2:45 PM
> >> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>om>; Tom Herbert <tom@herbertland.com>om>; Bob Hinden
> >> <bob.hinden@gmail.com>
> >> Cc: 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)
> >>
> >> On 4/9/19 00:02, Templin (US), Fred L wrote:
> >>> Fernando,
> >>>
> >>>> -----Original Message-----
> >>>> From: Fernando Gont [mailto:fgont@si6networks.com]
> >>>> Sent: Tuesday, September 03, 2019 1:49 PM
> >>>> To: Tom Herbert <tom@herbertland.com>om>; Bob Hinden <bob.hinden@gmail.com>
> >>>> Cc: 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)
> >>>>
> >>>> On 3/9/19 23:33, Tom Herbert 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".
> >>>>>
> >>>>> 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.
> >>>>
> >>>> Discussion is not measurements. Do you have measurements that suggest
> >>>> otherwise?
> >>>>
> >>>> We did separate measurements, with different methodologies, and they
> >>>> suggest the same thing. You can discuss as much as you want. But that
> >>>> will not make fragmentation work.
> >>>>
> >>>>
> >>>>
> >>>>> 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.
> >>>>
> >>>> "fragile" means that it fails in an uncceptably large number of cases.
> >>>> ~30 failure rate is not acceptable. ~20% isn't, either.
> >>>
> >>> What if we fragment the payload packet instead of the delivery packet?
> >>> Wouldn't that give a 0% failure rate?
> >>
> >> Sure. At which point you are using ip fragmentation in a limited domain,
> >> and that's *not* the case this document is addressing, right?
> >
> > As I just answered to Ole, it is not only for limited domains but also for over
> > the open Internet. The fragmentation footprint is the same as the tunnel
> > footprint.
> 
> Sorry, maybe I'm missing something: If you fragment the outeer packet,
> you better don't because fragmentation is fragile. If you fragment the
> inner packet, the the outer packet is not fragmented, so from the pov of
> the Internet you're not generating fragmented traffic.
> 
> Am I missing something?
> 
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
>