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

Joe Touch <touch@isi.edu> Thu, 16 February 2017 21:43 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 0B418129629; Thu, 16 Feb 2017 13:43:14 -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 S3zi_UkbCitB; Thu, 16 Feb 2017 13:43:13 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 0ADF512967D; Thu, 16 Feb 2017 13:43:13 -0800 (PST)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v1GLggFI007094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Feb 2017 13:42:42 -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> <e6176571-2ff9-dd63-11b3-c713d61eebe2@isi.edu> <4c6539a9-75d1-81b8-be1e-5f5b26c10750@gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <f2e2972e-04ca-ca9c-91e1-b12f816c9380@isi.edu>
Date: Thu, 16 Feb 2017 13:42:42 -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: <4c6539a9-75d1-81b8-be1e-5f5b26c10750@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/ipv6/CTNudEVkh0pbAK41Ux3zzpgh9h4>
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:43:14 -0000


On 2/16/2017 1:29 PM, Stewart Bryant wrote:
>
>
> On 16/02/2017 18:49, Joe Touch wrote:
>>
>> 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";
>
> In the MPLS world an "MPLS tunnel" is a common name for an MPLS LSP that
> is used to carry some payload such as IP.

MPLS just adds the label tags; there's no length field.  It's only a
tunnel when it goes over some other encapsulation layer, e.g., IP or
Ethernet.

>
>> 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.
>
> It was of course IPv6 over MPLS that concerned me.

IPv6 over MPLS isn't yet a tunnel. It would be IPv6 over MPLS over IPv6,
presumably (IPv6 over IPv4 isn't guaranteed to work because IPv4 EMTU_R
is only 576, and for an IPv6 tunnel it would be required to be at least
1280+encaps).

An IPv6 packet can traverse an IPv6 over MPLS over Ethernet tunnel (with
a 1500B payload) as long as the MPLS headers are smaller than 1500-1280
bytes.

An IPv6 packet can traverse an IPv6 over MPLS over IPv6 tunnel as long
as the MPLS + added IPv6 headers are smaller than 1500-1280 bytes.
However, if the arriving (transit) packet is larger than
1280-MPLS-IPv6ecaps, the MPLS tunnel ingress would need to do source
fragmentation inside the tunnel (with the egress doing reassembly).

Again, all these cases are discussed in draft-ietf-intarea-tunnels but
none have relevance IMO to this doc.

Joe