draft-ietf-nvo3-geneve-03.txt   draft-ietf-nvo3-geneve-04.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: March 24, 2017 Intel Expires: September 14, 2017 Intel
T. Sridhar, Ed. T. Sridhar, Ed.
VMware VMware
September 20, 2016 March 13, 2017
Geneve: Generic Network Virtualization Encapsulation Geneve: Generic Network Virtualization Encapsulation
draft-ietf-nvo3-geneve-03 draft-ietf-nvo3-geneve-04
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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 March 24, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 36 skipping to change at page 2, line 36
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. Encapsulation of Geneve in IP . . . . . . . . . . . . . . 17 4.1. Encapsulation of Geneve in IP . . . . . . . . . . . . . . 17
4.1.1. IP Fragmentation . . . . . . . . . . . . . . . . . . 17 4.1.1. IP Fragmentation . . . . . . . . . . . . . . . . . . 17
4.1.2. DSCP and ECN . . . . . . . . . . . . . . . . . . . . 17 4.1.2. DSCP and ECN . . . . . . . . . . . . . . . . . . . . 17
4.1.3. Broadcast and Multicast . . . . . . . . . . . . . . . 18 4.1.3. Broadcast and Multicast . . . . . . . . . . . . . . . 18
4.1.4. Unidirectional Tunnels . . . . . . . . . . . . . . . 18 4.1.4. Unidirectional Tunnels . . . . . . . . . . . . . . . 18
4.2. Constraints on Protocol Features . . . . . . . . . . . . 19 4.2. Constraints on Protocol Features . . . . . . . . . . . . 19
4.2.1. Constraints on Options . . . . . . . . . . . . . . . 19
4.3. NIC Offloads . . . . . . . . . . . . . . . . . . . . . . 19 4.3. NIC Offloads . . . . . . . . . . . . . . . . . . . . . . 19
4.4. Inner VLAN Handling . . . . . . . . . . . . . . . . . . . 20 4.4. Inner VLAN Handling . . . . . . . . . . . . . . . . . . . 20
5. Interoperability Issues . . . . . . . . . . . . . . . . . . . 20 5. Interoperability Issues . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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], and STT [I-D.davie-stt], often VXLAN [RFC7348], NVGRE [RFC7637], and STT [I-D.davie-stt], often
skipping to change at page 19, line 23 skipping to change at page 19, line 23
handle certain encapsulated payload types, such as Ethernet or IP. handle certain encapsulated payload types, such as Ethernet or IP.
This could be either globally throughout the system or, for example, This could be either globally throughout the system or, for example,
restricted to certain classes of devices or network paths. restricted to certain classes of devices or network paths.
These constraints may be communicated to tunnel endpoints either These constraints may be communicated to tunnel endpoints either
explicitly through a control plane or implicitly by the nature of the explicitly through a control plane or implicitly by the nature of the
application. As Geneve is defined as a data plane protocol that is application. As Geneve is defined as a data plane protocol that is
control plane agnostic, the exact mechanism is not defined in this control plane agnostic, the exact mechanism is not defined in this
document. document.
4.2.1. Constraints on Options
While Geneve options are more flexible, a control plane may restrict
the number of option TLVs as well as the order and size of the TLVs,
between tunnel endpoints, to make it simpler for a data plane
implementation in software or hardware to handle [I-D.dt-nvo3-encap].
For example, there may be some critical information such as a secure
hash that must be processed in a certain order to provide lowest
latency.
A control plane may negotiate a subset of option TLVs and certain TLV
ordering, as well may limit the total number of option TLVs present
in the packet, for example, to accommodate hardware capable of
processing fewer options [I-D.dt-nvo3-encap]. Hence, a control plane
needs to have the ability to describe the supported TLVs subset and
their order to the tunnel end points. In the absence of a control
plane, alternative configuration mechanisms may be used for this
purpose. The exact mechanism is not defined in this document.
4.3. NIC Offloads 4.3. NIC Offloads
Modern NICs currently provide a variety of offloads to enable the Modern NICs currently provide a variety of offloads to enable the
efficient processing of packets. The implementation of many of these efficient processing of packets. The implementation of many of these
offloads requires only that the encapsulated packet be easily parsed offloads requires only that the encapsulated packet be easily parsed
(for example, checksum offload). However, optimizations such as LSO (for example, checksum offload). However, optimizations such as LSO
and LRO involve some processing of the options themselves since they and LRO involve some processing of the options themselves since they
must be replicated/merged across multiple packets. In these must be replicated/merged across multiple packets. In these
situations, it is desirable to not require changes to the offload situations, it is desirable to not require changes to the offload
logic to handle the introduction of new options. To enable this, logic to handle the introduction of new options. To enable this,
skipping to change at page 24, line 26 skipping to change at page 24, line 46
[ETYPES] The IEEE Registration Authority, "IEEE 802 Numbers", 2013, [ETYPES] The IEEE Registration Authority, "IEEE 802 Numbers", 2013,
<http://www.iana.org/assignments/ieee-802-numbers/ <http://www.iana.org/assignments/ieee-802-numbers/
ieee-802-numbers.xml>. ieee-802-numbers.xml>.
[I-D.davie-stt] [I-D.davie-stt]
Davie, B. and J. Gross, "A Stateless Transport Tunneling Davie, B. and J. Gross, "A Stateless Transport Tunneling
Protocol for Network Virtualization (STT)", draft-davie- Protocol for Network Virtualization (STT)", draft-davie-
stt-08 (work in progress), April 2016. stt-08 (work in progress), April 2016.
[I-D.dt-nvo3-encap]
Boutros, S., Aldrin, S., Elzur, U., Ganga, I., Manur, R.,
Mozes, D., and M. Smith, "NVO3 Encapsulation
Considerations", draft-dt-nvo3-encap-01 (work in
progress), March 2017.
[I-D.ietf-nvo3-dataplane-requirements] [I-D.ietf-nvo3-dataplane-requirements]
Bitar, N., Lasserre, M., Balus, F., Morin, T., Jin, L., Bitar, N., Lasserre, M., Balus, F., Morin, T., Jin, L.,
and B. Khasnabish, "NVO3 Data Plane Requirements", draft- and B. Khasnabish, "NVO3 Data Plane Requirements", draft-
ietf-nvo3-dataplane-requirements-03 (work in progress), ietf-nvo3-dataplane-requirements-03 (work in progress),
April 2014. April 2014.
[IEEE.802.1Q-2014] [IEEE.802.1Q-2014]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks -- Bridges and Bridged Networks", IEEE networks -- Bridges and Bridged Networks", IEEE
Std 802.1Q, 2014. Std 802.1Q, 2014.
 End of changes. 11 change blocks. 
10 lines changed or deleted 36 lines changed or added

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