Fred, > On Sep 4, 2019, at 7:23 AM, Templin (US), Fred L <[email protected]> > wrote: > > Bob, > >> -----Original Message----- >> From: Bob Hinden [mailto:[email protected]] >> Sent: Tuesday, September 03, 2019 5:08 PM >> To: Templin (US), Fred L <[email protected]> >> Cc: Bob Hinden <[email protected]>; Tom Herbert <[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) >> >> Fred, >> >>> On Sep 3, 2019, at 2:10 PM, Templin (US), Fred L >>> <[email protected]> wrote: >>> >>> 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. >> >> 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. I will plan to include the new first paragraph in the next version. Bob
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
