[mpls] The first nibble issue associated with MPLS encapsulation

Xuxiaohu <xuxiaohu@huawei.com> Thu, 07 April 2016 17:40 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EF23B12D5D0; Thu, 7 Apr 2016 10:40:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id IznpSBdWNGjQ; Thu, 7 Apr 2016 10:40:01 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD3412D5A1; Thu, 7 Apr 2016 10:39:59 -0700 (PDT)
Received: from (EHLO lhreml705-cah.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGZ94521; Thu, 07 Apr 2016 17:39:56 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com ( by lhreml705-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Thu, 7 Apr 2016 18:39:55 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([]) with mapi id 14.03.0235.001; Fri, 8 Apr 2016 01:39:49 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Tony Przygienda <tonysietf@gmail.com>, "bier@ietf.org" <bier@ietf.org>
Thread-Topic: The first nibble issue associated with MPLS encapsulation
Thread-Index: AQHRkPR7Ow6l9wh8WUKpFJXl+MwAqA==
Date: Thu, 07 Apr 2016 17:39:49 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871CNKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57069B6D.013A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 76c0900cb14475b246c81dcc3d30b04a
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/xnJdm9iQ1xy_QZmdkAuJsLU3ZgM>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Subject: [mpls] The first nibble issue associated with MPLS encapsulation
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 07 Apr 2016 17:40:05 -0000

As for the first nibble issue, will it violate the layering principle of network protocol stacks if the first nibble of any new encapsulation header (which could be an MPLS payload) is used as the "MPLS payload type" field? wouldn't it  be more reasonable and sustainable to fix the problem (i.e., the lack of a protocol field in the MPLS header) by the MPLS header itself?

By the way, since it's claimed that the NSH is transport-independant, it means the NSH should be able to be transported over MPLS. However, it seems that the first nibble issue has not be considered in the current NSH draft. As a result, when encapsulating NSH over MPLS, the NSH may be mis-interpreted as IP header.

Best regards,


发件人: BIER [bier-bounces@ietf.org] 代表 Tony Przygienda [tonysietf@gmail.com]
发送时间: 2016年4月5日 22:36
收件人: bier@ietf.org
主题: [Bier] comments on draft-wang-bier-ethernet-01

after reading

a) first nibble: refer to MPLS encaps as "the same value" to keep in sync
b) refer to all other possible fields to MPLS encaps to keep in sync when describing instead of repeating
c) you need to describe which kind of ether MACs are allowed, especially on broadcast media, i.e. is it always p2p or can you take advantage of the broadcast ?
d) Figure 4: use the architecture/MPLS encoding for the length, don't invent a new one
e) who will obtain a new ether type from IEEE? As far I understand, not a trivial process albeit we have several liaisons with IEEE

We’ve heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.
―Robert Wilensky