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

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Saturday, April 09, 2016 2:25 AM
To: Xuxiaohu
Cc: Dr. Tony Przygienda; bier@ietf.org; mpls@ietf.org; sfc@ietf.org
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 <xuxiaohu@huawei.com<mailto:xuxiaohu@huawei.com>> 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 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.

[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

________________________________
发件人: BIER [bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>] 代表 Tony Przygienda [tonysietf@gmail.com<mailto:tonysietf@gmail.com>]
发送时间: 2016年4月5日 22:36
收件人: bier@ietf.org<mailto:bier@ietf.org>
主题: [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

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:

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

Thanks,

— Carlos.

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
_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls