Re: [mpls] The first nibble issue associated with MPLS encapsulation

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Fri, 08 April 2016 18:25 UTC

Return-Path: <cpignata@cisco.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 6CBBB12D1B6; Fri, 8 Apr 2016 11:25:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 7JRy2AazpRaQ; Fri, 8 Apr 2016 11:25:01 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D52312D0DA; Fri, 8 Apr 2016 11:25:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18279; q=dns/txt; s=iport; t=1460139901; x=1461349501; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1cyZjRKPxzXh4QWLnZWQrpumAGulu07/L3skIFOKguI=; b=cuZOldjV7wqbqUQ0EBXEbyNN4JtYZxbdx+5RWVVo93xlyBcK8RjEGaqf I9nsFGOMns0ONxR7pyw5baD1Dyln+rOEJnTEohpVmUff2AKLWjB5ljOnI gwNg75ugS7qi7NLiDR2z4RWUjKD+vy1fdVn+LTliK8XEDYO3vcFrwRW+k 0=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAgAp9gdX/4wNJK1cgmtMU30GrmeGZ?= =?us-ascii?q?YRzDoFzFwEJhWwCgTM4FAEBAQEBAQFlJ4RBAQEBAwEBAQEgSwsFCwIBBgISBic?= =?us-ascii?q?DAgIhBgsUAw4CBA4FCQWIBAMKCA6RWp0XjEINhSEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQENCIYhgXUIgk6CQYIFJgmCSiuCKwWTGYQ6MQGDI4FmbYJygy6BdYFnhE2?= =?us-ascii?q?IWYdKh1oBHgFDg2dsiDt+AQEB?=
X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="asc'?scan'208,217";a="259203294"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2016 18:24:59 +0000
Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u38IOxr1010852 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 18:24:59 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 14:24:58 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 14:24:58 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Xiaohu Xu <xuxiaohu@huawei.com>
Thread-Topic: [mpls] The first nibble issue associated with MPLS encapsulation
Thread-Index: AQHRkPR7Ow6l9wh8WUKpFJXl+MwAqJ+AqQ4A
Date: Fri, 8 Apr 2016 18:24:58 +0000
Message-ID: <B664DB14-0A8C-4437-83E3-F9DA6C0DDA61@cisco.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.247.9]
Content-Type: multipart/signed; boundary="Apple-Mail=_96308AB7-A1EC-47DF-AA5E-35FBEE6ACEE6"; protocol="application/pgp-signature"; micalg=pgp-sha256
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/fxSjp9_Di63KDNQi484N0IzwABA>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "bier@ietf.org" <bier@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, "Dr. Tony Przygienda" <tonysietf@gmail.com>
Subject: Re: [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: Fri, 08 Apr 2016 18:25:04 -0000

Xiaohu, Tony,

Please see inline.

> On Apr 7, 2016, at 2:39 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> 
> 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?

Reading draft-wang-bier-ethernet-01, Section 3, the “first nibble” is _not_ used as an “MPLS payload type”. Instead, the text describes an anti-aliasing mechanism, much like RFC 4928.

The relevant text is:
     First nibble: The first 4 bits of the header are set to 0101; this
   ensures that the BIER header will not be confused with an IP header
   or with the header of a pseudowire packet.

Which says “… will not be confused with …"

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

Who says it is a *problem*? There’s no “fixing” needed.

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

There seems to be some massive confusion on this paragraph, on a number of levels. First, NSH is not “claimed to be” transport-independent. It is by charter and by design. Second, the NSH draft does not even include the term “MPLS”, because it does not define transports. The SFC Encapsulation can be used in a transport-agnostic way.

One more comment below.

> Best regards,
> Xiaohu
> 
> 发件人: BIER [bier-bounces@ietf.org <mailto:bier-bounces@ietf.org>] 代表 Tony Przygienda [tonysietf@gmail.com <mailto:tonysietf@gmail.com>]
> 发送时间: 2016年4月5日 22:36
> 收件人: bier@ietf.org <mailto: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

One comment regarding the “First nibble” text at draft-ietf-bier-mpls-encapsulation-03

Since the function of the first nibble is to prevent aliasing with an IP packet, in order for RFC 4928 to specify values of 0x0 and 0x1 for the First Nibble, it had to “Reserve” IP protocol versions of 0 and 1, referencing that RFC (see https://tools.ietf.org/html/rfc4928#section-5).

Is the intent to re-assign IPv5 at http://www.iana.org/assignments/version-numbers/ <http://www.iana.org/assignments/version-numbers/> ?

Note that RFC 4928 says “REQUIRED” at:

   It is REQUIRED, however, that applications depend upon in-order
   packet delivery restrict the first nibble values to 0x0 and 0x1.

Thanks,

— Carlos.


> 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
> _______________________________________________
> mpls mailing list
> mpls@ietf.org <mailto:mpls@ietf.org>
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>