From: nvo3 [mailto:[email protected]] On Behalf Of Anton Ivanov (antivano) Sent: Monday, March 10, 2014 12:10 PM To: [email protected] Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap
On 10/03/14 17:04, Lucy yong wrote: Sorry, "Gross" in my previous mail means draft-gross-geneve-00. The metadata is what is described in this draft. That is a "ready-baked" solution. It is not requirements. [Lucy] Agree. The draft itself is the solution draft. The requirements for NVO were discussed in nvo3 mail list extensively. Nvo3 data plane requirement doc. is the place to capture the requirements. In order to "face off" GRE, VXLAN, Geneve (and L2TPv3 for that matter) you need to set the field. [Lucy] Sorry, it should be "phase off". This is not what I mean. I mean to say, "phase off VXLAN and NVGRE for NVO", not GRE. Lucy If you do not set the field by having requirements you can claim anyone being the winner - it stops being an engineering standards process. A. From: nvo3 [mailto:[email protected]] On Behalf Of Anton Ivanov (antivano) Sent: Monday, March 10, 2014 11:46 AM To: [email protected]<mailto:[email protected]> Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap Requirements draft? For metadata? Document id please? A. On 10/03/14 16:32, Lucy yong wrote: 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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
