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

From: Xuxiaohu <[email-masked]>
Date: Thu, 7 Apr 2016 17:39:49 +0000

As for the first nibble issue, will it violate the layering principle of network protocol stacks if the first nibble of any new encapsulation header (which could be an MPLS payload) is used as the "MPLS payload type" field? wouldn't it  be more reasonable and sustainable to fix the problem (i.e., the lack of a protocol field in the MPLS header) by the MPLS header itself?

By the way, since it's claimed that the NSH is transport-independant, it means the NSH should be able to be transported over MPLS. However, it seems that the first nibble issue has not be considered in the current NSH draft. As a result, when encapsulating NSH over MPLS, the NSH may be mis-interpreted as IP header.

Best regards,

Xiaohu

________________________________
发件人: BIER [[email-masked]] 代表 Tony Przygienda [[email-masked]]
发送时间: 2016年4月5日 22:36
收件人: [email-masked]
主题: [Bier] comments on draft-wang-bier-ethernet-01

after reading

a) first nibble: refer to MPLS encaps as "the same value" to keep in sync
b) refer to all other possible fields to MPLS encaps to keep in sync when describing instead of repeating
c) you need to describe which kind of ether MACs are allowed, especially on broadcast media, i.e. is it always p2p or can you take advantage of the broadcast ?
d) Figure 4: use the architecture/MPLS encoding for the length, don't invent a new one
e) who will obtain a new ether type from IEEE? As far I understand, not a trivial process albeit we have several liaisons with IEEE

--
We’ve heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.
―Robert Wilensky

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 8 Apr 2016 18:24:58 +0000

Xiaohu, Tony,

Please see inline.

> On Apr 7, 2016, at 2:39 PM, Xuxiaohu <[email-masked]> wrote:
> 
> As for the first nibble issue, will it violate the layering principle of network protocol stacks if the first nibble of any new encapsulation header (which could be an MPLS payload) is used as the "MPLS payload type" field?

Reading draft-wang-bier-ethernet-01, Section 3, the “first nibble” is _not_ used as an “MPLS payload type”. Instead, the text describes an anti-aliasing mechanism, much like RFC 4928.

The relevant text is:
     First nibble: The first 4 bits of the header are set to 0101; this
   ensures that the BIER header will not be confused with an IP header
   or with the header of a pseudowire packet.

Which says “… will not be confused with …"

> wouldn't it  be more reasonable and sustainable to fix the problem (i.e., the lack of a protocol field in the MPLS header) by the MPLS header itself?
> 

Who says it is a *problem*? There’s no “fixing” needed.

> By the way, since it's claimed that the NSH is transport-independant, it means the NSH should be able to be transported over MPLS. However, it seems that the first nibble issue has not be considere…

There seems to be some massive confusion on this paragraph, on a number of levels. First, NSH is not “claimed to be” transport-independent. It is by charter and by design. Second, the NSH draft does not even include the term “MPLS”, because it does not define transports. The SFC Encapsulation can be used in a transport-agnostic way.

One more comment below.

> Best regards,
> Xiaohu
> 
> 发件人: BIER [[email-masked] <mailto:[email-masked]>] 代表 Tony Przygienda [[email-masked] <mailto:[email-masked]>]
> 发送时间: 2016年4月5日 22:36
> 收件人: [email-masked] <mailto:[email-masked]>

One comment regarding the “First nibble” text at draft-ietf-bier-mpls-encapsulation-03

Since the function of the first nibble is to prevent aliasing with an IP packet, in order for RFC 4928 to specify values of 0x0 and 0x1 for the First Nibble, it had to “Reserve” IP protocol versions of 0 and 1, referencing that RFC (see https://tools.ietf.org/html/rfc4928#section-5).

Is the intent to re-assign IPv5 at http://www.iana.org/assignments/version-numbers/ <http://www.iana.org/assignments/version-numbers/> ?

Note that RFC 4928 says “REQUIRED” at:

   It is REQUIRED, however, that applications depend upon in-order
   packet delivery restrict the first nibble values to 0x0 and 0x1.

Thanks,

— Carlos.

> _______________________________________________
> mpls mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 8 Apr 2016 19:31:30 +0000

Carlos and all,
Just for the reference, IANA has defined version 5 (0101) has assigned to ST protocol and refers to RFC 1119. The latter has been obsoleted by RFC 1819, but the IANA
assignment still holds.

Is there, just in case, any relationship between BIER and ST?
Thumb typed on my cellphone
Regards,
Sasha

-------- Original Message --------
From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, April 08, 2016 9:25 PM +0300
To: Xiaohu Xu <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], "Dr. Tony Przygienda" <[email-masked]>
Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulation

Xiaohu, Tony,

Please see inline.

On Apr 7, 2016, at 2:39 PM, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:

Reading draft-wang-bier-ethernet-01, Section 3, the "first nibble" is _not_ used as an "MPLS payload type". Instead, the text describes an anti-aliasing mechanism, much like RFC 4928.

