IETF Logo Mail Archive

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

Joe Touch <touch@isi.edu> Fri, 24 April 2015 15:54 UTC

Return-Path: <touch@isi.edu>
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 C4AD61A6EE1 for <int-area@ietfa.amsl.com>; Fri, 24 Apr 2015 08:54:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 YCiqp2ehoEn5 for <int-area@ietfa.amsl.com>; Fri, 24 Apr 2015 08:54:14 -0700 (PDT)
Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653411B30A7 for <int-area@ietf.org>; Fri, 24 Apr 2015 08:54:14 -0700 (PDT)
Received: from [192.168.1.4] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t3OFrECC028226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Apr 2015 08:53:38 -0700 (PDT)
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> <2134F8430051B64F815C691A! 62D9831832E511A5@XCH-BLV-504.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831832E511A5@XCH-BLV-504.nw.nos.boeing.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"
Message-Id: <7F6CD4A4-F93B-4015-B708-A0C0586D3FE3@isi.edu>
X-Mailer: iPad Mail (12F69)
From: Joe Touch <touch@isi.edu>
Date: Fri, 24 Apr 2015 08:53:10 -0700
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/int-area/ZCllb8Ghcl5bP-kMhfPNGJqta7A>
Cc: Ronald Bonica <rbonica@juniper.net>, "int-area@ietf.org" <int-area@ietf.org>
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:54:19 -0000


> 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

v2.23.0 | Report a Bug | By Email