NVO3 Requirements Versus Available Protocol Capabilities

The charter of the NVO3 Working Group requires it to identify any gaps between the requirements it has identified and the available protocol solutions as a prerequisite to rechartering or concluding the Working Group if no gaps exist. The present document is intended to provide the required analysis. It provides a tabulation of the candidate protocols' ability to satisfy each requirement identified by the Working Group. Areas where further work is required to ensure that the requirements are met are identified. Since the Working Group has yet to adopt documents describing requirements for the management and control planes, they are absent from the present version of this document. The data plane requirements are taken from . The initial candidate protocols are NVGRE , VxLAN , L2VPN [reference?], and L3VPN [reference?].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

This document uses the following abbreviations: Network virtualization overlays Layer 2 virtual private network Layer 3 virtual private network Network virtualization edge Virtual access point Virtual network instance Link aggregation group Equal cost multi-path Differentiated services code point Explicit congestion notification

In this section, the numbering of requirement headings is taken from the corresponding section numbers in . 3.1. Virtual Access Points (VAPs) Requirement NVGRE VxLAN L2VPN L3VPN MUST support VAP identification - - - - - 1) Local interface YES - - - - - 2) Local interface + fields in frame header YES 3.2. Virtual Network Instance (VNI) Requirement NVGRE VxLAN L2VPN L3VPN VAP are associated with a specific VNI at service instantiation time. YES 3.2.1. L2 VNI Requirement NVGRE VxLAN L2VPN L3VPN L2 VNI MUST provide an emulated Ethernet multipoint service as if Tenant Systems are interconnected by a bridge (but instead by using a set of NVO3 tunnels). NO - - - - - Loop avoidance capability MUST be provided. - - - - - In the absence of a management or control plane, data plane learning MUST be used to populate forwarding tables. - - - - - When flooding is required, either to deliver unknown unicast, or broadcast or multicast traffic, the NVE MUST either support ingress replication or multicast. - - - - - In this latter case, the NVE MUST be able to build at least a default flooding tree per VNI. 3.2.2. L3 VNI Requirement NVGRE VxLAN L2VPN L3VPN L3 VNIs MUST provide virtualized IP routing and forwarding. YES - - - - - L3 VNIs MUST support per-tenant forwarding instance with IP addressing isolation and L3 tunneling for interconnecting instances of the same VNI on NVEs. YES 3.3.1. NVO3 overlay header Requirement NVGRE VxLAN L2VPN L3VPN An NVO3 overlay header MUST be included after the underlay tunnel header when forwarding tenant traffic. YES 3.3.1.1. Virtual Network Context Identification Requirement NVGRE VxLAN L2VPN L3VPN The overlay encapsulation header MUST contain a field which allows the encapsulated frame to be delivered to the appropriate virtual network endpoint by the egress NVE. YES 3.3.1.2. Service QoS identifier Requirement NVGRE VxLAN L2VPN L3VPN Traffic flows originating from different applications could rely on differentiated forwarding treatment to meet end-to-end availability and performance objectives. NO 3.3.2.1. LAG and ECMP Requirement NVGRE VxLAN L2VPN L3VPN For performance reasons, multipath over LAG and ECMP paths SHOULD be supported. YES 3.3.2.2. DiffServ and ECN marking Requirement NVGRE VxLAN L2VPN L3VPN defines two modes for mapping the DSCP markings from inner to outer headers and vice versa. Both models SHOULD be supported. NO - - - - - ECN marking MUST be performed according to which describes the correct ECN behavior for IP tunnels. NO 3.3.2.3. Handling of broadcast, unknown unicast, and multicast traffic Requirement NVGRE VxLAN L2VPN L3VPN NVO3 data plane support for either ingress replication or point-to- multipoint tunnels is required to send traffic destined to multiple locations on a per-VNI basis (e.g. L2/L3 multicast traffic, L2 broadcast and unknown unicast traffic). YES 3.4. External NVO3 connectivity Requirement NVGRE VxLAN L2VPN L3VPN NVO3 services MUST interoperate with current VPN and Internet services. This may happen inside one DC during a migration phase or as NVO3 services are delivered to the outside world via Internet or VPN gateways. YES 3.5. Path MTU Requirement NVGRE VxLAN L2VPN L3VPN Classical ICMP-based MTU Path Discovery (, ) or Extended MTU Path Discovery techniques such as defined in . NO - - - - - Segmentation and reassembly support from the overlay layer operations without relying on the Tenant Systems to know about the end-to-end MTU. YES 3.7. NVE Multi-Homing Requirements Requirement NVGRE VxLAN L2VPN L3VPN Multi-homing techniques SHOULD be used to increase the reliability of an NVO3 network. NO 3.8. OAM Requirement NVGRE VxLAN L2VPN L3VPN NVE MAY be able to originate/terminate OAM messages for connectivity verification, performance monitoring, statistic gathering and fault isolation. Depending on configuration, NVEs SHOULD be able to process or transparently tunnel OAM messages, as well as supporting alarm propagation capabilities. NO