NVO3 Gap Analysis - Requirements Versus Available Technology Choices

The initial charter of the NVO3 Working Group requires it to identify any gaps between the requirements identified and available technoloogy solutions as a prerequisite to rechartering or concluding the Working Group (if no gaps exist). This document is intended to provide the required gap analysis. This document provides a tabulation of candidate solutions and their ability to satisfy each requirement identified by the Working Group. Areas of work are identified where further work is required to ensure that the requirements are met. The major areas covered in this document include: Operational Requirements Management Requirements (TBD) Control (Plane) Requirements Dataplane Requirements Since the Working Group has yet to complete (and in some cases adopt) documents describing requirements for some of these areas, not all areas are complete in the present version of this document. The initial candidate technologies are: NVGRE , VxLAN , L2VPN: VPLS and EVPN , and L3VPN .

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.

In sections providing analysis of requirements defined in referenced documents, section numbers from each referenced document are used as they were listed in that document. In order to avoid confusing those section numbers with the section numbering in this document, the included numbering is parenthesized. L2VPN is represented (in tables and analysis, as a technology) by the two differing approaches: VPLS and EVPN.

This document uses terms and acronyms defined in , , , and . Acronyms are included here for convenience but are meant to remain aligned with definitions in the references included. Explicit Congestion Notification Network Virtualization Authority Network Virtualization Edge Virtual Access Point Virtual Network Instance Virtual Network Interface Card (NIC) Virtual Network Identifier This document uses the following additional general terms and abbreviations: Differentiated Services Code-Point Equal Cost Multi-Path Layer 2 Virtual Private Network Layer 3 Virtual Private Network Network Virtualization Overlay over L3 Virtual Machine Virtual Network

TBD

The NVO3 Problem Statement , describes 3 categories of control functions: Control functions associated with implementing the Network Virtualization Authority (e.g. - signaling and control required for interactions between multiple NVA devices). Control functions associated with interactions between an NVA and a Network Virtualization Edge (NVE). Control functions associated with attaching and detaching a Virtual Machine (VM) from a particular Virtual Network Instance (VNI). As sometimes happens, there is not a 1:1 mapping of the work areas defined in and requirements documents intended to address the problems that have been identified there. Current control-plane requirement documents include the following: Overall control-plane requirements Control-plane requirements specific to VM-to-NVE interactions

In this section, numbering of requirement headings corresponds to section numbering in . (3.1) Inner to Outer Address Mapping The requirements document states that avoiding the need to "flood" traffic to support learning of mapping information from the data-plane is a goal of NVO3 candidate technological approaches. For each candidate technology, (how) is the mapping of header information present in tenant traffic mapped to corresponding header information to be used in overlay encapsulation (this includes addresses, context identification, etc.) determined? Supported Approach NVGRE VxLAN VPLS EVPN L3VPN Control Protocol Acquisition? - - - - - - - - - - - - - - - - - - Data-Plane Learning? (3.2) Underlying Network Multi-Destination Address(es) The requirements document lists 3 approaches that may be used to deliver traffic to multiple destinations in an overlay virtual network: Use the capabilities of the underlay network. Require a sending NVE to replicate traffic. Use a replication service provided within the overlay network. For each delivery approach, it may be necessary to map specific multipoint (e.g. - broadcast, unknown destination or multicast) traffic to (for instance) addresses used to deliver this traffic via the underlay network. For each technological approach, which delivery approaches are supported and does the technology provide a method by which an NVE needing to send multi-destination traffic can determine to what address, or addresses to which to send this traffic? Supported Approach NVGRE VxLAN VPLS EVPN L3VPN Underlay Network Capability - - - - - - - - - - - - - - - - - - NVE Sender Replication - - - - - - - - - - - - - - - - - - Replication Service (3.3) VN Connect/Disconnect Notification The requirements document states as an assumption that a mechanism exists in the overlay technology by which an NVE is notified of Tenant Systems attaching and detaching from a specific Virtual Network (VN). For each candidate technology, does the technology currently support these functions? Requirement NVGRE VxLAN VPLS EVPN L3VPN Connect Notification - - - - - - - - - - - - - - - - - - Disconnect Notification (3.4) VN Name to VNID Mapping The requirements document concludes that having a means to map for a "VN Name to a "VN ID" may be useful. For each technological approach we are considering, is this function currently available? Function NVGRE VxLAN VPLS EVPN L3VPN VN-Name:VN-ID Mapping

