To respond to myself, I will say that RFC6438 permits the tunnel ingress to set the flow label in the way in which it sees fit (i.e., in the spirit of RFC6437) which may or may not depend on the flow label values in the actual payload packets.
So, if the ingress uses a module function that maps the tuples of the packets it carries into just a few flow labels to be used in the encapsulation header (say, 4 or 5 values) then the ingress can test all of those paths and can shut down the tunnel if any one or more path consistently fails to acknowledge a 1280 byte probe. The drawbacks are that there may be many ECMP/LAG paths that go unused, and the more distinct flow label values the ingress uses the more probes will be necessary. Still, why not keep the tunnel up by using fragmentation and alert the network operations staff? The staff can then take action to either find and fix the link(s) that have a too-small MTU or they can shut down the tunnel in a managed fashion. Or, they can just let it continue to fragment if fragmentation isn't a problem. Thanks - Fred [email protected] > -----Original Message----- > From: Int-area [mailto:[email protected]] On Behalf Of Templin, Fred L > Sent: Friday, April 24, 2015 8:11 AM > To: Joe Touch; Ronald Bonica; [email protected] > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > 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 _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
