draft-ietf-nvo3-geneve-09.txt   draft-ietf-nvo3-geneve-10.txt 
Network Working Group J. Gross, Ed. Network Working Group J. Gross, Ed.
Internet-Draft Internet-Draft
Intended status: Standards Track I. Ganga, Ed. Intended status: Standards Track I. Ganga, Ed.
Expires: August 26, 2019 Intel Expires: September 4, 2019 Intel
T. Sridhar, Ed. T. Sridhar, Ed.
VMware VMware
February 22, 2019 March 03, 2019
Geneve: Generic Network Virtualization Encapsulation Geneve: Generic Network Virtualization Encapsulation
draft-ietf-nvo3-geneve-09 draft-ietf-nvo3-geneve-10
Abstract Abstract
Network virtualization involves the cooperation of devices with a Network virtualization involves the cooperation of devices with a
wide variety of capabilities such as software and hardware tunnel wide variety of capabilities such as software and hardware tunnel
endpoints, transit fabrics, and centralized control clusters. As a endpoints, transit fabrics, and centralized control clusters. As a
result of their role in tying together different elements in the result of their role in tying together different elements in the
system, the requirements on tunnels are influenced by all of these system, the requirements on tunnels are influenced by all of these
components. Flexibility is therefore the most important aspect of a components. Flexibility is therefore the most important aspect of a
tunnel protocol if it is to keep pace with the evolution of the tunnel protocol if it is to keep pace with the evolution of the
system. This draft describes Geneve, a protocol designed to system. This document describes Geneve, an encapsulation protocol
recognize and accommodate these changing capabilities and needs. designed to recognize and accommodate these changing capabilities and
needs.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 26, 2019. This Internet-Draft will expire on September 4, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 36
3.1. Geneve Packet Format Over IPv4 . . . . . . . . . . . . . 9 3.1. Geneve Packet Format Over IPv4 . . . . . . . . . . . . . 9
3.2. Geneve Packet Format Over IPv6 . . . . . . . . . . . . . 10 3.2. Geneve Packet Format Over IPv6 . . . . . . . . . . . . . 10
3.3. UDP Header . . . . . . . . . . . . . . . . . . . . . . . 12 3.3. UDP Header . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Tunnel Header Fields . . . . . . . . . . . . . . . . . . 13 3.4. Tunnel Header Fields . . . . . . . . . . . . . . . . . . 13
3.5. Tunnel Options . . . . . . . . . . . . . . . . . . . . . 14 3.5. Tunnel Options . . . . . . . . . . . . . . . . . . . . . 14
3.5.1. Options Processing . . . . . . . . . . . . . . . . . 16 3.5.1. Options Processing . . . . . . . . . . . . . . . . . 16
4. Implementation and Deployment Considerations . . . . . . . . 17 4. Implementation and Deployment Considerations . . . . . . . . 17
4.1. Applicability Statement . . . . . . . . . . . . . . . . . 17 4.1. Applicability Statement . . . . . . . . . . . . . . . . . 17
4.2. Congestion Control Functionality . . . . . . . . . . . . 18 4.2. Congestion Control Functionality . . . . . . . . . . . . 18
4.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 18 4.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1. UDP Zero Checksum Handling with IPv6 . . . . . . . . 18 4.3.1. UDP Zero Checksum Handling with IPv6 . . . . . . . . 19
4.4. Encapsulation of Geneve in IP . . . . . . . . . . . . . . 20 4.4. Encapsulation of Geneve in IP . . . . . . . . . . . . . . 20
4.4.1. IP Fragmentation . . . . . . . . . . . . . . . . . . 20 4.4.1. IP Fragmentation . . . . . . . . . . . . . . . . . . 20
4.4.2. DSCP, ECN and TTL . . . . . . . . . . . . . . . . . . 21 4.4.2. DSCP, ECN and TTL . . . . . . . . . . . . . . . . . . 21
4.4.3. Broadcast and Multicast . . . . . . . . . . . . . . . 22 4.4.3. Broadcast and Multicast . . . . . . . . . . . . . . . 22
4.4.4. Unidirectional Tunnels . . . . . . . . . . . . . . . 22 4.4.4. Unidirectional Tunnels . . . . . . . . . . . . . . . 22
4.5. Constraints on Protocol Features . . . . . . . . . . . . 23 4.5. Constraints on Protocol Features . . . . . . . . . . . . 23
4.5.1. Constraints on Options . . . . . . . . . . . . . . . 23 4.5.1. Constraints on Options . . . . . . . . . . . . . . . 23
4.6. NIC Offloads . . . . . . . . . . . . . . . . . . . . . . 23 4.6. NIC Offloads . . . . . . . . . . . . . . . . . . . . . . 24
4.7. Inner VLAN Handling . . . . . . . . . . . . . . . . . . . 24 4.7. Inner VLAN Handling . . . . . . . . . . . . . . . . . . . 24
5. Interoperability Issues . . . . . . . . . . . . . . . . . . . 24 5. Interoperability Issues . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6.1. Data Confidentiality . . . . . . . . . . . . . . . . . . 26 6.1. Data Confidentiality . . . . . . . . . . . . . . . . . . 26
6.1.1. Inter-Data Center Traffic . . . . . . . . . . . . . . 26 6.1.1. Inter-Data Center Traffic . . . . . . . . . . . . . . 26
6.2. Data Integrity . . . . . . . . . . . . . . . . . . . . . 27 6.2. Data Integrity . . . . . . . . . . . . . . . . . . . . . 27
6.3. Authentication of NVE peers . . . . . . . . . . . . . . . 27 6.3. Authentication of NVE peers . . . . . . . . . . . . . . . 27
6.4. Options Interpretation by Transit Devices . . . . . . . . 27 6.4. Options Interpretation by Transit Devices . . . . . . . . 28
6.5. Multicast/Broadcast . . . . . . . . . . . . . . . . . . . 28 6.5. Multicast/Broadcast . . . . . . . . . . . . . . . . . . . 28
6.6. Control Plane Communications . . . . . . . . . . . . . . 28 6.6. Control Plane Communications . . . . . . . . . . . . . . 28
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Normative References . . . . . . . . . . . . . . . . . . 31 10.1. Normative References . . . . . . . . . . . . . . . . . . 31
10.2. Informative References . . . . . . . . . . . . . . . . . 32 10.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
Networking has long featured a variety of tunneling, tagging, and Networking has long featured a variety of tunneling, tagging, and
other encapsulation mechanisms. However, the advent of network other encapsulation mechanisms. However, the advent of network
virtualization has caused a surge of renewed interest and a virtualization has caused a surge of renewed interest and a
corresponding increase in the introduction of new protocols. The corresponding increase in the introduction of new protocols. The
large number of protocols in this space, ranging all the way from large number of protocols in this space, ranging all the way from
VLANs [IEEE.802.1Q_2014] and MPLS [RFC3031] through the more recent VLANs [IEEE.802.1Q_2014] and MPLS [RFC3031] through the more recent
VXLAN [RFC7348], NVGRE [RFC7637], often leads to questions about the VXLAN [RFC7348] (Virtual eXtensible Local Area Network) and NVGRE
need for new encapsulation formats and what it is about network [RFC7637] (Network Virtualization Using Generic Routing
virtualization in particular that leads to their proliferation. Encapsulation), often leads to questions about the need for new
encapsulation formats and what it is about network virtualization in
particular that leads to their proliferation.
While many encapsulation protocols seek to simply partition the While many encapsulation protocols seek to simply partition the
underlay network or bridge between two domains, network underlay network or bridge between two domains, network
virtualization views the transit network as providing connectivity virtualization views the transit network as providing connectivity
between multiple components of a distributed system. In many ways between multiple components of a distributed system. In many ways
this system is similar to a chassis switch with the IP underlay this system is similar to a chassis switch with the IP underlay
network playing the role of the backplane and tunnel endpoints on the network playing the role of the backplane and tunnel endpoints on the
edge as line cards. When viewed in this light, the requirements edge as line cards. When viewed in this light, the requirements
placed on the tunnel protocol are significantly different in terms of placed on the tunnel protocol are significantly different in terms of
the quantity of metadata necessary and the role of transit nodes. the quantity of metadata necessary and the role of transit nodes.
Current work such as VL2 [VL2] and the NVO3 working group Current work such as [VL2] (A Scalable and Flexible Data Center
Network) and the NVO3 Data Plane Requirements
[I-D.ietf-nvo3-dataplane-requirements] have described some of the [I-D.ietf-nvo3-dataplane-requirements] have described some of the
properties that the data plane must have to support network properties that the data plane must have to support network
virtualization. However, one additional defining requirement is the virtualization. However, one additional defining requirement is the
need to carry system state along with the packet data. The use of need to carry system state along with the packet data. The use of
some metadata is certainly not a foreign concept - nearly all some metadata is certainly not a foreign concept - nearly all
protocols used for virtualization have at least 24 bits of identifier protocols used for virtualization have at least 24 bits of identifier
space as a way to partition between tenants. This is often described space as a way to partition between tenants. This is often described
as overcoming the limits of 12-bit VLANs, and when seen in that as overcoming the limits of 12-bit VLANs, and when seen in that
context, or any context where it is a true tenant identifier, 16 context, or any context where it is a true tenant identifier, 16
million possible entries is a large number. However, the reality is million possible entries is a large number. However, the reality is
skipping to change at page 4, line 29 skipping to change at page 4, line 34
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Terminology 1.2. Terminology
The NVO3 framework [RFC7365] defines many of the concepts commonly The NVO3 framework [RFC7365] defines many of the concepts commonly
used in network virtualization. In addition, the following terms are used in network virtualization. In addition, the following terms are
specifically meaningful in this document: specifically meaningful in this document:
Checksum offload. An optimization implemented by many NICs which Checksum offload. An optimization implemented by many NICs (Network
enables computation and verification of upper layer protocol Interface Controller) which enables computation and verification of
checksums in hardware on transmit and receive, respectively. This upper layer protocol checksums in hardware on transmit and receive,
typically includes IP and TCP/UDP checksums which would otherwise be respectively. This typically includes IP and TCP/UDP checksums which
computed by the protocol stack in software. would otherwise be computed by the protocol stack in software.
Clos network. A technique for composing network fabrics larger than Clos network. A technique for composing network fabrics larger than
a single switch while maintaining non-blocking bandwidth across a single switch while maintaining non-blocking bandwidth across
connection points. ECMP is used to divide traffic across the connection points. ECMP is used to divide traffic across the
multiple links and switches that constitute the fabric. Sometimes multiple links and switches that constitute the fabric. Sometimes
termed "leaf and spine" or "fat tree" topologies. termed "leaf and spine" or "fat tree" topologies.
ECMP. Equal Cost Multipath. A routing mechanism for selecting from ECMP. Equal Cost Multipath. A routing mechanism for selecting from
among multiple best next hop paths by hashing packet headers in order among multiple best next hop paths by hashing packet headers in order
to better utilize network bandwidth while avoiding reordering of to better utilize network bandwidth while avoiding reordering of
packets within a flow. packets within a flow.
Geneve. Generic Network Virtualization Encapsulation. The tunnel Geneve. Generic Network Virtualization Encapsulation. The tunnel
protocol described in this draft. protocol described in this document.
LRO. Large Receive Offload. The receive-side equivalent function of LRO. Large Receive Offload. The receive-side equivalent function of
LSO, in which multiple protocol segments (primarily TCP) are LSO, in which multiple protocol segments (primarily TCP) are
coalesced into larger data units. coalesced into larger data units.
NIC. Network Interface Card. A NIC could be part of a tunnel NIC. Network Interface Controller. Also called as Network Interface
endpoint or transit device and can either process Geneve packets or Card or Network Adapter. A NIC could be part of a tunnel endpoint or
aid in the processing of Geneve packets. transit device and can either process Geneve packets or aid in the
processing of Geneve packets.
Transit device. A forwarding element along the path of the tunnel Transit device. A forwarding element along the path of the tunnel
making up part of the Underlay Network. A transit device MAY be making up part of the Underlay Network. A transit device MAY be
capable of understanding the Geneve packet format but does not capable of understanding the Geneve packet format but does not
originate or terminate Geneve packets. originate or terminate Geneve packets.
LSO. Large Segmentation Offload. A function provided by many LSO. Large Segmentation Offload. A function provided by many
commercial NICs that allows data units larger than the MTU to be commercial NICs that allows data units larger than the MTU to be
passed to the NIC to improve performance, the NIC being responsible passed to the NIC to improve performance, the NIC being responsible
for creating smaller segments of size less than or equal to the MTU for creating smaller segments of size less than or equal to the MTU
skipping to change at page 5, line 41 skipping to change at page 5, line 49
VM. Virtual Machine. VM. Virtual Machine.
2. Design Requirements 2. Design Requirements
Geneve is designed to support network virtualization use cases, where Geneve is designed to support network virtualization use cases, where
tunnels are typically established to act as a backplane between the tunnels are typically established to act as a backplane between the
virtual switches residing in hypervisors, physical switches, or virtual switches residing in hypervisors, physical switches, or
middleboxes or other appliances. An arbitrary IP network can be used middleboxes or other appliances. An arbitrary IP network can be used
as an underlay although Clos networks composed using ECMP links are a as an underlay although Clos networks composed using ECMP links are a
common choice to provide consistent bisectional bandwidth across all common choice to provide consistent bisectional bandwidth across all
connection points. Figure 1 shows an example of a hypervisor, top of connection points. Many of the concepts of network virtualization
rack switch for connectivity to physical servers, and a WAN uplink overlays over Layer 3 IP networks are described in NVO3 Framework
framework [RFC7365]. Figure 1 shows an example of a hypervisor, top
of rack switch for connectivity to physical servers, and a WAN uplink
connected using Geneve tunnels over a simplified Clos network. These connected using Geneve tunnels over a simplified Clos network. These
tunnels are used to encapsulate and forward frames from the attached tunnels are used to encapsulate and forward frames from the attached
components such as VMs or physical links. components such as VMs or physical links.
+---------------------+ +-------+ +------+ +---------------------+ +-------+ +------+
| +--+ +-------+---+ | |Transit|--|Top of|==Physical | +--+ +-------+---+ | |Transit|--|Top of|==Physical
| |VM|--| | | | +------+ /|Router | | Rack |==Servers | |VM|--| | | | +------+ /|Router | | Rack |==Servers
| +--+ |Virtual|NIC|---|Top of|/ +-------+\/+------+ | +--+ |Virtual|NIC|---|Top of|/ +-------+\/+------+
| +--+ |Switch | | | | Rack |\ +-------+/\+------+ | +--+ |Switch | | | | Rack |\ +-------+/\+------+
| |VM|--| | | | +------+ \|Transit| |Uplink| WAN | |VM|--| | | | +------+ \|Transit| |Uplink| WAN
skipping to change at page 6, line 42 skipping to change at page 6, line 45
o High performance over existing IP fabrics. o High performance over existing IP fabrics.
These requirements are described further in the following These requirements are described further in the following
subsections. subsections.
2.1. Control Plane Independence 2.1. Control Plane Independence
Although some protocols for network virtualization have included a Although some protocols for network virtualization have included a
control plane as part of the tunnel format specification (most control plane as part of the tunnel format specification (most
notably, the original VXLAN spec prescribed a multicast learning- notably, the VXLAN spec prescribed a multicast learning- based
based control plane), these specifications have largely been treated control plane), these specifications have largely been treated as
as describing only the data format. The VXLAN packet format has describing only the data format. The VXLAN packet format has
actually seen a wide variety of control planes built on top of it. actually seen a wide variety of control planes built on top of it.
There is a clear advantage in settling on a data format: most of the There is a clear advantage in settling on a data format: most of the
protocols are only superficially different and there is little protocols are only superficially different and there is little
advantage in duplicating effort. However, the same cannot be said of advantage in duplicating effort. However, the same cannot be said of
control planes, which are diverse in very fundamental ways. The case control planes, which are diverse in very fundamental ways. The case
for standardization is also less clear given the wide variety in for standardization is also less clear given the wide variety in
requirements, goals, and deployment scenarios. requirements, goals, and deployment scenarios.
As a result of this reality, Geneve aims to be a pure tunnel format As a result of this reality, Geneve is a pure tunnel format
specification that is capable of fulfilling the needs of many control specification that is capable of fulfilling the needs of many control
planes by explicitly not selecting any one of them. This planes by explicitly not selecting any one of them. This
simultaneously promotes a shared data format and increases the simultaneously promotes a shared data format and reduces the chance
chances that it will not be obsoleted by future control plane of obsolescence by future control plane enhancements.
enhancements.
2.2. Data Plane Extensibility 2.2. Data Plane Extensibility
Achieving the level of flexibility needed to support current and Achieving the level of flexibility needed to support current and
future control planes effectively requires an options infrastructure future control planes effectively requires an options infrastructure
to allow new metadata types to be defined, deployed, and either to allow new metadata types to be defined, deployed, and either
finalized or retired. Options also allow for differentiation of finalized or retired. Options also allow for differentiation of
products by encouraging independent development in each vendor's core products by encouraging independent development in each vendor's core
specialty, leading to an overall faster pace of advancement. By far specialty, leading to an overall faster pace of advancement. By far
the most common mechanism for implementing options is Type-Length- the most common mechanism for implementing options is Type-Length-
skipping to change at page 7, line 37 skipping to change at page 7, line 40
service interposition both require tags to be placed on data service interposition both require tags to be placed on data
packets). Therefore, while it would be desirable to limit the packets). Therefore, while it would be desirable to limit the
extensibility to only control packets for the purposes of simplifying extensibility to only control packets for the purposes of simplifying
the datapath, that would not satisfy the design requirements. the datapath, that would not satisfy the design requirements.
2.2.1. Efficient Implementation 2.2.1. Efficient Implementation
There is often a conflict between software flexibility and hardware There is often a conflict between software flexibility and hardware
performance that is difficult to resolve. For a given set of performance that is difficult to resolve. For a given set of
functionality, it is obviously desirable to maximize performance. functionality, it is obviously desirable to maximize performance.
However, that does not mean new features that cannot be run at that However, that does not mean new features that cannot be run at a
speed today should be disallowed. Therefore, for a protocol to be desired speed today should be disallowed. Therefore, for a protocol
efficiently implementable means that a set of common capabilities can to be efficiently implementable means that a set of common
be reasonably handled across platforms along with a graceful capabilities can be reasonably handled across platforms along with a
mechanism to handle more advanced features in the appropriate graceful mechanism to handle more advanced features in the
situations. appropriate situations.
The use of a variable length header and options in a protocol often The use of a variable length header and options in a protocol often
raises questions about whether it is truly efficiently implementable raises questions about whether it is truly efficiently implementable
in hardware. To answer this question in the context of Geneve, it is in hardware. To answer this question in the context of Geneve, it is
important to first divide "hardware" into two categories: tunnel important to first divide "hardware" into two categories: tunnel
endpoints and transit devices. endpoints and transit devices.
Tunnel endpoints must be able to parse the variable header, including Tunnel endpoints must be able to parse the variable header, including
any options, and take action. Since these devices are actively any options, and take action. Since these devices are actively
participating in the protocol, they are the most affected by Geneve. participating in the protocol, they are the most affected by Geneve.
However, as tunnel endpoints are the ultimate consumers of the data, However, as tunnel endpoints are the ultimate consumers of the data,
transmitters can tailor their output to the capabilities of the transmitters can tailor their output to the capabilities of the
recipient. As new functionality becomes sufficiently well defined to recipient. As new functionality becomes sufficiently well defined to
add to tunnel endpoints, supporting options can be designed using add to tunnel endpoints, supporting options can be designed using
ordering restrictions and other techniques to ease parsing. ordering restrictions and other techniques to ease parsing.
Options, if present in the packet, MUST be generated and terminated Options, if present in the packet, MUST only be generated and
by tunnel endpoints. Transit devices MAY be able to interpret the terminated by tunnel endpoints. Transit devices MAY be able to
options, however, as non-terminating devices, transit devices do not interpret the options, however, as non-terminating devices, transit
originate or terminate the Geneve packet, hence MUST NOT modify devices do not originate or terminate the Geneve packet, hence MUST
Geneve headers and MUST NOT insert or delete options, which is the NOT modify Geneve headers and MUST NOT insert or delete options,
responsibility of tunnel endpoints. The participation of transit which is the responsibility of tunnel endpoints. The participation
devices in interpreting options is OPTIONAL. of transit devices in interpreting options is OPTIONAL.
Further, either tunnel endpoints or transit devices MAY use offload Further, either tunnel endpoints or transit devices MAY use offload
capabilities of NICs such as checksum offload to improve the capabilities of NICs such as checksum offload to improve the
performance of Geneve packet processing. The presence of a Geneve performance of Geneve packet processing. The presence of a Geneve
variable length header SHOULD NOT prevent the tunnel endpoints and variable length header SHOULD NOT prevent the tunnel endpoints and
transit devices from using such offload capabilities. transit devices from using such offload capabilities.
2.3. Use of Standard IP Fabrics 2.3. Use of Standard IP Fabrics
IP has clearly cemented its place as the dominant transport mechanism IP has clearly cemented its place as the dominant transport mechanism
skipping to change at page 17, line 31 skipping to change at page 17, line 40
4. Implementation and Deployment Considerations 4. Implementation and Deployment Considerations
4.1. Applicability Statement 4.1. Applicability Statement
Geneve is a network virtualization overlay encapsulation protocol Geneve is a network virtualization overlay encapsulation protocol
designed to establish tunnels between NVEs over an existing IP designed to establish tunnels between NVEs over an existing IP
network. It is intended for use in public or private data center network. It is intended for use in public or private data center
environments, for deploying multi-tenant overlay networks over an environments, for deploying multi-tenant overlay networks over an
existing IP underlay network. existing IP underlay network.
Geneve is an UDP based encapsulation protocol transported over Geneve is a UDP based encapsulation protocol transported over
existing IPv4 and IPv6 networks. Hence, as an UDP based protocol, existing IPv4 and IPv6 networks. Hence, as a UDP based protocol,
Geneve needs to meet the UDP usage guidelines as specified in Geneve adheres to the UDP usage guidelines as specified in [RFC8085].
[RFC8085]. The applicability of these guidelines are dependent on The applicability of these guidelines are dependent on the underlay
the underlay IP network and the nature of Geneve payload protocol IP network and the nature of Geneve payload protocol (example TCP/IP,
(example TCP/IP, IP/Ethernet). IP/Ethernet).
[RFC8085] outlines two applicability scenarios for UDP applications, [RFC8085] outlines two applicability scenarios for UDP applications,
1) general Internet and 2) controlled environment. The controlled 1) general Internet and 2) controlled environment. The controlled
environment means a single administrative domain or adjacent set of environment means a single administrative domain or adjacent set of
cooperating domains. A network in a controlled environment can be cooperating domains. A network in a controlled environment can be
managed to operate under certain conditions whereas in general managed to operate under certain conditions whereas in general
Internet this cannot be done. Hence requirements for a tunnel Internet this cannot be done. Hence requirements for a tunnel
protocol operating under a controlled environment can be less protocol operating under a controlled environment can be less
restrictive than the requirements of general internet. restrictive than the requirements of general internet.
skipping to change at page 25, line 26 skipping to change at page 25, line 35
devices do not introduce additional interoperability concerns. devices do not introduce additional interoperability concerns.
To assist with this transition, it is strongly suggested that To assist with this transition, it is strongly suggested that
implementations support simultaneous operation of both Geneve and implementations support simultaneous operation of both Geneve and
existing tunnel protocols as it is expected to be common for a single existing tunnel protocols as it is expected to be common for a single
node to communicate with a mixture of other nodes. Eventually, older node to communicate with a mixture of other nodes. Eventually, older
protocols may be phased out as they are no longer in use. protocols may be phased out as they are no longer in use.
6. Security Considerations 6. Security Considerations
As encapsulated within an UDP/IP packet, Geneve does not have any As encapsulated within a UDP/IP packet, Geneve does not have any
inherent security mechanisms. As a result, an attacker with access inherent security mechanisms. As a result, an attacker with access
to the underlay network transporting the IP packets has the ability to the underlay network transporting the IP packets has the ability
to snoop or inject packets. Compromised tunnel endpoints may also to snoop or inject packets. Compromised tunnel endpoints may also
spoof identifiers in the tunnel header to gain access to networks spoof identifiers in the tunnel header to gain access to networks
owned by other tenants. owned by other tenants.
Within a particular security domain, such as a data center operated Within a particular security domain, such as a data center operated
by a single service provider, the most common and highest performing by a single service provider, the most common and highest performing
security mechanism is isolation of trusted components. Tunnel security mechanism is isolation of trusted components. Tunnel
traffic can be carried over a separate VLAN and filtered at any traffic can be carried over a separate VLAN and filtered at any
skipping to change at page 29, line 21 skipping to change at page 29, line 35
+----------------+--------------------------------------+ +----------------+--------------------------------------+
| 0x0000..0x00FF | Unassigned - IETF Review | | 0x0000..0x00FF | Unassigned - IETF Review |
| 0x0100 | Linux | | 0x0100 | Linux |
| 0x0101 | Open vSwitch (OVS) | | 0x0101 | Open vSwitch (OVS) |
| 0x0102 | Open Virtual Networking (OVN) | | 0x0102 | Open Virtual Networking (OVN) |
| 0x0103 | In-band Network Telemetry (INT) | | 0x0103 | In-band Network Telemetry (INT) |
| 0x0104 | VMware, Inc. | | 0x0104 | VMware, Inc. |
| 0x0105 | Amazon.com, Inc. | | 0x0105 | Amazon.com, Inc. |
| 0x0106 | Cisco Systems, Inc. | | 0x0106 | Cisco Systems, Inc. |
| 0x0107 | Oracle Corporation | | 0x0107 | Oracle Corporation |
| 0x0108..0xFFEF | Unassigned - First Come First Served | | 0x0108..0x110 | Amazon.com, Inc. |
| 0x0111..0xFFEF | Unassigned - First Come First Served |
| 0xFFF0..FFFF | Experimental | | 0xFFF0..FFFF | Experimental |
+----------------+--------------------------------------+ +----------------+--------------------------------------+
8. Contributors 8. Contributors
The following individuals were authors of an earlier version of this The following individuals were authors of an earlier version of this
document and made significant contributions: document and made significant contributions:
Pankaj Garg Pankaj Garg
Microsoft Corporation Microsoft Corporation
skipping to change at page 31, line 46 skipping to change at page 32, line 15
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935, UDP Checksums for Tunneled Packets", RFC 6935,
DOI 10.17487/RFC6935, April 2013, DOI 10.17487/RFC6935, April 2013,
<https://www.rfc-editor.org/info/rfc6935>. <https://www.rfc-editor.org/info/rfc6935>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums", for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, DOI 10.17487/RFC6936, April 2013, RFC 6936, DOI 10.17487/RFC6936, April 2013,
<https://www.rfc-editor.org/info/rfc6936>. <https://www.rfc-editor.org/info/rfc6936>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 10.2. Informative References
skipping to change at page 34, line 11 skipping to change at page 34, line 32
Virtualization Using Generic Routing Encapsulation", Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015, RFC 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>. <https://www.rfc-editor.org/info/rfc7637>.
[RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T.
Narten, "An Architecture for Data-Center Network Narten, "An Architecture for Data-Center Network
Virtualization over Layer 3 (NVO3)", RFC 8014, Virtualization over Layer 3 (NVO3)", RFC 8014,
DOI 10.17487/RFC8014, December 2016, DOI 10.17487/RFC8014, December 2016,
<https://www.rfc-editor.org/info/rfc8014>. <https://www.rfc-editor.org/info/rfc8014>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-
in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086,
March 2017, <https://www.rfc-editor.org/info/rfc8086>. March 2017, <https://www.rfc-editor.org/info/rfc8086>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
[RFC8293] Ghanwani, A., Dunbar, L., McBride, M., Bannai, V., and R. [RFC8293] Ghanwani, A., Dunbar, L., McBride, M., Bannai, V., and R.
Krishnan, "A Framework for Multicast in Network Krishnan, "A Framework for Multicast in Network
Virtualization over Layer 3", RFC 8293, Virtualization over Layer 3", RFC 8293,
DOI 10.17487/RFC8293, January 2018, DOI 10.17487/RFC8293, January 2018,
<https://www.rfc-editor.org/info/rfc8293>. <https://www.rfc-editor.org/info/rfc8293>.
[VL2] Greenberg, A., et al., "VL2: A Scalable and Flexible Data [VL2] "VL2: A Scalable and Flexible Data Center Network", ACM
Center Network", ACM SIGCOMM Computer Communication SIGCOMM Computer Communication Review,
Review, DOI 10.1145/1594977.1592576, 2009, DOI 10.1145/1594977.1592576, 2009,
<http://www.sigcomm.org/sites/default/files/ccr/ <http://www.sigcomm.org/sites/default/files/ccr/
papers/2009/October/1594977-1592576.pdf>. papers/2009/October/1594977-1592576.pdf>.
Authors' Addresses Authors' Addresses
Jesse Gross (editor) Jesse Gross (editor)
Email: jesse@kernel.org Email: jesse@kernel.org
Ilango Ganga (editor) Ilango Ganga (editor)
 End of changes. 29 change blocks. 
63 lines changed or deleted 69 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/