Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

Joe Touch <touch@isi.edu> Wed, 15 February 2017 21:09 UTC

Return-Path: <touch@isi.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E53129B67; Wed, 15 Feb 2017 13:09:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 q35r9USeQVjr; Wed, 15 Feb 2017 13:09:10 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70598129B64; Wed, 15 Feb 2017 13:09:10 -0800 (PST)
Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v1FL8m87008923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Feb 2017 13:08:49 -0800 (PST)
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
To: otroan@employees.org, Stewart Bryant <stewart.bryant@gmail.com>
References: <148665359396.20513.9749548375095869760.idtracker@ietfa.amsl.com> <2997d33f-3884-7831-50ed-1713c93b3867@gmail.com> <b9dfd941-0eba-c257-fef4-2f5e6bbd82a8@gmail.com> <078b28a9a26540da9e4caaba4c436cd3@XCH15-06-08.nw.nos.boeing.com> <440c60d3-0687-c7f1-f8b6-19620e6f618a@gmail.com> <6cb665e0a2244dae93e1b5b91bd9495a@XCH15-06-08.nw.nos.boeing.com> <fce8c0ef-25b7-9ba7-a5bf-9b5d7f2b19fc@gmail.com> <f4f81574e09e45169438d39afeb83369@XCH15-06-08.nw.nos.boeing.com> <1fb9a3ad-19e5-0b35-d15a-e74fed88bb8b@gmail.com> <57307617-C87C-4430-B92A-59E28C6779CD@employees.org>
From: Joe Touch <touch@isi.edu>
Message-ID: <b7a65660-2cc5-8461-c1c4-21b94fd65166@isi.edu>
Date: Wed, 15 Feb 2017 13:08:47 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <57307617-C87C-4430-B92A-59E28C6779CD@employees.org>
Content-Type: multipart/alternative; boundary="------------007E84B2003B9732A6018B39"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/5Id8IM9o4VOiGRqPCHcSR5zr-Y8>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, 6man WG <ipv6@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-6man-rfc1981bis.all@ietf.org" <draft-ietf-6man-rfc1981bis.all@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2017 21:09:12 -0000

Hi, Ole,


On 2/14/2017 10:33 AM, otroan@employees.org wrote:
>> *If*  you care about packet loss, then your only option is to probe the path with with
>> synthetic data that exactly mimics the live data, or not to probe at all and live
>> with the 1280. As I said 1280 is pretty close to 1496 which is all most networks
>> will give you in practice.
> Yes, but sending at 1280 does not work for IP tunnels. The whole purpose of the minimum MTU was to give space for tunnel headers (1500-1280).
I'm in the process of revising draft-intarea-tunnels to make this more
clear, as well as to provide a TSV ART review of this doc, but in preface:

There are two IPv6 minimum sizes: link MTU of 1280 and EMTU_R of 1500.

Support for source fragmentation and the difference between these two
values is what gives space for tunnel headers.

No amount of link MTU management can ever avoid source fragmentation
without violating the link MTU minimums in RFC2460.

Joe