Tom, Regarding point 2, IMHO, SFC header should be treated as a metadata when it applies to NVO3 because the SFC header essential is to carry some states from ingress NVE to egress NVE to facilitate NVE egress forwarding. But we should not invent an encapsulation to allow passing arbitrary metadata because it defeats the purpose of metadata: pass some dynamic changed states along with packet. Using metadata is an expensive costs, we should only use when it makes sense and have the market value.
SFC header itself may also contain a metadata that is used for service functions (TSs in NVO3), we should distinguish between two. Regards, Lucy From: nvo3 [mailto:[email protected]] On Behalf Of Thomas Nadeau Sent: Wednesday, March 12, 2014 5:07 PM To: Anton Ivanov (antivano) Cc: [email protected] Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap I agree. We should be discussing whether or not we need: 1) yet another encapsulation. 2) how/if/why metadata Incidentally point 2 is under discussion and part of the proposed architecture in NSC. --Tom On Mar 10, 2014:10:10 AM, at 10:10 AM, Anton Ivanov (antivano) <[email protected]<mailto:[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]<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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
