Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Thursday, April 23, 2015 9:16 AM > 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 8:58 AM, Templin, Fred L wrote: > ... > >> Beyond suggesting that the probing mechanism use a 1280-byte payload, we > >> have put the details of that probing mechanism out of > >> scope for this document. > > > > If a 1280 byte probe (which becomes 1280+ENCAPS bytes following > > encapsulation) succeeds along one path of a multipath, but would > > have failed along another path, then there is possibility for black > > holing. And, there is no way for the ingress to know that there > > may be ECMP or LAG on the path to the egress. Hence, having the > > ingress probe for the purpose of minimum MTU detection is > > problematic if there may be some kind of multipath. > > Probe success tells you only that. Probe loss tells you only that. > > IP allows loss, so strictly there's no reason to shut a tunnel down due > to loss. Burst lost or patterns of loss might be undesirable, but > they're allowed by IP. > > However, it might be useful to note that probe success isn't the only > issue; that probe loss over 1% might be considered problematic (using > the typical performance needed for 'reasonable' TCP progress).
That is fine, but the troubling condition is when the tunnel ingress successfully probes for 1280 (or 1500) but that same probe would have failed if it travelled along a different path. And, the ingress has no way of knowing whether there is ECMP or LAG on the path to the egress. Which returns us to fragmentation as I said a couple of messages back. Thanks - Fred [email protected] > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
