February 9, 2020

311 words 2 mins read

Lightning Talk: The Sunset of VXLAN

Lightning Talk: The Sunset of VXLAN

VXLAN has been around for a decade, there are substantial numbers of deployments, and everything seems to be perfect. What might be wrong? It appears that many thi …

Talk Title Lightning Talk: The Sunset of VXLAN
Speakers Ignas Bagdonas, Equinix
Conference NANOG74
Conf Tag
Location Vancouver, BC, Canada
Date Oct 1 2018 - Oct 3 2018
URL Talk Page
Slides Talk Slides
Video Talk Video

VXLAN has been around for a decade, there are substantial numbers of deployments, and everything seems to be perfect. What might be wrong? It appears that many things are wrong with VXLAN, and it is not that easy to fit that. VXLAN was a successful accident – back at the time when it was designed (by a single vendor for a single product family), the intended use cases were narrow in scope and contained within a tight boundary, and it was a conscious engineering tradeoff. The rest is a history now – VXLAN got successfully used and abused for things not even envisioned at the time, and the limitations are now evident. Three large and well known problem areas are present in VXLAN as an encapsulator:

  1. No protocol identifier. VXLAN tunnel can carry single payload type only.
  2. No indicator for non-client payload. This rules out majority of OAM mechanisms.
  3. No extensibility. All fields in VXLAN header have defined values and no interoperable extensibility is possible. IETF has addressed the problem space by designing a successor to VXLAN – Geneve. It provides mechanisms for practical extensibility, security aspects, better integration with OAM toolkits, and is starting to see traction in the industry. VXLAN has served well for a long, and time has come for it to be replaced. The main goal of this lightning talk is to bring in awareness of fundamental limitations present in VXLAN, and provide information on alternative solutions available in the industry.
comments powered by Disqus