On Jul 21, 2016 4:56 PM, "Bocci, Matthew (Nokia - GB)" < [email protected]> 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). > > 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. > - TLVs are expensive to process in both HW and SW. They also create a potential DOS vector. - Four byte overhead per TLV is significant. - 16 bit protocol number is overkill. It is unlikely that Geneve will ever carry more than 20 protocols. This is a significant portion of primary header and lookup on 16 bit value is expensive often done with hash instead of simple indexed array (which is suitable for an 8 bit field). - Similar to above, 16 bit TLV option type is an expensive lookup. - The draft allows the length of a (non-critical) TLV to be determined either by length field or canonical length of type. This allows the possibility of having two completely different interpretations of the same protocol fields, where both can claim conformance. - There is no security mechanism defined within the protocol to provide integrity or authenticity of the VNI. - When encapsulating Ethernet four byte alignment of the inner header is not preserved. This is an issue on certain host CPU architectures such as Sparc. - The draft does not mention congestion control considerations. - The draft allows a host to send a zero UDP6 checksum, but does not demonstrate how requirements in section 4 of RFC6936 are met.
> 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. > - VXLAN-GPE does not appear compatible with VXLAN-GPE. If a VXLAN host receives a VXLAN packet for some protocol other than Ethern the payload will be misinterpreted. A separate port number was required. I assume that a user using VXLAN in HW must upgrade HW to use VXLAN-GPE - VXLAN-GPE has very little extensibility. - There is no allowance in VXLAN-GPE for custom extensions to the protocol. - There are no guidelines as to how reserved bits or fields are intended to be used or allocated (please see thread on my question about RCO in VXLAN-GPE). - There is no security mechanism within the protocol for integrity or authenticity of the VNI. The security considerations section otherwise defers security to the encapsulated protocol, there is no consideration for security of the VXLAN header itself. - VXLAN-GPE allows a receiver to ignore a non-zero UDP checksum. This violates RFC1122 . - The draft makes no mention of congestion control considerations. - The draft recommends using a zero UDP checksum with IPv6 without reference or consideration of RFC6935 or RFC6936. - Ethernet encapsulation has the same alignment issue as Geneve. > 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. > > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
