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

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

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

> -----Original Message-----
> From: Int-area [mailto:[e-mail]] On Behalf Of Templin, Fred L
> Sent: Friday, April 24, 2015 8:11 AM
> To: Joe Touch; Ronald Bonica; [e-mail]
> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt
> 
> 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.
> 
> 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
> [e-mail]
> 
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area