Oh, certainly if the intermediate layer's variant of fragmentation is better than IP's, sure - SEAL has similar benefits.
Your 4th bullet point is the one I hope we can start objecting to, though - if IP can't allow fragments, it's not IP and we should simply return that sort of mislabeled equipment (presuming it says "supports IP"). On your last point regarding UDP ports, that should matter only for IPv4. For IPv6, the flow ID is a better place to coordinate path fate-sharing. Joe On 6/1/2016 4:57 PM, Tom Herbert wrote: > On Wed, Jun 1, 2016 at 4:36 PM, Joe Touch <to...@isi.edu> wrote: >> >> On 6/1/2016 3:50 PM, Templin, Fred L wrote: >>> Any tunnel that traverses a 1280 link has to fragment, but instead of outer >>> fragmentation >>> it should use tunnel fragmentation which is something I have been >>> advocating for a very >>> long time. The tunnel egress should configure at least a 2KB reassembly >>> buffer size. >> If the only layer you have that fragments is the outermost IP, that's >> where you MUST do it. >> >> Sure, if you can fragment at an intermediate "transport" layer inside of >> IP, that's also an option. I'm not sure why it should be preferred >> except for the flaws of current equipment in supporting standards, though. >> > We defined fragmentation option in GUE > (draft-herbert-gue-fragmentation-02). The listed benefits are: > > o A 32 bit identifier can be defined to avoid issues of the 16 bit > Identification in IPv4. > > o Encapsulation mechanisms for security and identification such as > virtual network identifiers can be applied to each segment. > > o This allows the possibility of using alternate fragmentation and > reassembly algorithms (e.g. fragmentation with Forward Error > Correction). > > o Fragmentation is transparent to the underlying network so it is > unlikely that fragmented packet will be unconditionally dropped > as might happen with IP fragmentation. > > We should probably add that all fragments will have the same outer > addresses and UDP ports in the encapsulation so it is likely that all > the fragments will follow the same path. Security means that we can > cover fragmentation information with checksum or stronger integrity > checks. > > This option probably only makes use of fragmentation a little more > palatable, but doesn't change the fact that it's better to avoid > having to fragment in the first place if at all possible ;-). > > Tom > >> Joe >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