The relevant text is:

Which says "... will not be confused with ..."

Who says it is a *problem*? There's no "fixing" needed.

There seems to be some massive confusion on this paragraph, on a number of levels. First, NSH is not "claimed to be" transport-independent. It is by charter and by design. Second, the NSH draft does not even include the term "MPLS", because it does not define transports. The SFC Encapsulation can be used in a transport-agnostic way.

One more comment below.

Best regards,
Xiaohu

________________________________
???: BIER [[email-masked]<mailto:[email-masked]>] ?? Tony Przygienda [[email-masked]<mailto:[email-masked]>]
????: 2016?4?5? 22:36
???: [email-masked]<mailto:[email-masked]>
??: [Bier] comments on draft-wang-bier-ethernet-01

after reading

One comment regarding the "First nibble" text at draft-ietf-bier-mpls-encapsulation-03

Since the function of the first nibble is to prevent aliasing with an IP packet, in order for RFC 4928 to specify values of 0x0 and 0x1 for the First Nibble, it had to "Reserve" IP protocol versions of 0 and 1, referencing that RFC (see https://tools.ietf.org/html/rfc4928#section-5).

Is the intent to re-assign IPv5 at http://www.iana.org/assignments/version-numbers/ ?

Note that RFC 4928 says "REQUIRED" at:

Thanks,

- Carlos.

--
We've heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.
?Robert Wilensky
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 8 Apr 2016 15:28:07 -0700

Hi Sasha,
thank you for pointing to existing IANA allocation, though stale. I wonder
if there is the registry for the first nibble. We, Tony and I, had
discussed the way the first nibble space managed. If there already is the
registry, could you please point me to it.
Regards, Greg
On Apr 8, 2016 2:31 PM, "Alexander Vainshtein" <
[email-masked]> wrote:

> As for the first nibble issue, will it violate the layering principle of
> network protocol stacks if the first nibble of any new encapsulation header
> (which could be an MPLS payload) is used as the "MPLS payload type" field?
>
>
> Reading draft-wang-bier-ethernet-01, Section 3, the “first nibble” is
> _not_ used as an “MPLS payload type”. Instead, the text describes an
> anti-aliasing mechanism, much like RFC 4928.
>
> The relevant text is:
> wouldn't it  be more reasonable and sustainable to fix the problem (i.e.,
> the lack of a protocol field in the MPLS header) by the MPLS header itself?
>
>
>
>
> By the way, since it's claimed that the NSH is transport-independant, it
> means the NSH should be able to be transported over MPLS. However, it seems
> that the first nibble issue has not be considered in the current NSH draft.
> As a result, when encapsulating NSH over MPLS, the NSH may be
> mis-interpreted as IP header.
>
>
>
>
> There seems to be some massive confusion on this paragraph, on a number of
> levels. First, NSH is not “claimed to be” transport-independent. It is by
> charter and by design. Second, the NSH draft does not even include the term
> “MPLS”, because it does not define transports. The SFC Encapsulation can be
> used in a transport-agnostic way.
>
> One more comment below.
>
> Best regards,
> Xiaohu
>
>
> ------------------------------
> *发件人:* BIER [[email-masked]] 代表 Tony Przygienda [
> [email-masked]]
> *发送时间:* 2016年4月5日 22:36
> *收件人:* [email-masked]
> *主题:* [Bier] comments on draft-wang-bier-ethernet-01
>
> after reading
>
> Since the function of the first nibble is to prevent aliasing with an IP
> packet, in order for RFC 4928 to specify values of 0x0 and 0x1 for the
> First Nibble, it had to “Reserve” IP protocol versions of 0 and 1,
> referencing that RFC (see https://tools.ietf.org/html/rfc4928#section-5).
>
> Is the intent to re-assign IPv5 at
> http://www.iana.org/assignments/version-numbers/ ?
>
> c) you need to describe which kind of ether MACs are allowed, especially
> on broadcast media, i.e. is it always p2p or can you take advantage of the
> broadcast ?
> e) who will obtain a new ether type from IEEE? As far I understand, not a
> trivial process albeit we have several liaisons with IEEE
>
> --
> *We’ve heard that a million monkeys at a million keyboards could produce
> the complete works of Shakespeare; now, thanks to the Internet, we know
> that is not true.*
> ―Robert Wilensky
> [email-masked]
> [email-masked]

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 8 Apr 2016 22:38:52 +0000

Greg,

My point, sorry if I was not clear, was that there is no such a thing as a ‘first nibble registry’.

Instead, RFC 4928, Section 5, at https://tools.ietf.org/html/rfc4928#section-5, says:

   IANA has marked the value 0x1 in the IP protocol version number space
   as "Reserved" and placed a reference to this document to both values
   0x0 and 0x1.

And that is reflected as http://www.iana.org/assignments/version-numbers/version-numbers.xhtml#version-numbers-1

