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

Stewart Bryant <stewart.bryant@gmail.com> Thu, 14 April 2016 18:06 UTC

Return-Path: <stewart.bryant@gmail.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 1C49512D72A; Thu, 14 Apr 2016 11:06:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ehOeEsKqcJ83; Thu, 14 Apr 2016 11:06:15 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20B912D6E0; Thu, 14 Apr 2016 11:06:14 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id n3so137906909wmn.0; Thu, 14 Apr 2016 11:06:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=SKG0GpXPAPu11jLNObBU5etFGDsX+PPW2XSw1FDt6P8=; b=DemucUhndEAVGm/Irvu32oUGuilXT+/+YABixtu4R4TCXtVcEppouQYoLVwDMdAIJe PDLj/slMPMussVblhB5qmTInenY3YnBRM5j8VpQdITcp6QSWOlGriseOVl69lCUiq0uv rCbhEkIUQspnOpkHnhUOerlJ1EHD4O/A2iu6lUBHHnN/9eUZTCbg+xEGd6T2d8p8FX9A 7JrFWVWkaq1//WAhABDnkjH1/Ti0aPRbLYhfW3YiPb23GF5Wo0RJ3EBQfJx2OX/svzWw uOsBn6NFPX5xbsuIy+/12qsYmPOO2dzAo+tbpAnPumUi7OQMSzfa8m/k3aXB7t9sBHHS 0GLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=SKG0GpXPAPu11jLNObBU5etFGDsX+PPW2XSw1FDt6P8=; b=lRxGXNnkfglI1Kmp5PCvNfJ7wPJwfrcE91mYZVLBD4CNqdVpc1q1xUOvz08vblXR5G HZRHzVt4Guy9bLwzojp8O6RjPqbvjffQd9Jq5A2hlham+mrF9mnRfnU30wwICM9CdB4X UBsMpLlFw2Hn4MWC441pMLlbqtGdC08tw88QCKRgZ6E8+2uFSLO/tXJFRO0qHMyG2wBh UERyT8x6NzZbrdCrhqtYa+Z6S9iqr0ANCCDj+oEPNK3tZaUQ9xbjKxTQmgNU25443bDt 2sg0UTP2k+DRWjr+r28Bk60Ydq/7eHvmP0aw/km9JsFoQGHU26TAOLsGESTdYgkm72AE QfRg==
X-Gm-Message-State: AOPr4FWDtZSwvQ2g5dvFdwqOGBat735lyzTmzTFNZKcLv2vFvYlk7dbpeowUjEHzWlUe8w==
X-Received: by 10.194.63.8 with SMTP id c8mr17867516wjs.89.1460657173497; Thu, 14 Apr 2016 11:06:13 -0700 (PDT)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id gt7sm45188321wjc.1.2016.04.14.11.06.12 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 11:06:12 -0700 (PDT)
To: Loa Andersson <loa@pi.nu>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.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> <570F79AB.9070107@pi.nu>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <570FDC12.6090505@gmail.com>
Date: Thu, 14 Apr 2016 19:06:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <570F79AB.9070107@pi.nu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/2mpDqYRDhKj4VCxjEd8gvKu9Y7Y>
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 18:06:17 -0000


On 14/04/2016 12:06, Loa Andersson wrote:
> 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-

0x1 is of course the OAM identifier, i.e. the GACH indicator, which BIER 
is also free to
use with appropriate channel type.

Stewart


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