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

Joe Touch <touch@isi.edu> Thu, 16 February 2017 18:50 UTC

Return-Path: <touch@isi.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CED91294F8; Thu, 16 Feb 2017 10:50:40 -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 MAWj4OS1eig9; Thu, 16 Feb 2017 10:50:39 -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 C1BD4127077; Thu, 16 Feb 2017 10:50:39 -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 v1GIo0Ch014046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Feb 2017 10:50:00 -0800 (PST)
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
To: Stewart Bryant <stewart.bryant@gmail.com>, "Templin, Fred L" <Fred.L.Templin@boeing.com>, Brian E Carpenter <brian.e.carpenter@gmail.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>
From: Joe Touch <touch@isi.edu>
Message-ID: <e6176571-2ff9-dd63-11b3-c713d61eebe2@isi.edu>
Date: Thu, 16 Feb 2017 10:49:58 -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: <01055a07-c5b6-b9c2-f953-ad6aa45de511@gmail.com>
Content-Type: text/plain; charset="windows-1252"
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/ietf/7Njb0etOA5DJ5pVvsD206VcUUJw>
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: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2017 18:50:41 -0000


On 2/16/2017 7:59 AM, 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.

IMO, this doc shouldn't be discussing tunneling as any different from
any other link.

> 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.

There's no such thing as an "MPLS tunnel"; at best, it's "MPLS over X",
e.g., MPLS over ethernet. MPLS doesn't indicate a message length so
while it can't support fragmentation it would never need it either. It
would be the next layer down (e.g., Ethernet, ATM, etc.) that might have
needed fragmentation.  If that can't be supported, then the addition of
MPLS would just reduce the effective MTU of the MPLS-over-X link.

Joe