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

Stewart and all,
I concur with Stewart that there is a strong case for 0 in the first nibble for all non-IP flows.

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