Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Monday, March 02, 2015 10:49 AM > To: Templin, Fred L; Ronald Bonica; Carlos Pignataro (cpignata) > Cc: [email protected] > Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 > > > > On 3/2/2015 10:30 AM, Templin, Fred L wrote: > > Hi Joe, > > > >> -----Original Message----- > >> From: Joe Touch [mailto:[email protected]] > >> Sent: Monday, March 02, 2015 10:13 AM > >> To: Templin, Fred L; Ronald Bonica; Carlos Pignataro (cpignata) > >> Cc: [email protected] > >> Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 > >> > >> > >> > >> On 3/2/2015 10:08 AM, Templin, Fred L wrote: > >>>> So you're talking about updating RFC2460 to allow on-path fragmentation > >>>>> of source fragments. I disagree with that, for the same reasons it was > >>>>> omitted from IPv6 in the first place. > >>> > >>> In this case, the tunnel ingress uses on-path fragmentation of the payload > >>> packet instead of link-specific fragmentation of the delivery packet. The > >>> tunnel egress is therefore excused from having to reassemble. That is > >>> better than link-specific fragmentation and reassembly, and will make > >>> for a better IPv6 Internet. > >> > >> I disagree. This method, IMO, simply lets tunnels make work that > >> endpoints need to clean up. > > > > Actually, the very best solution would be for the original source itself to > > do the fragmentation - that way, the tunnel ingress never has to. > > That is viable only if we have no lower bound on fragment size.
I was thinking that a reasonable lower bound on frag size could be something like 750 (1/2 of 1500). Or maybe 576 (slightly more than 1/3 of 1500). > If we did (do), then that would be the min MSS, and it will always be a > problem at some point. > > > In the > > scenario I am describing, the tunnel ingress is actually having to work hard > > on behalf of original sources that are too lazy to do the work themselves. > > If the tunnel can't transport min-MSS datagrams, it is the ingress that > is causing the problem by claiming to support a protocol (IPv6) when it > does not. You will have to tell that to the draft-ietf-intarea-gre-ipv6 authors, because they are saying to do exactly that. > Having tunnels do work to play IPv6 doesn't mean the sources are lazy in > not supporting capabilities outside the scope of IPv6. It doesn't scale for tunnels to support thousands or millions of end systems all placing a heavy frag/reass burden on them. > > That hurts the tunnel ingress, which only hurts the original source. > > > >> It trades profit for tunnel equipment > >> vendors (who get to make what I consider to be underpowered equipment) > >> at the expense of endpoints. > > > > How bad is that, really, Joe? The most we will ever ask the endpoints to > > fragment and reassemble is 1500; everything larger than that will go as > > one piece or not at all. In the long run, it is in the endpoints' best > > interest > > to offload the tunnel ingress and egress. > > For every reason you want to allow the tunnel to offload work to the > endpoints, I think it is equally fair (if not more fair) to ask the > egress to clean up the mess made by the source. Asking to the egress to reassemble on behalf of great multitudes of end systems doesn't scale. And, in the end, all end systems suffer. Thanks - Fred [email protected] > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
