Subject: [sfc] 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: "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 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: 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: 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.