I see that a healthy discussion has broken out around draft-gross-geneve-00 which I see has a slot in the agenda for the NVO3 WG meeting on Monday. Here are my thoughts.
I will be comparing Geneve to an encapsulation that is near and dear to my heart, VXLAN. When I do this, I see an encapsulation that is very similar to VXLAN (e.g. uses UDP, uses a 24-bit segment identifier at the same offset). I see three things that Geneve adds beyond what is available in draft-mahalingam-dutt-dcops-vxlan: 1) The ability to encapsulate any protocol with an Ethertype (not just Ethernet frames), by adding a Protocol Type field. This is certainly useful, and has already been covered in draft-quinn-vxlan-gpe as a backward compatible extension to VXLAN by using a P bit flag to signal its presence. The field is even at the same offset as draft-quinn-vxlan-gpe, but is missing the P bit for backwards compatibility. 2) The addition of an OAM bit to signal that the packet should be processed by the tunnel endpoint and not forwarded to a tenant. This also seems useful, and seems identical in usage to the (IMO, poorly named) "Router Alert" bit extension to VXLAN covered in (the currently expired) draft-singh-nvo3-vxlan-router-alert. 3) Last, but not least is the addition of a variable length options field, which the draft suggests is used to carry metadata along with the payload. As mentioned by some others, IMO, the encapsulation transport header is not the right place to define and carry metadata. Architecturally, metadata should be defined independent of transport so it can be carried inside of whatever transport is desired (e.g. VXLAN, NVGRE, MPLSoGRE, L2TPV3 etc). One example of an effort to do this is in the Network Service Header draft (draft-quinn-sfc-nsh) being discussed in the SFC WG. I am guessing that since the Geneve options field is optional, that the metadata it contains is not related to basic network connectivity, but more to providing higher level network services (aka Service Functions). The Network Service Header contains two separate parts, the service path (used to guide the packets through the service chain) and context (metadata). I can certainly see the context part of NSH being used to carry metadata even if the service chain is null (all services are fully distributed to the tunnel endpoints). In short, I don't see anything in Geneve that cannot be accomplished by using the backward compatible extensions to VXLAN proposed in draft-quinn-vxlan-gpe and draft-singh-nvo3-vxlan-router-alert, combined with the addition of NSH. When the current NVO3 WG charter was being written, there seemed to be consensus that we have no shortage of encapsulation options, but what was lacking was a standard control plane. The Geneve draft seems to turn that on its head by saying "There is a clear advantage in settling on a data format: most of the protocols are only superficially different and there is little advantage in duplicating effort. However, the same cannot be said of control planes, which are diverse in very fundamental ways. The case for standardization is also less clear given the wide variety in requirements, goals, and deployment scenarios.". I agree with the first part of this, so why define a completely new, non-backward compatible encapsulation? I disagree with the second part, since this is clearly the goal of the NVO3 WG. I see that there is an agenda slot to discuss the Geneve draft, but I'm not clear what the goals are of the authors within the IETF since the draft name does not target it to any particular WG, and it is currently marked as "Informational". I would suggest that the authors consider extending currently implemented encapsulations rather than starting from scratch, e.g. by moving a few bits around in the first word of the Geneve header, it could be made backward compatible with VXLAN. Thanks, Larry
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
