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

Joe Touch <touch@isi.edu> Thu, 16 February 2017 21:10 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 84C781296DF; Thu, 16 Feb 2017 13:10:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 OrWqTj9udy46; Thu, 16 Feb 2017 13:10:31 -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 22B001296A6; Thu, 16 Feb 2017 13:10:31 -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 v1GL9fQK017392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Feb 2017 13:09:42 -0800 (PST)
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Stewart Bryant <stewart.bryant@gmail.com>, "Templin, Fred L" <Fred.L.Templin@boeing.com>, "gen-art@ietf.org" <gen-art@ietf.org>
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> <cb03ceda3ecb4241ad867302a3195bf4@XCH15-06-08.nw.nos.boeing.com> <01055a07-c5b6-b9c2-f953-ad6aa45de511@gmail.com> <c65c6582-c874-9352-89cb-24c882c0516e@gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <9f298dea-88c9-3784-c87e-d33384fe8308@isi.edu>
Date: Thu, 16 Feb 2017 13:09:40 -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: <c65c6582-c874-9352-89cb-24c882c0516e@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
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/EbAdZAurrSL0lwaL6DWuAJxXZh0>
Cc: "ipv6@ietf.org" <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: Thu, 16 Feb 2017 21:10:35 -0000


On 2/16/2017 11:59 AM, Brian E Carpenter wrote:
> On 17/02/2017 04:59, Stewart Bryant wrote:
>>
>> On 14/02/2017 23:00, Templin, Fred L wrote:
>>> Unless there is operational assurance of
>>> some size X>1280, however, tunnels have to use fragmentation to
>>> guarantee that - at a minimum - packets up to 1280 will get through.
>> In that case there really needs to be a note about MPLS.
>>
>> You can fragment into an IP tunnel, but not an MPLS tunnel, because you 
>> cannot fragment the payload as you can in IPv4 and you cannot fragment MPLS.
> I'm confused. A tunnel end point that accepts IPv6 packets MUST accept packets
> of 1280 bytes (or shorter) and MUST emit them. How it gets them through the
> tunnel is irrelevant - if it's an ATM tunnel it has to chop them into 48 byte
> fragments and re-assemble them at the other end - if it's an avian carrier tunnel
> it might have to use several pigeons per packet*. None of this matters to the IPv6
> nodes concerned; the physical MTU of the tunnel technology is irrelevant except
> to the tunnel end points.
There are too many systems that try to optimize the link MTU to
represent the size of the payload of the link source, rather than the
reassembly limit of the link receiver.

It's trying to make PMTUD work multiple layers down rather than stopping
at the IP layer (which I think is where it should stop).

Joe