On Fri, Jul 27, 2018 at 5:38 AM, Fernando Gont <ferna...@gont.com.ar> wrote: > Hi, Joe, > > On 07/26/2018 04:14 AM, Joe Touch wrote: >> Hi, all, >> >> I still think it would be useful for this doc to describe how tunnels >> interact with fragmentation (per draft-ietf-intarea-tunnels), which seems to >> be something I’ve noted several times before. >> >> I’m also still not thrilled with the title I’d be happier with “IP >> fragmentation still not supported per requirements”, and I’d have to see >> where this goes with final recommendations. >> >> But I agree *some* statement is worthwhile here. My primary concern is that >> if we’re not careful, endorsing the status quo will only ensure nothing >> changes. > > FWIW, I see and understand your point. However, based on the operational > implications of fragmentation, it believe it is *extremely* unlikely > that the situation improves (if at all possible). > > So my take is that this I-D rather than endorsing the status quo, is > essentially warning possible users of what it may happen with their > fragmented traffic. > > Side coments: > > It would all seem that there are two operating environments: > * Controlled environments, where you can somehow make all this work > * Public internet, which is more of a "fingers crossed" thing (if anything). > > I'm not saying that I'm happy with the outcome, but rather that I think > that from an engenering point of view, it all looks like this ship has > sailed, and we should probably figure out how to deal with those cases > where fragmentation is actually needed. > Fernado,
Couldn't that same line of thinking be applied to several other protocol features? So has the ship sailed for out ability to ever use extension headers or any protocol other than TCP (and sometimes UDP)? Maybe documents that recommend operational workarounds should distinguish problems that inherent in the protocol from those that have arisen because of non-conformant implementation. It's true that calling implementations that probably won't help to fix what is out there, but maybe this could help prevent new instances of non-conformance. Tom > Thanks! > > Cheers, > -- > Fernando Gont > e-mail: ferna...@gont.com.ar || fg...@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > _______________________________________________ > 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
