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. 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. 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. Tom Tom On Tue, Sep 3, 2019 at 1:01 PM Bob Hinden <[email protected]> wrote: > > Fred, > > > On Sep 3, 2019, at 12:45 PM, Templin (US), Fred L > > <[email protected]> wrote: > > > > Bob, > > > >> -----Original Message----- > >> From: Bob Hinden [mailto:[email protected]] > >> Sent: Tuesday, September 03, 2019 9:10 AM > >> To: Templin (US), Fred L <[email protected]> > >> Cc: Bob Hinden <[email protected]>; Joe Touch <[email protected]>; > >> Alissa Cooper <[email protected]>; Joel Halpern > >> <[email protected]>; [email protected]; > >> [email protected]; IESG <[email protected]>; intarea- > >> [email protected] > >> 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 > >>> <[email protected]> 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:[email protected]] On Behalf Of Joe Touch > >>>> Sent: Tuesday, September 03, 2019 7:06 AM > >>>> To: Alissa Cooper <[email protected]> > >>>> Cc: Joel Halpern <[email protected]>; > >>>> [email protected]; [email protected]; The IESG > >> <[email protected]>; > >>>> [email protected] > >>>> 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 > >>>>> <[email protected]> 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 > >>>>> [email protected] > >>>>> https://www.ietf.org/mailman/listinfo/int-area > >>>> > >>>> _______________________________________________ > >>>> Int-area mailing list > >>>> [email protected] > >>>> https://www.ietf.org/mailman/listinfo/int-area > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
