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. 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. Having tunnels do work to play IPv6 doesn't mean the sources are lazy in not supporting capabilities outside the scope of IPv6. > 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. Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
