On Wed, Apr 1, 2015 at 12:55 PM, Joe Touch <to...@isi.edu> wrote: > > > On 3/25/2015 9:58 PM, Tom Herbert wrote: >> This draft describes a fragmentation option for GUE. The option is >> intended for use cases where GUE is used over a network where we might >> not be able to control or know what the link MTUs in a tunnel are. >> This also provides a answer to the interesting degenerative case where >> someone configures an MTU of 1280 on the link and there is an attempt >> to encapsulate an IPv6 packet of size 1280-- in this case the packet >> size + encapsulation > link MTU & we cannot send a ICMP PTB since 1280 >> is specified minimum MTU for IPv6. >> >> This describes only the mechanics of fragmentation/reassembly in GUE. >> It does cover the the semantics of use such as how to determine tunnel >> Path MTU, when to fragment. > > FWIW, there are a few issues that should be addressed. RFC4459 suggests > a taxonomy, but it's informational (and IMO incorrect) on a few points. > > Below are suggestions. > > Joe > > --- > > Section 1, also Sec 3.1: > > There are two separate trigger points for MTU handling: > > A- the tunnel path MTU > this is defined by the protocols over > which the tunnel is defined to operate > > B- the tunnel egress reassembly maximum > this is specified by the tunnel protocol > description > > The following cases should be handled as follows: > > 1. encaps packet <= A > send as-is > > 2. A < encaps packet <= B > fragment and reassemble > > 3. encaps packet >B > drop and send PTB >
Thanks, Joe. We can probably add some general guidelines like this to the draft. I think #3 is provided for when the link MTU of tunnel <= B. > If you don't want to ever do frag/reassembly, then make sure A=B. > > Note that A cannot match B whenever a tunnel mechanism is used > "recursively", e.g., GUE over GUE, even indirectly (GUE over IP over GUE). > Each tunneling layer should have its own concept of both link MTU and path MTU for the tunnel. So the link MTU in an inner tunnel could define the path MTU in an outer tunnel. > --- > > The wrap of the IPv4 frag field and the impact of avoiding fragmentation > is described in RFC 6864. > Will add a reference to that RFC. Thanks, Tom _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