The IANA text in 4928 is additionally followed by a disclaimer:

   Note that this document does not in any way change the policies
   regarding the allocation of version numbers, including the possible
   use of the reserved numbers for some future purpose.

Further, RFC 4385 does not specify the ‘first nibble’ as a field. Instead, it depicts the actual binary values for the different CW formats. In other words, it takes the values from the IP protocol version number and not as a new CW Field.

Thanks,

― Carlos.

PS: Sasha, quick typo, s/1119/1190/;

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 8, 2016 at 7:28 PM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Dr. Tony Przygienda" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Xiaohu Xu <[email-masked]<mailto:[email-masked]>>, Carlos Pignataro <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulation

Hi Sasha,
thank you for pointing to existing IANA allocation, though stale. I wonder if there is the registry for the first nibble. We, Tony and I, had discussed the way the first nibble space managed. If there already is the registry, could you please point me to it.
Regards, Greg

On Apr 8, 2016 2:31 PM, "Alexander Vainshtein" <[email-masked]<mailto:[email-masked]>> wrote:

Carlos and all,

-------- Original Message --------
From: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>
Date: Fri, April 08, 2016 9:25 PM +0300
To: Xiaohu Xu <[email-masked]<mailto:[email-masked]>>
CC: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, "Dr. Tony Przygienda" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulation

Xiaohu, Tony,

Please see inline.

The relevant text is:

One more comment below.

Best regards,
Xiaohu

________________________________
发件人: BIER [[email-masked]<mailto:[email-masked]>] 代表 Tony Przygienda [[email-masked]<mailto:[email-masked]>]
发送时间: 2016年4月5日 22:36
收件人: [email-masked]<mailto:[email-masked]>
主题: [Bier] comments on draft-wang-bier-ethernet-01

after reading

Thanks,

― Carlos.

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 8 Apr 2016 16:05:51 -0700

Hi Carlos,
thank you for the clarification. Should we think about establishing the
registry than?
Regards, Greg
On Apr 8, 2016 5:38 PM, "Carlos Pignataro (cpignata)" <[email-masked]>
wrote:

> Instead, RFC 4928, Section 5, at
> https://tools.ietf.org/html/rfc4928#section-5, says:
>
> And that is reflected as
> http://www.iana.org/assignments/version-numbers/version-numbers.xhtml#version-numbers-1
>
>
> Further, RFC 4385 does not specify the ‘first nibble’ as a field. Instead,
> it depicts the actual binary values for the different CW formats. In other
> words, it takes the values from the IP protocol version number and not as a
> new CW Field.
>
> Thanks,
>
> — Carlos.
>
> From: Greg Mirsky <[email-masked]>
> To: Alexander Vainshtein <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Dr.
> Tony Przygienda" <[email-masked]>, "[email-masked]" <[email-masked]>,
> Xiaohu Xu <[email-masked]>, Carlos Pignataro <[email-masked]>
>> There seems to be some massive confusion on this paragraph, on a number
>> of levels. First, NSH is not “claimed to be” transport-independent. It is
>> by charter and by design. Second, the NSH draft does not even include the
>> term “MPLS”, because it does not define transports. The SFC Encapsulation
>> can be used in a transport-agnostic way.
>>
>> One more comment below.
>>
>> Best regards,
>> Xiaohu
>>
>>
>> —Robert Wilensky

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 8 Apr 2016 21:42:54 -0700

Carlos, thanks, enlightening input. That leads kind of back towards BIER
with the question whether we are comfortable with it being  ECMP'ed by DPI
by mistake or whether we actually consider it desirable that it is ECMP'ed.
BIER has its own ECMP section and is otherwise basically a hop-by-hop
technology but the question still hold in case we have IP ECMP between two
nodes (now, whether that's of practical relevance today or will be of
relevance I leave over to the list to discuss). Then there is of course the
consideration what happens if BIER is carried over tunnels, amongst them
MPLS.

Overall, looks like the only safe choice if we do NOT want it to be ECMP'ed
unintentionally is to follow 4925 sec. 5, otherwise to pick up something
that is not 4/6 to prevent firewall DPI and other tricks.

--- tony

On Fri, Apr 8, 2016 at 4:05 PM, Greg Mirsky <[email-masked]> wrote:

>> Further, RFC 4385 does not specify the ‘first nibble’ as a field.
>> Instead, it depicts the actual binary values for the different CW formats.
>> In other words, it takes the values from the IP protocol version number and
>> not as a new CW Field.
>>
>> Thanks,
>>
>> — Carlos.
>>
>> thank you for pointing to existing IANA allocation, though stale. I
>> wonder if there is the registry for the first nibble. We, Tony and I, had
>>> wouldn't it  be more reasonable and sustainable to fix the problem
>>> (i.e., the lack of a protocol field in the MPLS header) by the MPLS header
>>> itself?
>>>
>>>
>>>
>>>
>>> e) who will obtain a new ether type from IEEE? As far I understand, not
>>> a trivial process albeit we have several liaisons with IEEE
>>>
>>> --

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 11 Apr 2016 12:45:02 +0000

