NVO3 Gap Analysis - Requirements Versus Available Technology Choices
draft-ietf-nvo3-gap-analysis-01

Abstract

This document evaluates candidate protocols against the NVO3 requirements. Gaps are identified and further work recommended.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 18, 2014.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology and Conventions
• 2.1. Requirements Language
• 2.2. Conventions
• 2.3. Terms and Abbreviations
• 3. Operational Requirements
• 4. Management Requirements
• 5. Control Plane Requirements
• 5.1. NVE-NVA Control-Plane Requirements
• 5.2. VM-to-NVE Specific Control-Plane Requirements
• 6. Data Plane Requirements
• 7. Summary and Conclusions
• 8. Acknowledgements
• 9. IANA Considerations
• 10. Security Considerations
• 11. References
• 11.1. Normative References
• 11.2. Informative References
• Authors' Addresses

1. Introduction

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 [I-D.ashwood-nvo3-operational-requirement]
• Management Requirements (TBD)
• Control (Plane) Requirements [I-D.ietf-nvo3-nve-nva-cp-req]
• Dataplane Requirements [I-D.ietf-nvo3-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 [I-D.sridharan-virtualization-nvgre],
• VxLAN [I-D.mahalingam-dutt-dcops-vxlan],
• L2VPN: VPLS [RFC4761][RFC4762] and EVPN [I-D.ietf-l2vpn-evpn], and
• L3VPN [RFC4365].

2. Terminology and Conventions

2.1. Requirements Language

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 [RFC2119].

2.2. Conventions

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.

2.3. Terms and Abbreviations

This document uses terms and acronyms defined in [RFC3168], [I-D.ietf-nvo3-framework], [I-D.ietf-nvo3-dataplane-requirements], [I-D.kreeger-nvo3-hypervisor-nve-cp] and [I-D.ietf-nvo3-nve-nva-cp-req]. Acronyms are included here for convenience but are meant to remain aligned with definitions in the references included.

ECN:

Explicit Congestion Notification [RFC3168]

NVA:

Network Virtualization Authority [I-D.ietf-nvo3-nve-nva-cp-req]

NVE:

Network Virtualization Edge [I-D.ietf-nvo3-framework]

VAP:

Virtual Access Point [I-D.ietf-nvo3-dataplane-requirements]

VNI:

Virtual Network Instance [I-D.ietf-nvo3-framework]

VNIC:

Virtual Network Interface Card (NIC) [I-D.kreeger-nvo3-hypervisor-nve-cp]

VNID:

Virtual Network Identifier [I-D.ietf-nvo3-nve-nva-cp-req]

This document uses the following additional general terms and abbreviations:

DSCP:

Differentiated Services Code-Point

ECMP:

Equal Cost Multi-Path

L2VPN:

Layer 2 Virtual Private Network

L3VPN:

Layer 3 Virtual Private Network

NVO3:

Network Virtualization Overlay over L3

VM:

Virtual Machine

VN:

Virtual Network

3. Operational Requirements

TBD

4. Management Requirements

TBD

5. Control Plane Requirements

The NVO3 Problem Statement [I-D.ietf-nvo3-overlay-problem-statement], describes 3 categories of control functions:

1. Control functions associated with implementing the Network Virtualization Authority (e.g. - signaling and control required for interactions between multiple NVA devices).
2. Control functions associated with interactions between an NVA and a Network Virtualization Edge (NVE).
3. 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 [I-D.ietf-nvo3-overlay-problem-statement] and requirements documents intended to address the problems that have been identified there.

Current control-plane requirement documents include the following:

• NVE-NVA control-plane requirements [I-D.ietf-nvo3-nve-nva-cp-req]
• Control-plane requirements specific to VM-to-NVE interactions [I-D.kreeger-nvo3-hypervisor-nve-cp]

In the following subsections, we consider the data-plane candidate solutions and proposed or existing control plane solutions that may apply to each.

In each case, the control-plane solutions can be divided into support for Layer-2 and Layer-3 services, and for each of these cases, the data-plane solutions considered will be limited to those services and solutions that make sense for that case.

Tables are thus organized into separate tables for both L2 and L3 data/control service options. It may turn out that - for all potential control-plane solutions - each solution applies equally to all data-plane solutions considered for the layer applicable.

If this turns out to be the case, then the tables may be further simplified - possibly by reducing each pair of L2/L3 tables to a single table where the columns are simply "Layer-2" and "Layer-3."

The intent is to show potential mapping of data-plane to applicable control-plane alternatives and evaluate each applicable control-plane against defined control-plane requirements.

The way this document attempts to do this is to list the control planes that may be applicable to each of the candidate data-planes in table footnotes and then stating in table footnotes the extent to which candidate control plane technologies satisfy each requirement.

As with tables in other sections of this draft, the rows in each table list the applicable requirements found in analogous sections of applicable requirements documents.

5.1. NVE-NVA Control-Plane Requirements

In this section, numbering of requirement headings corresponds to section numbering in [I-D.ietf-nvo3-nve-nva-cp-req].

(3.1) Inner to Outer Address Mapping

The requirements document [I-D.ietf-nvo3-nve-nva-cp-req] 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?