1. Introduction
1. Introduction
Network virtualization is a useful technique for creating agile, multi-tenant environments on top of a shared physical infrastructure. By decoupling the simulation of the network topology from the physical hardware, simple and flexible control planes can be built giving the view of a dedicated network to adjacent higher-level applications. This often involves the use of a tunneling protocol to encapsulate the virtualized traffic as it flows across the physical infrastructure. While the requirements of the control plane and the environment are evolving, the tunneling and encapsulation protocol is a mechanism implemented in hardware and/or software and can be more difficult to change. This document describes Geneve (Generic Network Virtualization Encapsulation), a protocol that seeks to avoid the problems of rigid standard definitions by providing a flexible and extensible framework for current and future networking use cases.
The tunneling protocol defines the data plane format of the traffic in transit. To the extent that this format is fixed, it becomes the "narrow waist" of the system, constraining the pace of innovation (similar to the way that IPv4 options are difficult to evolve). The goal of Geneve is to define an encapsulation data format that is as flexible and extensible as possible in order to allow the control plane to evolve and support new use cases without requiring permanent changes to the data format.
Current virtualization encapsulations can be classified into those that are stateless (e.g., VXLAN [RFC7348] and NVGRE [RFC7637]) and those that include state (e.g., STT [STT]). Stateful protocols provide significant flexibility and performance, but the state must be synchronized between the endpoints, which adds complexity. Stateless protocols are simpler to implement and debug but are limited in the amount of information that can be carried in the packet. Geneve is a stateless protocol that attempts to provide the flexibility of a stateful protocol with the simplicity of a stateless one.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.