Before one analyses various encapsulations out there, newly proposed or existing ones, there should be a reference or set of requirements to compare with. I do not see those *new* requirements in the draft-ietf-nvo3-dataplane-requirements-02. It would be prudent for the authors of the documents for ‘new’ encap, to identify them in a new ID or propose those to the existing requirements draft. Till then it is speculation at best.
-sam On Mar 10, 2014, at 10:10 AM, Anton Ivanov (antivano) <[email protected]> wrote: > 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. > > In order to "face off" GRE, VXLAN, Geneve (and L2TPv3 for that matter) you > need to set the field. > > 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] >> 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] >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
