Hi All, GROSS brings a lot of attentions in this IETF meeting. VXLAN and NVGRE defects for Network Virtualization Overlay (NVO) technology were extensively discussed on nvo3 mailing list last year (http://www.ietf.org/mail-archive/web/nvo3/current/msg02779.html) and the enhancements on VXLAN and NVGRE for the technology were also proposed in the draft-yong-l3vpn-nvgre-vxlan-encap-03 and draft-ietf-tsvwg-gre-in-udp-00.
If we look at the geneve proposal, it addresses the defects identified in VXLAN and NVGRE for NVO and has the essential key elements required by NVO in the encapsulation header. Should we enhance VXLAN and NVGRE for NVO technology or create a new encapsulation protocol for NVO? Industry (or major vendors (authors in gross) in NVO) seems prefer the latter choice now. The benefit of the latter is that having one encapsulation protocol for the NVO technology, which is good for both vendors and operators. The "cons" is that we have a new encapsulation protocol, which is not compliant with either VXLAN or NVGRE. So the question is should we quickly face out VXLAN and NVGRE with GENEVE and have one encap. for NVO or we live with this pain ( enhance both VXLAN and NVGRE for NVO and use both in NVO). IMHO: Having two encapsulation semantics for the same technology is not good, the only reason we do it is for the reality. Is this reality not true anymore by seeing the authors in geneve? What should IETF do for NVO technology development? With current NVO3 WG progress pace, it is not much except discussing the technology and solution pieces on the mailing list. In the meanwhile, IETF keeps receiving these informational drafts from the industry (precisely, the nvo leader vendors). Which one will IETF publish as informational? Does IETF really want working on NVO technology? Regarding medadata option in geneve header, I'll express my opinion in a separated mail. Thanks, Lucy
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
