On Fri, Feb 28, 2014 at 3: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. > > +1 I think the above comments are very positive on Geneve but they seem to have been taken negatively. Regards, Behcet > 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
