[mpls] The first nibble issue associated with MPLS encapsulation

[Xuxiaohu <[e-mail]>]

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 [[e-mail]] 代表 Tony Przygienda [[e-mail]]
发送时间: 2016年4月5日 22:36
收件人: [e-mail]
主题: [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