On 5/9/19 17:31, Tom Herbert wrote: > On Wed, Sep 4, 2019 at 5:34 PM Fernando Gont <[email protected]> wrote: >> >> On 4/9/19 18:26, Templin (US), Fred L wrote: >>> Hi Ole, >>> >>>> -----Original Message----- >>>> From: Ole Troan [mailto:[email protected]] >>>> Sent: Wednesday, September 04, 2019 7:37 AM >>>> To: Templin (US), Fred L <[email protected]> >>>> Cc: Bob Hinden <[email protected]>; Tom Herbert <[email protected]>; >>>> Joel Halpern <[email protected]>; draft- >>>> [email protected]; [email protected] >>>> Subject: Re: [Int-area] Alissa Cooper's No Objection on >>>> draft-ietf-intarea-frag-fragile-16: (with COMMENT) >>>> >>>> Fred, >>>> >>>> I removed the IESG from this list, as we seem to have drifted into a more >>>> general fragmentation discussion as opposed to discussing >>>> the exact changes to this draft. >>>> >>>>>>>> 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. >>>>>> >>>>>> While inner fragmentation ensures the fragment will reach the tunnel >>>>>> tail end, a tunnel endpoint will typically not reassemble that >>>>>> fragment, so will generate fragments after the tunnel hop. >>>>>> Inner fragmentation is only available on IPv4. >>>>> >>>>> Not true. For IPv6 packets, simply insert a GUE header or an RFC2473 >>>>> header and >>>>> fragment on that. The fragments will be reassembled by the tunnel tail >>>>> end, then >>>>> passed to the next hop as a whole IPv6 packet. The fragmentation >>>>> footprint is >>>>> therefore the same as the tunnel footprint. >>>> >>>> Is that not the exact definition of outer fragmentation? >>> >>> No. I am talking about outer header (OH) followed by tunnel header (TH) >>> followed >>> by inner packet (IP). Recipe: >>> >>> 1) wrap the IP in a TH to create a tunnel packet (TP) >>> 2) fragment the TP >>> 3) encapsulate each tunnel fragment in an independent OH >>> 4) send each outer packet (OP). These will look like ordinary >>> unfragmented IP packets, but will contain a tunnel fragment >> >> This looks like a recent claim from the IAB that QUIC has shown that it >> is possible to deploy new transport protocols on the Internet. -- when >> quick employs UDP, and hence from the pov of the Internet, UDP is the >> transport protocol. >> >> Same with your example: you are tunneling your fragments. The Internet >> will not see fragments. *That* is why it would work. >> >> i.e., if you want fragmentation to not be fragile on the Internet, the >> trick is that packets shouldn't look like fragmens ;-) >> > Fernando, > > Sure, if we dress up protocols in UDP there is a greater probability > they can traverse the Internet. But this doesn't always work and it's > fallacious to think that unbiquitously solves the problem of protocol > ossification.
I fully agree with that. In fact, encapsulating transport protocols in UDP *circumvents* the problem -- it doesn't actually fix it. > I really wish the IAB would look at the issues of wide > spread middlebox non-conformance-- this is the root problem and a > fundamental deterrent to evolving the Internet IMO. FWIW, I did ask about this in the context of EH-insertion on the IAB's architecture list. Thanks, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
