Re: [mpls] draft-ietf-sfc-nsh "first nibble" issue

Gregory Mirsky <gregory.mirsky@ericsson.com> Wed, 27 April 2016 17:05 UTC

From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "pals@ietf.org" <pals@ietf.org>
Thread-Topic: draft-ietf-sfc-nsh "first nibble" issue
Thread-Index: AQHRoHv5jA1HvFPCM0yMnvW+PmvYjp+eC04w
Date: Wed, 27 Apr 2016 17:04:59 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF11221A60FA3@eusaamb103.ericsson.se>
References: <D3462168.4C3B2%jguichar@cisco.com>
In-Reply-To: <D3462168.4C3B2%jguichar@cisco.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A60FA3eusaamb103erics_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/1FlwH-YPhwktVCovg9tzbpBzpZ8>
Subject: Re: [mpls] draft-ietf-sfc-nsh "first nibble" issue
Precedence: list

Hi Jim,
as this issue is related to MPLS and MPLS PWs shall we extend the audience and invite MPLS and PALS WGs to the discussion?
Personally, I prefer solution that avoids not only 0x04 and 0x06 in the first nibble but 0x00 and 0x01 as well by using Non-of-the-Above value, e.g. 0x05 as in BIER over MPLS encapsulation<https://tools.ietf.org/html/draft-ietf-bier-mpls-encapsulation-04>.

                Regards,
                                Greg

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, April 27, 2016 4:58 AM
To: sfc@ietf.org
Subject: [sfc] draft-ietf-sfc-nsh "first nibble" issue

Dear WG:

The infamous "MPLS first nibble" issue was raised as part of the WGLC for draft-ietf-sfc-nsh-04. While this issue has been known for some time, and work has been done by the community to try and mitigate (for example RFC4928) or remove it (for example RFC6790), given the widespread implementation of existing hardware that uses the first nibble for ECMP decision processing, it seems prudent for us as a WG to address it in terms of how it affects our SFC protocol and make it clear within the draft the conclusion of the WG.

While it is true that we could rearrange our encapsulation header such that it avoids this issue (by simply making the first nibble correspond to a value that is neither 0x4 or 0x6), given multiple industry and open source implementations of the SFC encapsulation header, that is not a desired outcome, especially as multiple other transport encapsulations do not exhibit this behavior when coupled with the SFC encapsulation.

If we consider the current definition of the SFC encapsulation base header, we can see that the first two bits are used as a version field. This means that if we ever produce a version 01 for NSH it could result in a value of 0x4 or 0x6 being present within the first nibble. To avoid such a result the simplest solution would be to reserve within the SFC encapsulation specification version 01 and make it clear within the text that this is reserved and should not be used in future versions of the protocol. If we ever change the version, which incidentally should be a rare thing, we would therefore jump from version=00 to version=02 (i.e. making version 1 'reserved') thereby avoiding any clash in the first nibble.

IMHO this seems like a reasonable approach to the problem but I would like to hear opinions from the WG as to whether this is an acceptable solution and if we can reach consensus, ask the editors of draft-ietf-sfc-nsh to add text to reflect it.

Jim

Re: [mpls] draft-ietf-sfc-nsh "first nibble" issue Gregory Mirsky