Hi Matthew, See my responses inline below.
Thanks, Larry On 7/21/16, 7:56 AM, "nvo3 on behalf of Bocci, Matthew (Nokia - GB)" <nvo3-boun...@ietf.org on behalf of matthew.bo...@nokia.com> wrote: >WG > >There was a discussion in the NVO3 WG meeting in Berlin following strong >advice from our Area Director that we need to come to a consensus on >converging on a common encapsulation. Two sets of questions were asked: >(1) Should the WG move forward with one standards track encap? >(2) For a given encap, do you have significant technical objections? > >This email relates to the second of these questions. Please refer to the >separate email titled ³Consensus call on moving forward with single >encap² for discussion related to point (1). I am sorry I missed the meeting. Was the room polled for the option to move forward with more than one encap? I am interested in knowing the response to that question since on the list, that option appeared to have much more traction. If the room was not polled for that option or for a choice between the options discussed on the list, then we have incomplete/misleading results for how to move forward. > >We would recommend that those not familiar with RFC 7282 "On Consensus >and Humming in the IETF" may wish to read it for a fuller understanding >of how the IETF handles challenging consensus decisions and why. > >We would like to determine the consensus on the following points on the >list (there is a separate thread concerning point (2)): > >1) Does anyone have a significant technical objection to selecting Geneve >as the single NVO3 Standards track document? Please be as concrete and >detailed as possible as to your technical objection. Yes, I would strongly object to this being the only option. There are applications where both encap/decap and deep packet inspection of NVO3 encapsulated packets requires extremely low latency and low jitter. The variable nature of the Geneve header makes meeting these requirements extremely challenging and/or costly (in terms of the number of gates needed) to implement in hardware. Additionally, Geneve does not have any backward compatibility mechanisms for VXLAN support. Arguably, VXLAN is the most widely implemented and deployed NVO3 protocol in data centers today, so this is an important consideration. > >2) Does anyone have a significant technical objection to selecting >VXLAN-GPE as the single NVO3 Standards track document? Please be as >concrete and detailed as possible as to your technical objection. > >3)Does anyone have a significant technical objection to selecting GUE as >the single NVO3 Standards track document? Please be as concrete and >detailed as possible as to your technical objection. My major objection to GUE being the only option is the lack of backward compatibility with VXLAN (see above). I am also concerned about how much actual industry implementation GUE has in both software and hardware. > > >Please reply to this email thread on the NVO3 list by 29th July 2016. > >Please DO NOT use this thread to argue or debate the importance or >details of any technical objections that arise. That can be done in >other threads. This thread should be used to state your initial >objection. Any objections raised will be summarized in an additional >email at the end of this consensus call so that the WG can discuss the >results in detail. > >While the list of technical issues has been collected for each >encapsulation, the chairs are discussing how to develop an acceptable >solution. The goal is to have an answer before IETF 97. The chairs >will follow up to the list shortly. > >Regards > >Matthew and Sam > > _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
