Bob, > -----Original Message----- > From: Bob Hinden [mailto:[email protected]] > Sent: Tuesday, September 03, 2019 1:57 PM > To: Tom Herbert <[email protected]> > Cc: Bob Hinden <[email protected]>; Templin (US), Fred L > <[email protected]>; [email protected]; IESG > <[email protected]>; Joel Halpern <[email protected]>; > [email protected]; [email protected] > 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 <[email protected]> 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 <[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
