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

Loa Andersson <loa@pi.nu> Wed, 13 April 2016 12:16 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 9408412D948 for <mpls@ietfa.amsl.com>; Wed, 13 Apr 2016 05:16:08 -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 Ja62wJngeHoG for <mpls@ietfa.amsl.com>; Wed, 13 Apr 2016 05:16:07 -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 0241812D7D6 for <mpls@ietf.org>; Wed, 13 Apr 2016 05:16:07 -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 04713180158D; Wed, 13 Apr 2016 14:16:04 +0200 (CEST)
To: mpls@ietf.org, "tom p." <daedulus@btconnect.com>
References: <570BB266.8090608@juniper.net> <04c801d1957b$2be37ce0$4001a8c0@gateway.2wire.net>
From: Loa Andersson <loa@pi.nu>
Message-ID: <570E3879.309@pi.nu>
Date: Wed, 13 Apr 2016 20:15:53 +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: <04c801d1957b$2be37ce0$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/H8rblm0mKPIHjpj0tWNkuB7-mD8>
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 12:16:08 -0000

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
>