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

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