So Larry, earlier in the month I asked the chairs if nvo3 was ready to talk and explore solutions. The answer was no.
Then why is GENEVE on the agenda chairs? Dino > On Feb 28, 2014, at 1:57 PM, "Larry Kreeger (kreeger)" <[email protected]> > wrote: > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
