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

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Tue, 12 April 2016 00:19 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 688E612F558; Mon, 11 Apr 2016 17:19:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level:
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, 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 7cLnZsB3-SxR; Mon, 11 Apr 2016 17:19:05 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245D912F542; Mon, 11 Apr 2016 17:19:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3939; q=dns/txt; s=iport; t=1460420344; x=1461629944; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JFjG4kU9+w9VEpdD8+CfcftwNlAMqEQ23V0nWObETaU=; b=lzuzikXsMmfWtf2FDj4HeCY+Yd7oFKxKUfGR1k4yPzXrdaVBWStQY80/ MqAeG8TIAFU7mKB5DY8yWhJ3EepM/VUZavX+kOjXHgfSzEj2N/ZjAXSzp 9t7hMuctdMGCnc3ZataHGKTOxeqMsSGl1IZQbEdPGhcTqhQ2QGadr4IN3 U=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAgChPQxX/5pdJa1dgzeBUAa4ToIPD?= =?us-ascii?q?oFyhg0CgTA4FAEBAQEBAQFlJ4RBAQEBAwEjVgULAgEIGCoCAjIlAgQOBQ6IEQi?= =?us-ascii?q?td5IiAQEBAQEBAQEBAQEBAQEBAQEBAQEOCIYhgXUIgk6HPyuCKwWYBAGDI4Fmi?= =?us-ascii?q?QKPDY8lAR4BQ4IEGYFKbIkHfgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.24,471,1454976000"; d="asc'?scan'208";a="260139644"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2016 00:19:03 +0000
Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3C0J2cX002826 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2016 00:19:03 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 11 Apr 2016 20:19:01 -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; Mon, 11 Apr 2016 20:19:01 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Eric C Rosen <erosen@juniper.net>
Thread-Topic: [sfc] [mpls] The first nibble issue associated with MPLS encapsulation
Thread-Index: AQHRkPR7Ow6l9wh8WUKpFJXl+MwAqJ+AqQ4A///PiXuAAHRmgP//0LOAgAA52ICABAmLAIAAGlYAgACnj4A=
Date: Tue, 12 Apr 2016 00:19:01 +0000
Message-ID: <CFAC7D65-1AF0-4185-B580-2D1BB6728823@cisco.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <B664DB14-0A8C-4437-83E3-F9DA6C0DDA61@cisco.com> <mc51yrrf9n0wxbjsrprt9amf.1460143890063@email.android.com> <CA+RyBmXpZ-Kt77TW-=_kPYmahdw_yUHB5xhy8YtYVq2OcRJxbA@mail.gmail.com> <D32DB725.3F57B%cpignata@cisco.com> <CA+RyBmW+qonpScnLOfsGorayCvsS0vrFcn+o5nPvOqCOv9Jc3g@mail.gmail.com> <AM3PR03MB0775C55E5AD3247F373007139D940@AM3PR03MB0775.eurprd03.prod.outlook.com> <570BB266.8090608@juniper.net>
In-Reply-To: <570BB266.8090608@juniper.net>
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.24.101.176]
Content-Type: multipart/signed; boundary="Apple-Mail=_0CE6BADB-12FF-46DB-920E-1F70601B7917"; protocol="application/pgp-signature"; micalg=pgp-sha256
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/PPXZbkcb6QYbalnFVfX4bIO23wc>
Cc: "bier@ietf.org" <bier@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "Dr. Tony Przygienda" <tonysietf@gmail.com>
Subject: Re: [mpls] [sfc] 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: Tue, 12 Apr 2016 00:19:09 -0000

> On Apr 11, 2016, at 10:19 AM, Eric C Rosen <erosen@juniper.net> wrote:
> 
> (Removed sfc from the cc-list, this seems out of scope for that WG.)
> 
> In designing the BIER header, the BIER WG is free to mandate any value it chooses in the first nibble.  These values do not come from a "first nibble" registry.
> 

I absolutely agree with this, in particular the comment about a registry.

However...

> It seems prudent to put a value like 5 for the following reasons:

… the value (significance, merit) of such value (magnitude, number) seems, as described below, minimally incremental.

> 
> - If a BIER packet is being parsed by an off-line tool, this is a good hint (though just a hint) that the packet is actually a BIER packet;
> 

The format of a BIER packet have enough constrained or self-defining fields, that an off-line parsing tool like Wireshark can apply enough heuristics to figure it out, without the 0x5.

> - If a BIER packet is traveling through an MPLS tunnel, and it traverses a node that does its MPLS load splitting by guessing at the type of the payload, then this is  a good hint that the MPLS payload is not IPv4, IPv6, or PW.
> 

I understand why a mid-point LSR might want to not alias the MPLS payload with IPv4 or IPv6, to prevent mis-hashing in the LB. Why would a node be interested in knowing the payload is not a PW? What would it do differently? [It is interesting that the hint is, as described, to nudge a node that the packet is *not* something, instead of the packet *is* BIER.]

> This strategy does incur a risk.  Suppose IPv5 gets designed, implemented, and deployed, and folks start to deploy hardware that does MPLS load balancing by inspecting the IPv5 headers of the MPLS payloads.  If a BIER packet is traversing an MPLS tunnel, inappropriate load splitting may occur if the hardware thinks the payload is IPv5 rather than BIER.
> 
> This particular risk doesn't seem very significant to me.
> 

I agree that risk is quite insignificant (null in practice). The real risk I believe is if some other application over MPLS uses 0x5 in the first nibble, because they do not want to be confused with IP either, and they do not like 0x0 or 0x1.

> Thus I don't think there's anything here that needs fixing.
> 
> 

Frankly do not have strong opinions either way. I do believe, however, that the rational for using 0x5 as the first nibble is underspecified (or at least under-documented).

Thanks,

— Carlos.