Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt

["Templin, Fred L" <[e-mail]>]

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
[e-mail]



> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Friday, April 24, 2015 8:53 AM
> To: Templin, Fred L
> Cc: Ronald Bonica; [e-mail]
> 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 <[e-mail]> wrote:
> >
> > Hi Joe,
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[e-mail]]
> >> Sent: Thursday, April 23, 2015 3:39 PM
> >> To: Templin, Fred L; Ronald Bonica; [e-mail]
> >> 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