Greg, and all,
From my experience (from the days long past☺), the IETF has been always treating the first nibble just after the bottom of the label stack as being managed via the IP Version Numbers registry<http://www.iana.org/assignments/version-numbers/version-numbers.xhtml> – and this because, as per RFC 3032<https://tools.ietf.org/html/rfc3032>, “the network  layer packet immediately follows the label stack entry which has the  S bit set”.

RFC 4385<https://datatracker.ietf.org/doc/rfc4385/?include_text=1> has reused the values that have been defined as “Reserved” in this registry.
But, AFAIK, attempts to reuse some stale values (e.g., PIP<https://tools.ietf.org/html/rfc1621>) have been rejected out-of-hand.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: Greg Mirsky [mailto:[email-masked]]
Sent: Saturday, April 09, 2016 2:06 AM
To: Carlos Pignataro (cpignata)
Cc: [email-masked]; Alexander Vainshtein; [email-masked]; Dr. Tony Przygienda; Xiaohu Xu; [email-masked]
Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulation

Hi Carlos,
thank you for the clarification. Should we think about establishing the registry than?
Regards, Greg
On Apr 8, 2016 5:38 PM, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

Thanks,

— Carlos.

Hi Sasha,

Carlos and all,

assignment still holds.

Regards,

Sasha

-------- Original Message --------

Xiaohu, Tony,

Please see inline.

The relevant text is:

One more comment below.

Best regards,
Xiaohu

Thanks,

— Carlos.

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 11 Apr 2016 10:19:18 -0400

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 12 Apr 2016 00:19:01 +0000

> On Apr 11, 2016, at 10:19 AM, Eric C Rosen <[email-masked]> wrote:
> 
> 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.
> 

I absolutely agree with this, in particular the comment about a registry.

However...

> It seems prudent to put a value like 5 for the following reasons:

… the value (significance, merit) of such value (magnitude, number) seems, as described below, minimally incremental.

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

The format of a BIER packet have enough constrained or self-defining fields, that an off-line parsing tool like Wireshark can apply enough heuristics to figure it out, without the 0x5.

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

I understand why a mid-point LSR might want to not alias the MPLS payload with IPv4 or IPv6, to prevent mis-hashing in the LB. Why would a node be interested in knowing the payload is not a PW? What would it do differently? [It is interesting that the hint is, as described, to nudge a node that the packet is *not* something, instead of the packet *is* BIER.]

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

I agree that risk is quite insignificant (null in practice). The real risk I believe is if some other application over MPLS uses 0x5 in the first nibble, because they do not want to be confused with IP either, and they do not like 0x0 or 0x1.

> Thus I don't think there's anything here that needs fixing.

Frankly do not have strong opinions either way. I do believe, however, that the rational for using 0x5 as the first nibble is underspecified (or at least under-documented).

Thanks,

— Carlos.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 13 Apr 2016 01:30:26 +0000

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Saturday, April 09, 2016 2:25 AM
To: Xuxiaohu
Cc: Dr. Tony Przygienda; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulation

Xiaohu, Tony,

Please see inline.

The relevant text is:

[Xiaohu] The following text is quoted from the NSH draft:

“  6.  Transport Agnostic: NSH is transport independent and is carried

       in an overlay, over existing underlays.  If an existing overlay

       topology provides the required service path connectivity, that

       existing overlay may be used.”

Best regards,

Xiaohu

”

One more comment below.

Best regards,
Xiaohu

Thanks,

— Carlos.

---

From: t.petch <[email-masked]>
Date: Wed, 13 Apr 2016 12:53:06 +0100

----- Original Message -----
From: "Eric C Rosen" <[email-masked]>
Sent: Monday, April 11, 2016 3:19 PM

> 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

Discussion on the int-area list.

Tom Petch

---

From: Loa Andersson <[email-masked]>
Date: Wed, 13 Apr 2016 20:15:53 +0800

Tom,

> 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

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 13 Apr 2016 12:35:11 +0000

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.

-------- Original Message --------
From: Loa Andersson <[email-masked]>
Date: Wed, April 13, 2016 3:16 PM +0300
To: [email-masked], "tom p." <[email-masked]>
Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation

Tom,

/Loa

---

From: Loa Andersson <[email-masked]>
Date: Wed, 13 Apr 2016 21:00:43 +0800

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

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 13 Apr 2016 10:47:54 -0400

On 4/11/2016 8:19 PM, Carlos Pignataro (cpignata) wrote:
> The format of a BIER packet have enough constrained or self-defining 
> fields, that an off-line parsing tool like Wireshark can apply enough 
> heuristics to figure it out, without the 0x5. 

I haven't worked out for myself whether this is the case or not, but it 
certainly doesn't hurt to have the 0x05 there.

> I understand why a mid-point LSR might want to not alias the MPLS 
> payload with IPv4 or IPv6, to prevent mis-hashing in the LB. Why would 
> a node be interested in knowing the payload is not a PW? What would it 
> do differently? 

I'm not sure if there is any hardware that performs PW-specific 
functions in the forwarding plane, based on the first nibble, but it 
seems prudent to avoid any possibility of confusion.

> [It is interesting that the hint is, as described, to nudge a node 
> that the packet is *not* something, instead of the packet *is* BIER.] 

Well, of course, that's why the nibble is not a protocol type field ;-)  
In the MPLS encaps, the fact that the packet is BIER is determined from 
the MPLS label.  In other proposed encapsulations, the encapsulating 
protocol would have a protocol type field.

> I agree that risk is quite insignificant (null in practice). The real risk I believe is if some other application over MPLS uses 0x5 in the first nibble, because they do not want to be confused wit…

That is possible, but I don't really see what the problem is.

I guess it is true that we'll have to say that BIER is not 100% 
compliant with RFC 4928.   I don't see that as a problem either, but it 
is certainly possible that some AD will make an issue of it.

---

From: t.petch <[email-masked]>
Date: Wed, 13 Apr 2016 17:00:10 +0100

----- Original Message -----
From: "Loa Andersson" <[email-masked]>
To: <[email-masked]>; "tom p." <[email-masked]>
Sent: Wednesday, April 13, 2016 1:15 PM

> Isn't this just in time - if IPv5 is made historic - we can safely use

I think not

'   A specification that has been superseded by a more recent
   specification or is for any other reason considered to be obsolete is
   assigned to the "Historic" level.  '

It doesn't mean it is not in use although that I-D does say

'Given that IPv6 is a deployment reality and there are no proven
   deployments of the aforementioned IP versions ...'

My point was that IPv5 exists, as of now, and still will, even when made
Historic.

The I-D says

' IANA is requested to deallocate the version numbers'

which I think wrong. If you are feeling paranoid - sometimes I do - then
you will think that somewhere the value 5 is given a significance and it
would be safer not to free it up for re-use.

Tom Petch

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 14 Apr 2016 03:07:06 +0000

> -----Original Message-----
> From: Eric C Rosen [mailto:[email-masked]]
> Sent: Wednesday, April 13, 2016 10:48 PM
> Cc: Alexander Vainshtein; Greg Mirsky; [email-masked]; [email-masked]; Xuxiaohu;
> Dr. Tony Przygienda
> Subject: Re: [bier] [mpls] The first nibble issue associated with MPLS
> encapsulation
> 
> 
> I haven't worked out for myself whether this is the case or not, but it certainly
> doesn't hurt to have the 0x05 there.
> 
> I'm not sure if there is any hardware that performs PW-specific functions in the
> forwarding plane, based on the first nibble, but it seems prudent to avoid any
> possibility of confusion.
> 
> Well, of course, that's why the nibble is not a protocol type field ;-) In the MPLS

If we pick different values for the first nibble of different MPLS payloads, the first nibble actually plays the role of a protocol type field. In fact, there is an attempt to have a registry for the first nibble (a.k.a., MPLS payload type field).

Best regards,
Xiaohu

> encaps, the fact that the packet is BIER is determined from the MPLS label.  In
> other proposed encapsulations, the encapsulating protocol would have a
> protocol type field.
> 
> >> 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.
> >>
> > I agree that risk is quite insignificant (null in practice). The real risk I believe is if
> some other application over MPLS uses 0x5 in the first nibble, because they do
> not want to be confused with IP either, and they do not like 0x0 or 0x1.
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 14 Apr 2016 10:31:32 +0100

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:
> it chooses in the first nibble.  These values do not come from a 
> "first nibble" registry.
>
> - 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.
>
> 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.
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 14 Apr 2016 10:06:12 +0000

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

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Thursday, April 14, 2016 12:32 PM
To: Eric C Rosen; Alexander Vainshtein; Greg Mirsky
Cc: [email-masked]; [email-masked]; 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

---

From: Loa Andersson <[email-masked]>
Date: Thu, 14 Apr 2016 19:06:19 +0800

Sasha and Stewart,

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

If that is what we want for bier, there is a case to use 0x0 or 0x1 for
bier-

/Loa

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 14 Apr 2016 12:59:08 +0000

> On Apr 13, 2016, at 11:07 PM, Xuxiaohu <[email-masked]> wrote:
> 
> If we pick different values for the first nibble of different MPLS payloads, the first nibble actually plays the role of a protocol type field.

No. Really no.

> In fact, there is an attempt to have a registry for the first nibble (a.k.a., MPLS payload type field).
> 

Let’s not.

Thanks,

— Carlos.

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 14 Apr 2016 09:20:01 -0400

> At the same time, it seems that all the bits in CW structure are used - at least for some PW types in some cases.

It seems to me that Sasha's reasoning supports the conclusion that it is 
best to avoid 0 in the first nibble (even if this is not the conclusion 
he drew!)  I don't think sub-typing is a solution, because it doesn't 
offer any protection against the behavior of existing hardware.

> and any wish to take another value really needs to be discussed

Are you referring to the IP Version Number registry?  (I am not aware of 
an "IP types registry".)   We're not asking for any modification to 
that, since we're not doing another version of IP. I don't see any need 
to get into  one of those long and non-productive arguments that the INT 
area seems to relish.

> In fact, there is an attempt to have a registry for the first nibble (a.k.a., MPLS payload type field).

Hopefully that attempt won't succeed!

> If that is what we want for bier, there is a case to use 0x0 or 0x1 for

Strictly speaking, RFC 4928 needs to be updated, as the reasoning given 
there does not really support the above "requirement".  But the effort 
to do that hardly seems worthwhile.  RFC 4928 already makes clear that 
the above requirement is protecting against the risk that IPv5 ECMP will 
affect some MPLS packets inappropriately. No one seems to think that 
that is a real risk.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 14 Apr 2016 13:27:55 +0000

Eric,
I suspect (will have to check) that the packet processor I've mentioned actually would not differentiate between 0 and 5 in the first nibble.
They tend to consider anything with neither 4 or 6 in the first nibble as Ethernet PWs.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: Eric C Rosen [mailto:[email-masked]] 
Sent: Thursday, April 14, 2016 4:20 PM
To: Alexander Vainshtein; Stewart Bryant
Cc: [email-masked]; [email-masked]; Dr. Tony Przygienda; Greg Mirsky
Subject: Re: [mpls] [bier] The first nibble issue associated with MPLS encapsulation

> At the same time, it seems that all the bits in CW structure are used - at least for some PW types in some cases.

It seems to me that Sasha's reasoning supports the conclusion that it is best to avoid 0 in the first nibble (even if this is not the conclusion he drew!)  I don't think sub-typing is a solution, because it doesn't offer any protection against the behavior of existing hardware.

On 4/14/2016 5:31 AM, Stewart Bryant wrote:
> 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.

Are you referring to the IP Version Number registry?  (I am not aware of 
an "IP types registry".)   We're not asking for any modification to 
that, since we're not doing another version of IP. I don't see any need to get into  one of those long and non-productive arguments that the INT area seems to relish.

> If that is what we want for bier, there is a case to use 0x0 or 0x1 

Strictly speaking, RFC 4928 needs to be updated, as the reasoning given there does not really support the above "requirement".  But the effort to do that hardly seems worthwhile.  RFC 4928 already makes clear that the above requirement is protecting against the risk that IPv5 ECMP will affect some MPLS packets inappropriately. No one seems to think that that is a real risk.

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Thu, 14 Apr 2016 14:41:43 +0000

Hi,

Per IANA registry, 0-1 are ³Reserved² and so is not strictly assigned with
PW. Something like a modified CW beneath LSE?. Further, BIER is hop-by-hop
lookup based. So I think we don¹t need to include this always. Instead, we
could conditionally include this, if the next BFR is tunneled (not
directly connected).

The receiving node will use the label to identify the payload/FEC. So I
think, the presence of modified CW should not confuse it with PW.

Thanks,
Nagendra

On 4/14/16, 9:20 AM, "mpls on behalf of Eric C Rosen"
<[email-masked] on behalf of [email-masked]> wrote:

>> 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.
>>
>> At the same time, it seems that all the bits in CW structure are used -
>>at least for some PW types in some cases.
>

---

From: Loa Andersson <[email-masked]>
Date: Thu, 14 Apr 2016 23:11:47 +0800

Nagendra,

The IANA registry you refer to is the IP Version numbers
http://www.iana.org/assignments/version-numbers/version-numbers.xhtml#version-numbers-1

Please note that this registry does not globally define what needs to
be in the first nibble of a packet carried over mpls, it the payload
is IP you are correct.

If the payload is e.g. a PW then 0x0 in the first nibble of the payload
indicates that it is PW the first nibble refer to to the PWMCW 
(Pseudowire MPLS Control Word), if the first nibble is 0x1 it tells
you that this packet belongs to GACh.

/Loa

On 2016-04-14 22:41, Nagendra Kumar Nainar (naikumar) wrote:
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 14 Apr 2016 19:06:10 +0100

> If that is what we want for bier, there is a case to use 0x0 or 0x1 for

0x1 is of course the OAM identifier, i.e. the GACH indicator, which BIER 
is also free to
use with appropriate channel type.

Stewart

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

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 14 Apr 2016 20:31:43 +0100

>> indication of an Ethernet PW.

Well there will be Ethernet PWs not using the CW that can put any 
Ethernet address in the first nibble, so
if there are Ethernet addresses that start with 5 they will look like 
BIER packets.

> It seems to me that Sasha's reasoning supports the conclusion that it 
> is best to avoid 0 in the first nibble (even if this is not the 
> conclusion he drew!)  I don't think sub-typing is a solution, because 
> it doesn't offer any protection against the behavior of existing 
> hardware.

There is no truly safe position until we mandate that all deployed PWs 
use the CW, but that is not going to happen for a while.

> Are you referring to the IP Version Number registry?  (I am not aware 
> of an "IP types registry".)   We're not asking for any modification to 
> that, since we're not doing another version of IP. I don't see any 
> need to get into  one of those long and non-productive arguments that 
> the INT area seems to relish.
>
Sorry I meant version number.

Before we assign a member of this very small number range to BIER, I 
would like some confidence that it will see any significant deployment. 
When PW took 0 and 1, it was already a widely deployed protocol.

Stewart

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 14 Apr 2016 20:35:07 +0100

On 14/04/2016 15:41, Nagendra Kumar Nainar (naikumar) wrote:
> PW.
True, but PW caused then to be reserved so as to prevent future clashes.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 14 Apr 2016 20:36:22 +0100

>> think, the presence of modified CW should not confuse it with PW.

Not quite Loa.

It could be an Ethernet PW with no CW.

Stewart

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 14 Apr 2016 19:48:10 +0000

Hi Stewart, et. al,
just wanted to clarify, though that likely was stated on the thread already, that the problem of the first nibble is only on transient, i.e. P, nodes that are not aware of the context of the BoS label. And with the fact that there are old and very old P nodes out there in the network there might be no absolutely safe solution to the First Nibble issue/concern. Though we can recommend safer policies to handle ECMP on P nodes, e.g. use EL.

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Thursday, April 14, 2016 12:32 PM
To: Eric C Rosen; Alexander Vainshtein
Cc: [email-masked]; [email-masked]; Dr. Tony Przygienda
Subject: Re: [mpls] [bier] The first nibble issue associated with MPLS encapsulation

>> indication of an Ethernet PW.

Well there will be Ethernet PWs not using the CW that can put any Ethernet address in the first nibble, so if there are Ethernet addresses that start with 5 they will look like BIER packets.

> it doesn't offer any protection against the behavior of existing 

There is no truly safe position until we mandate that all deployed PWs use the CW, but that is not going to happen for a while.

Before we assign a member of this very small number range to BIER, I would like some confidence that it will see any significant deployment. 
When PW took 0 and 1, it was already a widely deployed protocol.

Stewart

- Stewart

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 14 Apr 2016 17:43:00 -0400

> if there are Ethernet addresses that start with 5 they will look like 

What problem will that cause?

> Before we assign a member of this very small number range to BIER,

The first nibble of the BIER header does not have to have a value taken 
from the IP version number registry.

> I would like some confidence that it will see any significant 
> deployment. When PW took 0 and 1, it was already a widely deployed 
> protocol. 

Note though that when PW started using 0 and 1 in the first nibble, it 
was not already a widely deployed protocol.  I'd say it was a mistake to 
reserve 0 and 1 in the IP version number registry, as those reservations 
have no practical impact, and just cause a lot of unproductive 
discussions to take place.

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 14 Apr 2016 23:50:32 +0000

Hi Loa, et. al,
assuming that deployed nodes understand some, at least 0x04 and 0x06, values of the first nibble, wouldn't it be sufficient to define one new value as None-of-the-Above? Though we're still exposed to Ethernet PW without CW case.

	Regards,
		Greg

-----Original Message-----
From: BIER [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, April 14, 2016 8:12 AM
To: Nagendra Kumar Nainar (naikumar); Eric C Rosen; Alexander Vainshtein; Stewart Bryant
Cc: [email-masked]; [email-masked]
Subject: Re: [Bier] [mpls] [bier] The first nibble issue associated with MPLS encapsulation

Nagendra,

Please note that this registry does not globally define what needs to be in the first nibble of a packet carried over mpls, it the payload is IP you are correct.

If the payload is e.g. a PW then 0x0 in the first nibble of the payload indicates that it is PW the first nibble refer to to the PWMCW (Pseudowire MPLS Control Word), if the first nibble is 0x1 it tells you that this packet belongs to GACh.

/Loa

On 2016-04-14 22:41, Nagendra Kumar Nainar (naikumar) wrote:
> Hi,
>
> Per IANA registry, 0-1 are ³Reserved² and so is not strictly assigned 
> with PW. Something like a modified CW beneath LSE?. Further, BIER is 
> hop-by-hop lookup based. So I think we don¹t need to include this 
> always. Instead, we could conditionally include this, if the next BFR 
> is tunneled (not directly connected).
>
> The receiving node will use the label to identify the payload/FEC. So 
> I think, the presence of modified CW should not confuse it with PW.
>
> Thanks,
> Nagendra
>
>
>>> At the same time, it seems that all the bits in CW structure are 
>>> used - at least for some PW types in some cases.
>>
>> it doesn't offer any protection against the behavior of existing hardware.
>>
>> Strictly speaking, RFC 4928 needs to be updated, as the reasoning 
>> given there does not really support the above "requirement".  But the 
>> effort to do that hardly seems worthwhile.  RFC 4928 already makes 
>> clear that the above requirement is protecting against the risk that 
>> IPv5 ECMP will affect some MPLS packets inappropriately. No one seems 
>> to think that that is a real risk.
>>
>>
>>

---

From: Loa Andersson <[email-masked]>
Date: Fri, 15 Apr 2016 10:36:01 +0800

Greg,

> assuming that deployed nodes understand some, at least 0x04 and 0x06, values of the first nibble, wouldn't it be sufficient to define one new value as None-of-the-Above? Though we're still exposed…
The "none-of-the-above" approach might be sufficient, though I
struggling to understand if we gain anything extra putting a specific
number there.

/Loa

---

From: Loa Andersson <[email-masked]>
Date: Fri, 15 Apr 2016 10:53:34 +0800

Stewart,

On 2016-04-15 03:36, Stewart Bryant wrote:
>>> with

Yes - you are right, how much of a problem is this in a P node? Any 
value, except 4 and 6, will stop the P node from doing ECMP/Load
Sharing, right? A P node will never look for the control word.

So an Ethernet PW that carries the same value in the first nibble that
we specify for bier will be treated the same way as a bier packet.
This does not effect the bier packets, and is the right way to treat
the PW.

So where do we have the problem?

BIER would be in the clear, as it will carry any value but 4 or 6
in the first nibble, right?
PWs with control word will have 0 (or 1) and not be effected by a
P node that are doing ECMP/Load Sharing.
Ethernet PWs without control word might have any value in the first
nibble, if there is 4 or 6 a P node might to ECMP/Load Sharing.

It seems to me that specifying the first nibble in a bier packet
would be good, for the time being I don't care if we say 0 or 5.

If there are problems with Ethernet PWs without control word, this
has to be solved in the context of PWs.

/Loa

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 15 Apr 2016 03:55:43 +0000

Hi Loa,
I think that use of value 5 in the first nibble for MPLS encapsulated BIER packets is to differentiate them from all other variants that use the first nibble as the hint to P node on what use as flow characteristic information for ECMP. I don't think, though we should consult with BIER WG and authors of draft-ietf-bier-mpls-encapsulation, that the first nibble not supposed to be used as payload type identifier but only to differentiate from other types of the first nibble at P nodes to avoid incidental hashing of BIER packets assumed to be something else, IP or Ethernet. If that is the case, then the same value 5 may be used as None-of-the-Above indicator, including SFC.

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, April 14, 2016 7:54 PM
To: Stewart Bryant; Nagendra Kumar Nainar (naikumar); Eric C Rosen; Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] [Bier] [bier] The first nibble issue associated with MPLS encapsulation

Stewart,

On 2016-04-15 03:36, Stewart Bryant wrote:
>>> Per IANA registry, 0-1 are ³Reserved² and so is not strictly 
>>> assigned with PW. Something like a modified CW beneath LSE?. 
>>> Further, BIER is hop-by-hop lookup based. So I think we don¹t need 
>>> to include this always.
>>> Instead, we
>>> The receiving node will use the label to identify the payload/FEC. 
>>> So I think, the presence of modified CW should not confuse it with PW.
>
> Not quite Loa.
>

Yes - you are right, how much of a problem is this in a P node? Any value, except 4 and 6, will stop the P node from doing ECMP/Load Sharing, right? A P node will never look for the control word.

So an Ethernet PW that carries the same value in the first nibble that we specify for bier will be treated the same way as a bier packet.
This does not effect the bier packets, and is the right way to treat the PW.

BIER would be in the clear, as it will carry any value but 4 or 6 in the first nibble, right?
PWs with control word will have 0 (or 1) and not be effected by a P node that are doing ECMP/Load Sharing.
Ethernet PWs without control word might have any value in the first nibble, if there is 4 or 6 a P node might to ECMP/Load Sharing.

It seems to me that specifying the first nibble in a bier packet would be good, for the time being I don't care if we say 0 or 5.

If there are problems with Ethernet PWs without control word, this has to be solved in the context of PWs.

/Loa

---

From: Loa Andersson <[email-masked]>
Date: Fri, 15 Apr 2016 15:09:50 +0800

Greg,

I think the position of the mpls wg should be that LSRs (P node) may do
load sharing if the the first nibble is 4 or 6, otherwise not.

Other wg may decide on which of the "none of the above"-values to use in
the cases they specify. When specifying such values it should be clear
that the first nibble is not a general payload indicator, it is an
indicator whether load sharing (if available) may be wanted or not.

For some PW application the first nibble have a meaning slightly
different from this, as far as I can see this is OK and deployed.
It also means that other wg may want to distinguish the payload that
wg specifies from PWs, but in doing so they should not assume that
the value they chose is a indicator that is 100% sure to identify that
payload.

/Loa