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

Hi Joe,

> -----Original Message-----
> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Templin, Fred L
> Sent: Friday, April 24, 2015 9:34 AM
> To: Joe Touch
> Cc: Ronald Bonica; int-area@ietf.org
> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt
> 
> 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.

BTW, the AERO spec already does this kind of probing. Only, its
fallback position is to fragment instead of shut down paths that don't
work. The augmentation to the AERO spec therefore is to use RC6438
and test multiple flows and only shut down those that can't pass a probe.

Thanks - Fred
fred.l.templin@boeing.com

> Thanks - Fred
> fred.l.templin@boeing.com
> 
> 
> 
> > -----Original Message-----
> > From: Joe Touch [mailto:touch@isi.edu]
> > Sent: Friday, April 24, 2015 8:53 AM
> > To: Templin, Fred L
> > Cc: Ronald Bonica; int-area@ietf.org
> > 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 <Fred.L.Templin@boeing.com> wrote:
> > >
> > > Hi Joe,
> > >
> > >> -----Original Message-----
> > >> From: Joe Touch [mailto:touch@isi.edu]
> > >> Sent: Thursday, April 23, 2015 3:39 PM
> > >> To: Templin, Fred L; Ronald Bonica; int-area@ietf.org
> > >> 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
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area