Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Thursday, April 23, 2015 3:39 PM > To: Templin, Fred L; Ronald Bonica; [email protected] > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > > > On 4/23/2015 2:41 PM, Templin, Fred L wrote: > ... > > More importantly, failure to receive an ACK is not necessarily a sign > > of a path MTU limitation whereas receipt of a (good) NACK is. > > The reasons this is not true are addressed in detail in RFC 4821.
That is not correct; RFC4821 is about starting with a small size and advancing to larger sizes based on successful probes for a given (src, dst, flow-label)-tuple. Re-read what I said again in both of my last two messages: >> If your liveness detection is >> only checking some paths and not others, data packets may be black >> holing over other (untested) paths. and: > > More importantly, failure to receive an ACK is not necessarily a sign > > of a path MTU limitation whereas receipt of a (good) NACK is. Deterministic actions to shut down the tunnel can only be based on an actual report of packet loss due to a size restriction, i.e., a good PTB message that is not dropped due to filtering. Shutting down the tunnel when it should stay up can make vast expanses of networks go unreachable. Failure to shut down the tunnel when it should be down can result in black hole loss of packets within a certain size range. None of these concerns are problematic when operational assurances are in place and/or when fragmentation is used. Thanks - Fred [email protected] _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
