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. 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. 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. Thanks - Fred [email protected] > See "tragedy of the commons". > > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
