Subject: [nvo3] Comments to draft-quinn-vxlan-gpe-02

From: "Zhou, Han" <[email-masked]>
Date: Tue, 18 Mar 2014 03:48:50 +0000

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

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?

---
Best regards,
Han

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 19 Mar 2014 01:27:51 +0000

发件人: nvo3 [mailto:[email-masked]] 代表 Zhou, Han
发送时间: 2014年3月18日 11:49
收件人: [email-masked]
抄送: [email-masked]
主题: [nvo3] Comments to draft-quinn-vxlan-gpe-02

Dear VXLAN-gpe Authors,

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

[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

Best regards,
Xiaohu
---
Best regards,
Han

---

From: "Zhou, Han" <[email-masked]>
Date: Wed, 19 Mar 2014 02:26:01 +0000

Hi Xiaohu,

Please see inlined.

On Wed, 2014-03-19 at 01:27 +0000, Xuxiaohu wrote:
>  
> 
>  
> 
> 发件人: nvo3 [mailto:[email-masked]]代表 Zhou, Han
> 发送时间: 2014年3月18日 11:49
> [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.

> [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,
Han

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 19 Mar 2014 03:15:36 +0000

> -----邮件原件-----
> 发件人: Zhou, Han [mailto:[email-masked]]
> 发送时间: 2014年3月19日 10:26
> 收件人: Xuxiaohu; [email-masked]
> 抄送: [email-masked]
> 主题: RE: Comments to draft-quinn-vxlan-gpe-02
> 
> 
> Hi Xiaohu,
> 
> Please see inlined.
> 
> 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.

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

Using 0x6558 is to be in accordance with the EtherType. Using 0x0000 is to be backwards compatible with the existing VXLAN.

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

Keeping the length of the protocol type field in the VXLAN header the same as that of the EtherType could avoid code allocation work for any new protocol type. For example, the IEEE EtherType, 0x894F, which has just been allocated for NSH could be directly used by VXLAN to indicate the presence of the NSH.

Best regards,
Xiaohu