> On Apr 24, 2015, at 8:11 AM, Templin, Fred L <[email protected]> > wrote: > > 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.
It is about positive vs negative confirmation. The rest are details. > 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. That is negative confirmation and we've already reviewed why that is not robust or safe. Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
