Hi Xiaohu,

Please see inlined.

On Wed, 2014-03-19 at 01:27 +0000, Xuxiaohu wrote:
>  
> 
>  
> 
> 发件人: nvo3 [mailto:[email protected]]代表 Zhou, Han
> 发送时间: 2014年3月18日 11:49
> 收件人: [email protected]
> 抄送: [email protected]
> 主题: [nvo3] Comments to draft-quinn-vxlan-gpe-02
> 
> 
>  
> 
> Dear VXLAN-gpe Authors,
> 
>  
> 
> VXLAN-gpe is a great extension to VXLAN, providing L3 encapsulation
> 
> directly. However, considering the precious space in VXLAN header, it
> 
> might be better if you could consider shrinking the size of protocol
> 
> type field. For my understanding there is only several ethertype
> values
> 
> really required, such as IPv4/v6. Could you help rule out the
> 
> possibilities and then shrink the field size to e.g. 8 bits or less? 8
> bits
> 
> should be far beyond enough for this protocol type field even
> 
> considering future extensions. But it would be so helpful for other
> 
> extension possibilities to VXLAN. For example discussed in:
> 
>  
> 
> http://www.ietf.org/mail-archive/web/nvo3/current/msg03388.html
> 
>  
> 
> [Xiaohu] If you need more space in the encapsulation header, you could
> exactly use a reserved bit to indicate the present of an optional
> field, just like the usage of GRE Checksum Present bit. Therefore, it
> seems no need for shrinking the protocol type field.
> 
>  

Fix-sized header would always be the best option, which is also an
advantage (may be the only advantage) of VXLAN over other new
feature-rich NVO3 protocols. It would be better if we could avoid
wasting header space without good reason.

> 
> And it is likely that there will be more extension coming to VXLAN, if
> 
> it is going to survive in the fast pace of innovation on network
> 
> overlay.
> 
>  
> 
> IMHO, even 0x6558, which is mentioned in section 4.2, is not required,
> 
> because VXLAN VTEP will ignore the P bit and the protocol type anyway,
> 
> so why not setting P bit to 0 in this situation?
> 
>  
> 
> [Xiaohu] Thanks for pointing this out. It seems that the solution that
> you desired has been described in
> http://tools.ietf.org/html/draft-yong-l3vpn-nvgre-vxlan-encap-03
> 
>  
Yes, this draft stated the same as in VXLAN-gpe to use 0x6558 for
ethernet and at the same time use 0x0000 for backward compatibility. So
why not always using 0x0000 for ethernet?

So are there only 3 values possible (0, IP, IPv6, which indicates 2
bits are enough instead of 16 bits)?

> Best regards,
> 
> Xiaohu
> 
> ---
> 
> Best regards,
> 
> Han
> 
>  
> 
> 

Best regards,
Han


_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to