[mpls] RFC3032 IPv6 MTU and Fragmentation Handling in MPLS

"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Sat, 29 August 2020 08:00 UTC

Return-Path: <xiejingrong@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9C33A11D7 for <mpls@ietfa.amsl.com>; Sat, 29 Aug 2020 01:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 HVHONADz3-3I for <mpls@ietfa.amsl.com>; Sat, 29 Aug 2020 01:00:28 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67F453A11D6 for <mpls@ietf.org>; Sat, 29 Aug 2020 01:00:28 -0700 (PDT)
Received: from lhreml722-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id ACEB1401CB0EA94F272C for <mpls@ietf.org>; Sat, 29 Aug 2020 09:00:24 +0100 (IST)
Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Sat, 29 Aug 2020 09:00:24 +0100
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml708-chm.china.huawei.com (10.98.57.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Sat, 29 Aug 2020 16:00:21 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Sat, 29 Aug 2020 16:00:21 +0800
From: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
To: "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: RFC3032 IPv6 MTU and Fragmentation Handling in MPLS
Thread-Index: AdZ92c40HeA4TrkEQdGGZH2Hne3kcw==
Date: Sat, 29 Aug 2020 08:00:21 +0000
Message-ID: <670f6b5c6d29411281449cdfcb4a3848@huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.202.118]
Content-Type: multipart/alternative; boundary="_000_670f6b5c6d29411281449cdfcb4a3848huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/-OS2YJELKEYPeM4owfLHTuAwzlg>
Subject: [mpls] RFC3032 IPv6 MTU and Fragmentation Handling in MPLS
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Aug 2020 08:00:30 -0000

Hello,
I am reading rfc3032 regarding the IPv6 MTU and Fragmentation handling in MPLS technology.
I feel that there is some issue in section 3.5 step 4.
I have checked the errata to rfc3032, and update RFCs as listed in https://tools.ietf.org/html/rfc3032, but failed to find any issue or update about this topic.
Do I miss something or understand something wrong ?

Detailed understanding and questions:
(1) The section 3.5 step 4 says "If the IP datagram is not larger than 1280 octets, and it contains a fragment header, then ... Convert it into fragments".
Does that mean an "Overlapping Fragment" or "cascaded fragment" ?

(2) Seems like it should be "If the IP datagram is not larger than 1280 octets, and it *doesn't* contain a fragment header, then ...Convert it into fragments".
And the following "Reassembly of the fragments will be done at the destination hosts" seems very well reflect the motivation of this approach.
However, this action is something obviously wrong. It damages a customer's packet, and imposes burden to the host.
Seems to me the right action is to configure the "Maximum Initially Labeled IP Datagram Size" no less than 1280 to convey an IPv6 packet on an Ingress LSR (Section 3.2) ?

Thanks
Jingrong