Hi Joe, Then, instead of saying "shut the tunnel down" you should say "shut the path down". As in, test over all of the distinct flows the tunnel will spread traffic over then shut down only those paths that consistently fail to pass a 1280 packet.
Only if all paths consistently fail to pass a 1280 should you consider shutting the tunnel down. Or, instead, start fragmenting. That is for when the original source can reasonably expect to receive PTBs from the path to the tunnel ingress and the tunnel ingress can reasonably expect to receive PTBs from the path to the tunnel ingress. When that is not the case, the probe size should be 1500. Thanks - Fred [email protected] > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Friday, April 24, 2015 8:53 AM > To: Templin, Fred L > Cc: Ronald Bonica; [email protected] > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > > > > 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
