draft-ietf-nvo3-geneve-05.txt   draft-ietf-nvo3-geneve-06.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 17, 2018 Intel Expires: September 6, 2018 Intel
T. Sridhar, Ed. T. Sridhar, Ed.
VMware VMware
September 13, 2017 March 05, 2018
Geneve: Generic Network Virtualization Encapsulation Geneve: Generic Network Virtualization Encapsulation
draft-ietf-nvo3-geneve-05 draft-ietf-nvo3-geneve-06
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 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 March 17, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
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 3, line 13 skipping to change at page 3, line 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 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], often leads to questions about the
leads to questions about the need for new encapsulation formats and need for new encapsulation formats and what it is about network
what it is about network virtualization in particular that leads to virtualization in particular that leads to their proliferation.
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.
skipping to change at page 15, line 47 skipping to change at page 15, line 47
comprised of a forwarding ASIC and a general purpose CPU, this comprised of a forwarding ASIC and a general purpose CPU, this
does not mean that the packet must be dropped in the ASIC. An does not mean that the packet must be dropped in the ASIC. An
implementation may send the packet to the CPU using a rate-limited implementation may send the packet to the CPU using a rate-limited
control channel for slow-path exception handling. control channel for slow-path exception handling.
R (3 bits): Option control flags reserved for future use. MUST be R (3 bits): Option control flags reserved for future use. MUST be
zero on transmission and ignored on receipt. zero on transmission and ignored on receipt.
Length (5 bits): Length of the option, expressed in four byte Length (5 bits): Length of the option, expressed in four byte
multiples excluding the option header. The total length of each multiples excluding the option header. The total length of each
option may be between 4 and 128 bytes. Packets in which the total option may be between 4 and 128 bytes. A value of 0 in the Length
length of all options is not equal to the 'Opt Len' in the base field implies an option with only the option header without the
header are invalid and MUST be silently dropped if received by an variable option data. Packets in which the total length of all
endpoint. options is not equal to the 'Opt Len' in the base header are
invalid and MUST be silently dropped if received by an endpoint.
Variable Option Data: Option data interpreted according to 'Type'. Variable Option Data: Option data interpreted according to 'Type'.
3.5.1. Options Processing 3.5.1. Options Processing
Geneve options are primarily intended to be originated and processed Geneve options are primarily intended to be originated and processed
by tunnel endpoints. However, options MAY be processed by transit by tunnel endpoints. However, options MAY be processed by transit
devices along the tunnel path as well. Transit devices not devices along the tunnel path as well. Transit devices not
processing Geneve headers SHOULD process Geneve packets as any other processing Geneve headers SHOULD process Geneve packets as any other
UDP packet and maintain consistent forwarding behavior. UDP packet and maintain consistent forwarding behavior.
skipping to change at page 21, line 5 skipping to change at page 21, line 5
the data format. the data format.
5. Interoperability Issues 5. Interoperability Issues
Viewed exclusively from the data plane, Geneve does not introduce any Viewed exclusively from the data plane, Geneve does not introduce any
interoperability issues as it appears to most devices as UDP packets. interoperability issues as it appears to most devices as UDP packets.
However, as there are already a number of tunnel protocols deployed However, as there are already a number of tunnel protocols deployed
in network virtualization environments, there is a practical question in network virtualization environments, there is a practical question
of transition and coexistence. of transition and coexistence.
Since Geneve is a superset of the functionality of the three most Since Geneve is a superset of the functionality of the most common
common protocols used for network virtualization (VXLAN, NVGRE, and protocols used for network virtualization (VXLAN, NVGRE ) it should
STT) it should be straightforward to port an existing control plane be straightforward to port an existing control plane to run on top of
to run on top of it with minimal effort. With both the old and new it with minimal effort. With both the old and new packet formats
packet formats supporting the same set of capabilities, there is no supporting the same set of capabilities, there is no need for a hard
need for a hard transition - endpoints directly communicating with transition - endpoints directly communicating with each other use any
each other use any common protocol, which may be different even common protocol, which may be different even within a single overall
within a single overall system. As transit devices are primarily system. As transit devices are primarily forwarding packets on the
forwarding packets on the basis of the IP header, all protocols basis of the IP header, all protocols appear similar and these
appear similar and these devices do not introduce additional devices do not introduce additional interoperability concerns.
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 UDP/IP packets, Geneve does not have any inherent security As UDP/IP packets, Geneve does not have any inherent security
skipping to change at page 23, line 39 skipping to change at page 23, line 39
Dinesh G. Dutt Dinesh G. Dutt
Cumulus Networks Cumulus Networks
140C S. Whisman Road 140C S. Whisman Road
Mountain View, CA 94041 Mountain View, CA 94041
USA USA
Email: ddutt@cumulusnetworks.com Email: ddutt@cumulusnetworks.com
Jon Hudson Jon Hudson
Brocade Communications Systems, Inc. Independent
130 Holger Way
San Jose, CA 95134
USA
Email: jon.hudson@gmail.com Email: jon.hudson@gmail.com
Ariel Hendel Ariel Hendel
Broadcom Limited Broadcom Limited
3151 Zanker Road 3151 Zanker Road
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: ariel.hendel@broadcom.com Email: ariel.hendel@broadcom.com
9. Acknowledgements 9. Acknowledgements
The authors wish to thank Martin Casado, Bruce Davie and Dave Thaler The authors wish to thank Martin Casado, Bruce Davie and Dave Thaler
for their input, feedback, and helpful suggestions. for their input, feedback, and helpful suggestions.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 24, line 35 skipping to change at page 24, line 34
IANA Considerations Section in RFCs", RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc5226>.
10.2. Informative References 10.2. Informative References
[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]
Davie, B. and J. Gross, "A Stateless Transport Tunneling
Protocol for Network Virtualization (STT)", draft-davie-
stt-08 (work in progress), April 2016.
[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.
[I-D.ietf-nvo3-encap] [I-D.ietf-nvo3-encap]
Boutros, S., Ganga, I., Garg, P., Manur, R., Mizrahi, T., Boutros, S., Ganga, I., Garg, P., Manur, R., Mizrahi, T.,
Mozes, D., and E. Nordmark, "NVO3 Encapsulation Mozes, D., Nordmark, E., Smith, M., Aldrin, S., and I.
Considerations", draft-ietf-nvo3-encap-00 (work in Bagdonas, "NVO3 Encapsulation Considerations", draft-ietf-
progress), June 2017. nvo3-encap-01 (work in progress), October 2017.
[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 802.1Q-2014, networks--Bridges and Bridged Networks", IEEE 802.1Q-2014,
DOI 10.1109/ieeestd.2014.6991462, December 2014, DOI 10.1109/ieeestd.2014.6991462, December 2014,
<http://ieeexplore.ieee.org/servlet/ <http://ieeexplore.ieee.org/servlet/
opac?punumber=6991460>. opac?punumber=6991460>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
 End of changes. 12 change blocks. 
36 lines changed or deleted 28 lines changed or added

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