> -----邮件原件----- > 发件人: Zhou, Han [mailto:[email protected]] > 发送时间: 2014年3月19日 10:26 > 收件人: Xuxiaohu; [email protected] > 抄送: [email protected] > 主题: RE: Comments to draft-quinn-vxlan-gpe-02 > > > 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? 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 > > Best regards, > > > > Xiaohu > > > > --- > > > > Best regards, > > > > Han > > > > > > > > > > Best regards, > Han > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
