IETF Logo Mail Archive

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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Fri, 24 April 2015 15:11 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7AC1A19EF for <int-area@ietfa.amsl.com>; Fri, 24 Apr 2015 08:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDVEzU8D_Jf6 for <int-area@ietfa.amsl.com>; Fri, 24 Apr 2015 08:11:27 -0700 (PDT)
Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29AA71A8891 for <int-area@ietf.org>; Fri, 24 Apr 2015 08:11:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3OFBObV022938; Fri, 24 Apr 2015 10:11:24 -0500
Received: from XCH-PHX-213.sw.nos.boeing.com (xch-phx-213.sw.nos.boeing.com [130.247.25.142]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3OFBI2W022771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 24 Apr 2015 10:11:18 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-PHX-213.sw.nos.boeing.com ([169.254.13.122]) with mapi id 14.03.0235.001; Fri, 24 Apr 2015 08:11:17 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Joe Touch <touch@isi.edu>, Ronald Bonica <rbonica@juniper.net>, "int-area@ietf.org" <int-area@ietf.org>
Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt
Thread-Index: AdB4lrxZWs10twsqTRutwXmGaisuPwAHGYjgASLWx3AAAvjv0AAjISpwAAGQugAAD5EnAAAOb1BQ//+XYQCAAHSM8P//kM8AgABx5ZD//5iGgIAAdApw//+TYwAADZY24AALfiiAACVsSzAAO1gQAACFLEUgAQaxedAB/JnHAAPlqi0g
Date: Fri, 24 Apr 2015 15:11:17 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832E511A5@XCH-BLV-504.nw.nos.boeing.com>
References: <CO1PR05MB44210DA85F9DC93A7FF7F42AEE40@CO1PR05MB442.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D9831832E50576@XCH-BLV-504.nw.nos.boeing.com> <55391AB2.4080701@isi.edu> <2134F8430051B64F815C691A62D9831832E5062E@XCH-BLV-504.nw.nos.boeing.com> <553923CE.4080504@isi.edu> <2134F8430051B64F815C691A62D9831832E506CC@XCH-BLV-504.nw.nos.boeing.com> <5539284C.4020103@isi.edu> <2134F8430051B64F815C691A62D9831832E5078D@XCH-BLV-504.nw.nos.boeing.com> <55393109.4090405@isi.edu> <2134F8430051B64F815C691A62D9831832E508D5@XCH-BLV-504.nw.nos.boeing.com> <55393744.5070004@isi.edu> <2134F8430051B64F815C691A62D9831832E50A62@XCH-BLV-504.nw.nos.boeing.com> <55394551.8020103@isi.edu> <2134F8430051B64F815C691A62D9831832E50ADE@XCH-BLV-504.nw.nos.boeing.com> <55394C76.1050108@isi.edu> <2134F8430051B64F815C691A62D9831832E50B67@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E50C65@XCH-BLV-504.nw.nos.boeing.com> <5539746A.5020306@isi.edu>
In-Reply-To: <5539746A.5020306@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <http://mailarchive.ietf.org/arch/msg/int-area/yGWADb1gqHnWZvat9Fbr184tKnQ>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Apr 2015 15:11:31 -0000

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.

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
fred.l.templin@boeing.com

v2.23.0 | Report a Bug | By Email