In this section, numbering of requirement headings corresponds to section numbering in . (4.1) VN Connect/Disconnect The requirements document states as a requirement that a mechanism must exist by which an NVE is notified when an end device requires a connection, or no longer requires a connection, to a specific Virtual Network (VN). The requirements document further states as a requirement that the mechanism(s) used in a candidate technological approach must provide a local indicator (e.g. - 802.1Q tag) that the end device will use in sending traffic to, or receiving traffic from, the NVE (where that traffic is associated with the connected VN). As an additional related requirement, the requirements document states that the NVE - once notified of a connection to a VN (by VN Name), needs to have a means for getting associated VN context information from the NVA. For each candidate technology, does the technology currently support these functions? Requirement NVGRE VxLAN VPLS EVPN L3VPN Connect Notification - - - - - - - - - - - - - - - - - - Local VN Indicator - - - - - - - - - - - - - - - - - - VN Name to VN Context Mapping - - - - - - - - - - - - - - - - - - Disconnect Notification (4.2) VNIC Address Association The requirements document lists two approaches for acquiring VNIC address association information: Data Plane Learning (i.e. - by inspecting source addresses in traffic received from an end device). Explicit signaling from the end device when a specific VNIC address is to be associated with a tenant system. Supported Approaches NVGRE VxLAN VPLS EVPN L3VPN Data Plane Learning - - - - - - - - - - - - - - - - - - Explicit Signaling (4.3) VNIC Address Disassociation TBD (4.4) VNIC Shutdown/Startup/Migration TBD (4.5) VN Profile TBD

In this section, numbering of requirement headings corresponds to section numbering in . (3.1) Virtual Access Points (VAPs) Requirement NVGRE VxLAN VPLS EVPN 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 VPLS EVPN L3VPN VAP are associated with a specific VNI at service instantiation time. YES (3.2.1) L2 VNI Requirement NVGRE VxLAN VPLS EVPN 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). - - - - - - - - - - - - - - - - - - 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 VPLS EVPN L3VPN L3 VNIs MUST provide virtualized IP routing and forwarding. - - - - - - - - - - - - - - - - - - L3 VNIs MUST support per-tenant forwarding instance with IP addressing isolation and L3 tunneling for interconnecting instances of the same VNI on NVEs. (3.3.1) NVO3 overlay header Requirement NVGRE VxLAN VPLS EVPN L3VPN An NVO3 overlay header MUST be included after the underlay tunnel header when forwarding tenant traffic. YES YES YES YES YES (3.3.1.1) Virtual Network Context Identification Requirement NVGRE VxLAN VPLS EVPN 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 YES YES YES YES (3.3.1.2) Service QoS identifier Requirement NVGRE VxLAN VPLS EVPN 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 VPLS EVPN 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 VPLS EVPN 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 VPLS EVPN 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 YES YES YES YES (3.4) External NVO3 connectivity Requirement NVGRE VxLAN VPLS EVPN 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 VPLS EVPN 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 VPLS EVPN L3VPN Multi-homing techniques SHOULD be used to increase the reliability of an NVO3 network. NO (3.8) OAM Requirement NVGRE VxLAN VPLS EVPN 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

TBD

The Authors would like to acknowledge the technical contributions of Florin Balus, Luyuan Fang, Sue Hares, Wim Henderickx, Yuichi Ikejiri, Rangaraju Iyengar, Mircea Pisica, Evelyn Roch, Ali Sajassi, Peter Ashwood-Smith and Lucy Yong as well as the initial help in editing the XML source for the document from Tom Taylor.

This memo includes no request to IANA.

Security considerations of the requirements documents referenced by this analysis document apply.