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

Loa Andersson <loa@pi.nu> Wed, 13 April 2016 13:00 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 9787412DF40 for <mpls@ietfa.amsl.com>; Wed, 13 Apr 2016 06:00:59 -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 I5cVMlJ1EACp for <mpls@ietfa.amsl.com>; Wed, 13 Apr 2016 06:00:55 -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 8080612DD7A for <mpls@ietf.org>; Wed, 13 Apr 2016 06:00:55 -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 4B14C1802B3F; Wed, 13 Apr 2016 15:00:53 +0200 (CEST)
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "mpls@ietf.org" <mpls@ietf.org>, "tom p." <daedulus@btconnect.com>
References: <570BB266.8090608@juniper.net> <04c801d1957b$2be37ce0$4001a8c0@gateway.2wire.net> <570E3879.309@pi.nu> <d3948774bx4hysw36letkn43.1460550906394@email.android.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <570E42FB.4020801@pi.nu>
Date: Wed, 13 Apr 2016 21:00:43 +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: <d3948774bx4hysw36letkn43.1460550906394@email.android.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/wypwPga37Hm3W9FgBcIp_Vchu-E>
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: Wed, 13 Apr 2016 13:00:59 -0000

Sasha,

I think that you are both right and wrong, there is no "Early IANA
De-allocation" processūüėČ.

However, since we are not requesting a new value from any register,
I think we are fine using right away.

A packet in an mpls tunnel with the first nibble gives two pieces of
information

- it may be a bier packet
- it is not IPv4 or IPv6, thus a node the do mpls load sharing not do
   that if the first nibble is 4 or 6

The first is just a hint, the second is a reality, but nothing of this
comes from an IANA registry for first nibble.

/Loa

On 2016-04-13 20:35, Alexander Vainshtein wrote:
> I concur with Loa - with a qualifier:
> AFAIK there is no such thing as an "Early IANA De-allocation" processūüėČ.
> So we may still have to wait some time until these values become formally available for reuse.
>
> My 2c.
>
> Thumb typed on my cellphone
> Regards,
> Sasha
>
> -------- Original Message --------
> From: Loa Andersson <loa@pi.nu>
> Date: Wed, April 13, 2016 3:16 PM +0300
> To: mpls@ietf.org, "tom p." <daedulus@btconnect.com>
> Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation
>
>
> Tom,
>
>
> On 2016-04-13 19:53, t.petch wrote:
>> ----- Original Message -----
>> From: "Eric C Rosen" <erosen@juniper.net>
>> Sent: Monday, April 11, 2016 3:19 PM
>>
>>
>>> (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
>>
>> Too late;  see
>>
>>
>> https://tools.ietf.org/html/draft-boucadair-ip-version-5-8-9-historic-00
>
> Isn't this just in time - if IPv5 is made historic - we can safely use
> it.
>
> /Loa
>>
>> Discussion on the int-area list.
>>
>> Tom Petch
>>
>>
>>
>>> 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
>