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

Stewart Bryant <> Thu, 14 April 2016 09:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4175C12D61D; Thu, 14 Apr 2016 02:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HIbYPwLJAxUH; Thu, 14 Apr 2016 02:31:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61ECA12D619; Thu, 14 Apr 2016 02:31:36 -0700 (PDT)
Received: by with SMTP id n3so116970482wmn.0; Thu, 14 Apr 2016 02:31:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=hbEnJweM1pN89JA5RGjVa2ZI3SOTNwr6BeNHZl+FBeY=; b=GBw288Bi4Y+ESyqv67XjcOBL7jftJRPbtnpx4QRe4iat+WnwzzP3MeQbC1oOtFPKae Op75nqFDKdN+GYxlD81x3Lsaq3V9nK02/52CdD6qEcM5bDSlppxj+scvscZKWzgnL7pU Pn6tjKgAb+WKDroWbtLqaiL4SvvPux2KMEknpwGerkb4mE2hOTKjsKTNgERw1Rl9o2MF FNj8FuGNk+iREF1/Q44RLkOKx35LHyF0WwoV1/yO+mpcQV1VybXaSld41WWmovWK7HGQ VY1tVfiIIUIIVEJ6SVZTEXQGObu/gSBjHuVDNjp53IM5lB+/tXyOYVSXFbT33BUuWGF+ FVXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=hbEnJweM1pN89JA5RGjVa2ZI3SOTNwr6BeNHZl+FBeY=; b=HmqnGZXsZBaarKeBiXEeq8bX+8ASzALIcNzAUd+B3iZygFZdrHqkHZ+WoM9t5sCsqx LOCSxY6HlSJhtL94x/50VyiX0YyZesUDlOPg7y2NgMqJuWtfv5tJA/7ijcqy+0PFLJUT 6MtUOBiRSkCsViRy5pOMrVZ6u7POH/USkxD6X6WyLf9Tbt/+sBuf4O5DpEvJqEMHTBb1 TcdAYRZ4SWX0Sdsg41URDBG7tXACm6n8JqRjd1+OLiCdBnRPn71VkTJDI24UFNoUC8Qw sWYTukDSiCS5U8UnjpRxRETppM9CmVs3kE2BtyRPwcfrQM1n5vtSmTyEv23prke0FL9e 4vMA==
X-Gm-Message-State: AD7BkJK+l+CGu4Q4radaCUJXYsGww6M/9SWpCygMF2gGsQVbjy+hjPxjwBdQafcLyhyftw==
X-Received: by with SMTP id y127mr34982077wmy.4.1460626294935; Thu, 14 Apr 2016 02:31:34 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id a73sm5581617wme.2.2016. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 02:31:33 -0700 (PDT)
To: Eric C Rosen <>, Alexander Vainshtein <>, Greg Mirsky <>
References: <> <> <> <> <> <> <> <>
From: Stewart Bryant <>
Message-ID: <>
Date: Thu, 14 Apr 2016 10:31:32 +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: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>, "" <>, "Dr. Tony Przygienda" <>
Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Apr 2016 09:31:38 -0000

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

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