On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci <[email protected]> wrote: >> On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino) <[email protected]> wrote: >>> >>> On 7/26/16 12:08 PM, Dino Farinacci wrote: >>>>> Having VXLAN as an Independent Stream RFC gives a document to be used to >>>>> innovate from. I believe that was the intent of VXLAN-GPE - to provide >>>>> the ability >>>>> for needed extensions. >>>> The only new feature the VXLAN-GPE brings to the table is a way to >>>> identify that NSH is being encapsulated. >>> >>> or any other shim header, NSH just happens to be one. >> >> Precisely. GPE addresses the limitation associated with VXLAN, namely the >> lack of multi-protocol support. As we've seen on the list, other protocols >> have come up: MPLS for example. > > This is technically not true. As long as you are willing to spend 14 bytes on > a MAC header, then anything with an ethertype can be encapsulated with VXLAN. > > And I have working code that encapsulates both IPv4 and IPv6 in VXLAN with > ethertypes 0x0800 and 0x86dd, respectively. > >> There are some other technical benefits as well: version and OAM. > As do Geneve and GUE. But this thread is not about touting the features of these protocols, it is about the technical objections to them. My major objections (from the list I posted) to VXLAN-GPE is that it has no extensibility and offers no security of the VNI. These are showstoppers in my deployment.
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
