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

Loa Andersson <loa@pi.nu> Thu, 14 April 2016 11:06 UTC

Return-Path: <loa@pi.nu>
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 6405A12DC71; Thu, 14 Apr 2016 04:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 C4yGloXSh3kG; Thu, 14 Apr 2016 04:06:33 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC6012DBEF; Thu, 14 Apr 2016 04:06:32 -0700 (PDT)
Received: from [192.168.1.2] (unknown [122.53.41.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 214B81802C2F; Thu, 14 Apr 2016 13:06:29 +0200 (CEST)
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, Stewart Bryant <stewart.bryant@gmail.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> <570F6374.6030406@gmail.com> <DB3PR03MB0780B7CE7B96283FB484C2489D970@DB3PR03MB0780.eurprd03.prod.outlook.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <570F79AB.9070107@pi.nu>
Date: Thu, 14 Apr 2016 19:06:19 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <DB3PR03MB0780B7CE7B96283FB484C2489D970@DB3PR03MB0780.eurprd03.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/Xrk3hj7M4lCbUtGC0tLwKbZk3Gw>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "bier@ietf.org" <bier@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: Thu, 14 Apr 2016 11:06:35 -0000

Sasha and Stewart,


On 2016-04-14 18:06, Alexander Vainshtein wrote:
> Stewart and all,
> I concur with Stewart that there is a strong case for 0 in the first nibble for all non-IP flows.

While I can live with 0x0000, 0x0010 or 0x0101, RFC 4928 actually says:

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

If that is what we want for bier, there is a case to use 0x0 or 0x1 for
bier-

/Loa
>
> As for the need for sub-typing:
> AFAIK quite a few implementations (including some HW-based packet processors) treat 0 in the first nibble after the label stack as an indication of an Ethernet PW.
>
> Some of them go as far as to hash on the assumed L2 headers for ECMP. This causes serious problems, e.g., with the TDM PWs that could be reordered if handled by such packet processors in transit LSRs.
>
> This makes quite a case for sub-typing IMO regardless of BIER.
> At the same time, it seems that all the bits in CW structure are used - at least for some PW types in some cases.
>
> Regards,
> Sasha
>
> Office: +972-39266302
> Cell:      +972-549266302
> Email:   Alexander.Vainshtein@ecitele.com
>
> -----Original Message-----
> From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
> Sent: Thursday, April 14, 2016 12:32 PM
> To: Eric C Rosen; Alexander Vainshtein; Greg Mirsky
> Cc: mpls@ietf.org; bier@ietf.org; Dr. Tony Przygienda
> Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation
>
> I am not sure zero is PW so much as "type undefined - don't ECMP".
> That was certainly the definition that we were talking about at the time.
>
> The nibble value  is recorded in the IP types registry and any wish to take another value really needs to be discussed with the INT area.
>
> Also the code space is so small that we really need to be super conservative in its allocation. Given it's true purpose, I suggest that we only have the unused deprecated values of 0 (taken), 1 (taken), 2, 3 and possibly 5 available for use (for ever).
> Seven and up really should be kept available to the IP protocol itself.
>
> Five of course was deployed. It was used for some form of streaming protocol, but it is probably safe to assume that it is no longer in the wild.
>
> Whilst Eric makes a case for 5, I think there is also a strong case for zero.
>
> If there is a need for subtyping zero for wireshark etc, we could take a look at what the use is made of the second nibble in PWs and see if there is a set of values never in practise used and thus available for subtyping.
>
> - Stewart
>
>
> On 11/04/2016 15:19, Eric C Rosen 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.
>>
>> It seems prudent to put a value like 5 for the following reasons:
>>
>> - 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;
>>
>> - 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.
>>
>> 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.
>>
>> Thus I don't think there's anything here that needs fixing.
>>
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>