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> Tue, 03 September 2019 21:10 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 CAA3A12004E; Tue, 3 Sep 2019 14:10:38 -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 7fAACgLPCngU; Tue, 3 Sep 2019 14:10:35 -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 667F7120043; Tue, 3 Sep 2019 14:10:35 -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 x83LAXJI027111; Tue, 3 Sep 2019 17:10:33 -0400
Received: from XCH16-07-08.nos.boeing.com (xch16-07-08.nos.boeing.com [144.115.66.110]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x83LASKR026083 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 3 Sep 2019 17:10:28 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-08.nos.boeing.com (144.115.66.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Tue, 3 Sep 2019 14:10:27 -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; Tue, 3 Sep 2019 14:10:27 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Bob Hinden <bob.hinden@gmail.com>, Tom Herbert <tom@herbertland.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//wU8wgAAZmpyAAAHqEA==
Date: Tue, 3 Sep 2019 21:10:26 +0000
Message-ID: <09d0dc428430407f8154f40d47a417dc@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>
In-Reply-To: <A8A10E03-6EEC-4F60-A213-7D66084BA754@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: F059FD1C9396D5F738812EB03865861258E6B3FEACC5AE3DA273F268970336772000: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/6VXi3iyrTiTOpQ3fhgf8bP2S1Dc>
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: Tue, 03 Sep 2019 21:10:39 -0000

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.

Thanks - Fred

> Bob
> 
> >
> > Speaking of balance, the introduction also mentions that:
> >
> > "this document recommends that upper-layer protocols address the
> > problem of fragmentation at their layer"
> >
> > But the "problem" of fragmentation is in intermediate devices that
> > don't properly handle it as the draft highlights. So it seems like
> > part of addressing the problem should also be to fix the problem! That
> > is implementations should be fixed to deal with fragmentation. IMO,
> > this should be another high level recommendation that is mentioned in
> > the introduction.
> 
> I am serving as document editor.  This to my understanding has been through w.g. last call and now IESG review.
> >
> > Tom
> >
> >
> >
> > Tom
> >
> >
> >
> >
> >
> > On Tue, Sep 3, 2019 at 1:01 PM Bob Hinden <bob.hinden@gmail.com> wrote:
> >>
> >> Fred,
> >>
> >>> On Sep 3, 2019, at 12:45 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 9:10 AM
> >>>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> >>>> Cc: Bob Hinden <bob.hinden@gmail.com>om>; Joe Touch <touch@strayalpha.com>om>; Alissa Cooper <alissa@cooperw.in>in>; Joel
> Halpern
> >>>> <joel.halpern@ericsson.com>om>; draft-ietf-intarea-frag-fragile@ietf.org; int-area@ietf.org; IESG <iesg@ietf.org>rg>; 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 7:33 AM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> >>>>>
> >>>>> Why was this section taken out:
> >>>>>
> >>>>>> 1.1.  IP-in-IP Tunnels
> >>>>>>
> >>>>>> 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.
> >>>>
> >>>> This text in the Introduction was removed because, as noted in Warren Kumari
> >>>> Comment (2019-08-07 for -15), this didn’t need to be in the introduction, and it didn’t say very much that isn’t described later in
> the
> >>>> document.
> >>>>
> >>>> The normative text in Section 5.3. "Packet-in-Packet Encapsulations” is unchanged.  I think Section 5.3 covers the topic.  It
> includes the
> >>>> reference to [I-D.ietf-intarea-tunnels].
> >>>
> >>> While I agree that both passages supply a working vector to 'intarea-tunnels',
> >>> the two strike very different tones. The former gives a balanced citation, while
> >>> the latter calls it a "corner case" - twice!
> >>>
> >>> Whether we like it or not, fragmentation and encapsulation will continue to
> >>> be associated with each other no matter what gets documented here. So,
> >>> a respectful handoff to 'intarea-tunnels' would be appreciated.
> >>
> >> You are talking about text in the Introduction of the document.
> >>
> >> The important substance relating to tunnels is in Section 5.3.   The text is:
> >>
> >>   5.3.  Packet-in-Packet Encapsulations
> >>
> >>   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.
> >>
> >> Seems fine to me, in tone and substance.
> >>
> >> Bob
> >>
> >>
> >>>
> >>> Fred
> >>>
> >>>> Bob
> >>>>
> >>>>
> >>>>>
> >>>>> Tunnels always inflate the size of packets to the point that they may exceed
> >>>>> the path MTU even if the original packet is no larger than the path MTU. And,
> >>>>> for IPv6 the only guarantee is 1280. Therefore, in order to robustly support
> >>>>> the minimum IPv6 MTU tunnels MUST employ fragmentation.
> >>>>>
> >>>>> Please put this section of text back in the document where it belongs.
> >>>>>
> >>>>> Thanks - Fred
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Joe Touch
> >>>>>> Sent: Tuesday, September 03, 2019 7:06 AM
> >>>>>> To: Alissa Cooper <alissa@cooperw.in>
> >>>>>> Cc: Joel Halpern <joel.halpern@ericsson.com>om>; draft-ietf-intarea-frag-fragile@ietf.org; int-area@ietf.org; The IESG
> >>>> <iesg@ietf.org>rg>;
> >>>>>> intarea-chairs@ietf.org
> >>>>>> Subject: Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)
> >>>>>>
> >>>>>> Hi, all,
> >>>>>>
> >>>>>> So let me see if I understand:
> >>>>>>
> >>>>>> Alissa issues a comment.
> >>>>>>
> >>>>>> We discuss this on the list and come to a rare consensus on a way forward.
> >>>>>>
> >>>>>> The new draft is issued that:
> >>>>>>
> >>>>>> a) ignores the list consensus
> >>>>>> b) removes a paragraph not under the DISCUSS (1.1)
> >>>>>> c) now refers to vague “other documents” without citation
> >>>>>> d) most importantly:
> >>>>>>
> >>>>>>   REMOVES a key recommendation that we MAY use frag where it works
> >>>>>>
> >>>>>>   Asserts the false claim that IP fragmentation “will fail” in the Internet,
> >>>>>>   despite citing evidence that the *majority of the time* it does work
> >>>>>>           e.g., for IPv6, sec 3.9
> >>>>>>
> >>>>>> What happened? Why is a change this substantial not reflecting the *list consensus*?
> >>>>>>
> >>>>>> Joe
> >>>>>>
> >>>>>>> On Sep 3, 2019, at 5:59 AM, Alissa Cooper via Datatracker <noreply@ietf.org> wrote:
> >>>>>>>
> >>>>>>> Alissa Cooper has entered the following ballot position for
> >>>>>>> draft-ietf-intarea-frag-fragile-16: No Objection
> >>>>>>>
> >>>>>>> When responding, please keep the subject line intact and reply to all
> >>>>>>> email addresses included in the To and CC lines. (Feel free to cut this
> >>>>>>> introductory paragraph, however.)
> >>>>>>>
> >>>>>>>
> >>>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> >>>>>>> for more information about IESG DISCUSS and COMMENT positions.
> >>>>>>>
> >>>>>>>
> >>>>>>> The document, along with other ballot positions, can be found here:
> >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ----------------------------------------------------------------------
> >>>>>>> COMMENT:
> >>>>>>> ----------------------------------------------------------------------
> >>>>>>>
> >>>>>>> Thanks for addressing my DISCUSS.
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Int-area mailing list
> >>>>>>> Int-area@ietf.org
> >>>>>>> https://www.ietf.org/mailman/listinfo/int-area
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Int-area mailing list
> >>>>>> Int-area@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/int-area
> >>>
> >>
> >> _______________________________________________
> >> Int-area mailing list
> >> Int-area@ietf.org
> >> https://www.ietf.org/mailman/listinfo/int-area