draft-ietf-nvo3-geneve-04.txt   draft-ietf-nvo3-geneve-05.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: September 14, 2017 Intel Expires: March 17, 2018 Intel
T. Sridhar, Ed. T. Sridhar, Ed.
VMware VMware
March 13, 2017 September 13, 2017
Geneve: Generic Network Virtualization Encapsulation Geneve: Generic Network Virtualization Encapsulation
draft-ietf-nvo3-geneve-04 draft-ietf-nvo3-geneve-05
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 34 skipping to change at page 1, line 34
recognize and accommodate these changing capabilities and needs. 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 http://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 September 14, 2017. This Internet-Draft will expire on March 17, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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 (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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 3, line 12 skipping to change at page 3, line 12
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 24
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], and STT [I-D.davie-stt], often
leads to questions about the need for new encapsulation formats and leads to questions about the need for new encapsulation formats and
what it is about network virtualization in particular that leads to what it is about network 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.
Current work such as [VL2] and the NVO3 working group Current work such as VL2 [VL2] and the NVO3 working group
[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 9, line 19 skipping to change at page 9, line 19
header provides control information plus a base level of header provides control information plus a base level of
functionality and interoperability with a focus on simplicity. This functionality and interoperability with a focus on simplicity. This
header is then followed by a set of variable options to allow for header is then followed by a set of variable options to allow for
future innovation. Finally, the payload consists of a protocol data future innovation. Finally, the payload consists of a protocol data
unit of the indicated type, such as an Ethernet frame. Section 3.1 unit of the indicated type, such as an Ethernet frame. Section 3.1
and Section 3.2 illustrate the Geneve packet format transported (for and Section 3.2 illustrate the Geneve packet format transported (for
example) over Ethernet along with an Ethernet payload. example) over Ethernet along with an Ethernet payload.
3.1. Geneve Packet Format Over IPv4 3.1. Geneve Packet Format Over IPv4
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Outer Ethernet Header: Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | | Outer Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | Outer Source MAC Address | | Outer Destination MAC Address | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source MAC Address | | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Optional Ethertype=C-Tag 802.1Q| Outer VLAN Tag Information | |Optional Ethertype=C-Tag 802.1Q| Outer VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 4 skipping to change at page 10, line 40
| | | |
| (Note that the original Ethernet Frame's FCS is not included) | | (Note that the original Ethernet Frame's FCS is not included) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame Check Sequence: Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New FCS (Frame Check Sequence) for Outer Ethernet Frame | | New FCS (Frame Check Sequence) for Outer Ethernet Frame |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2. Geneve Packet Format Over IPv6 3.2. Geneve Packet Format Over IPv6
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Outer Ethernet Header: Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | | Outer Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | Outer Source MAC Address | | Outer Destination MAC Address | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source MAC Address | | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Optional Ethertype=C-Tag 802.1Q| Outer VLAN Tag Information | |Optional Ethertype=C-Tag 802.1Q| Outer VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 17 skipping to change at page 14, line 5
C (1 bit): Critical options present. One or more options has the C (1 bit): Critical options present. One or more options has the
critical bit set (see Section 3.5). If this bit is set then critical bit set (see Section 3.5). If this bit is set then
tunnel endpoints MUST parse the options list to interpret any tunnel endpoints MUST parse the options list to interpret any
critical options. On endpoints where option parsing is not critical options. On endpoints where option parsing is not
supported the packet MUST be dropped on the basis of the 'C' bit supported the packet MUST be dropped on the basis of the 'C' bit
in the base header. If the bit is not set tunnel endpoints MAY in the base header. If the bit is not set tunnel endpoints MAY
strip all options using 'Opt Len' and forward the decapsulated strip all options using 'Opt Len' and forward the decapsulated
packet. Transit devices MUST NOT drop or modify packets on the packet. Transit devices MUST NOT drop or modify packets on the
basis of this bit. basis of this bit.
The critical bit allows hardware implementations the flexibility
to handle options processing in the hardware fastpath or in the
exception (slow) path without the need to process all the options.
For example, a critical option such as secure hash to provide
Geneve header integrity check must be processed by tunnel
endpoints and typically processed in the hardware fastpath.
Rsvd. (6 bits): Reserved field which MUST be zero on transmission Rsvd. (6 bits): Reserved field which MUST be zero on transmission
and ignored on receipt. and ignored on receipt.
Protocol Type (16 bits): The type of the protocol data unit Protocol Type (16 bits): The type of the protocol data unit
appearing after the Geneve header. This follows the EtherType appearing after the Geneve header. This follows the EtherType
[ETYPES] convention with Ethernet itself being represented by the [ETYPES] convention with Ethernet itself being represented by the
value 0x6558. value 0x6558.
Virtual Network Identifier (VNI) (24 bits): An identifier for a Virtual Network Identifier (VNI) (24 bits): An identifier for a
unique element of a virtual network. In many situations this may unique element of a virtual network. In many situations this may
skipping to change at page 17, line 33 skipping to change at page 17, line 30
tunnel headers. Manual or upper layer (such as TCP MSS clamping) tunnel headers. Manual or upper layer (such as TCP MSS clamping)
configuration can be used to ensure that fragmentation never takes configuration can be used to ensure that fragmentation never takes
place, however, in some situations this may not be feasible. place, however, in some situations this may not be feasible.
It is strongly RECOMMENDED that Path MTU Discovery ([RFC1191], It is strongly RECOMMENDED that Path MTU Discovery ([RFC1191],
[RFC1981]) be used by setting the DF bit in the IP header when Geneve [RFC1981]) be used by setting the DF bit in the IP header when Geneve
packets are transmitted over IPv4 (this is the default with IPv6). packets are transmitted over IPv4 (this is the default with IPv6).
The use of Path MTU Discovery on the transit network provides the The use of Path MTU Discovery on the transit network provides the
encapsulating endpoint with soft-state about the link that it may use encapsulating endpoint with soft-state about the link that it may use
to prevent or minimize fragmentation depending on its role in the to prevent or minimize fragmentation depending on its role in the
virtualized network. virtualized network. For example, recommendations/guidance for
handling fragmenation in similar overlay encapsulation services like
PWE3 are provided in section 5.3 of [RFC3985].
Note that some implementations may not be capable of supporting Note that some implementations may not be capable of supporting
fragmentation or other less common features of the IP header, such as fragmentation or other less common features of the IP header, such as
options and extension headers. options and extension headers.
4.1.2. DSCP and ECN 4.1.2. DSCP and ECN
When encapsulating IP (including over Ethernet) packets in Geneve, When encapsulating IP (including over Ethernet) packets in Geneve,
there are several considerations for propagating DSCP and ECN bits there are several considerations for propagating DSCP and ECN bits
from the inner header to the tunnel on transmission and the reverse from the inner header to the tunnel on transmission and the reverse
skipping to change at page 19, line 28 skipping to change at page 19, line 28
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 4.2.1. Constraints on Options
While Geneve options are more flexible, a control plane may restrict 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, 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 between tunnel endpoints, to make it simpler for a data plane
implementation in software or hardware to handle [I-D.dt-nvo3-encap]. implementation in software or hardware to handle
For example, there may be some critical information such as a secure [I-D.ietf-nvo3-encap]. For example, there may be some critical
hash that must be processed in a certain order to provide lowest information such as a secure hash that must be processed in a certain
latency. order to provide lowest latency.
A control plane may negotiate a subset of option TLVs and certain TLV 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 ordering, as well may limit the total number of option TLVs present
in the packet, for example, to accommodate hardware capable of in the packet, for example, to accommodate hardware capable of
processing fewer options [I-D.dt-nvo3-encap]. Hence, a control plane processing fewer options [I-D.ietf-nvo3-encap]. Hence, a control
needs to have the ability to describe the supported TLVs subset and plane needs to have the ability to describe the supported TLVs subset
their order to the tunnel end points. In the absence of a control and their order to the tunnel end points. In the absence of a
plane, alternative configuration mechanisms may be used for this control plane, alternative configuration mechanisms may be used for
purpose. The exact mechanism is not defined in this document. 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
skipping to change at page 24, line 23 skipping to change at page 24, line 17
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
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://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] [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] [I-D.ietf-nvo3-encap]
Boutros, S., Ganga, I., Garg, P., Manur, R., Mizrahi, T.,
Mozes, D., and E. Nordmark, "NVO3 Encapsulation
Considerations", draft-ietf-nvo3-encap-00 (work in
progress), June 2017.
[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 802.1Q-2014,
Std 802.1Q, 2014. DOI 10.1109/ieeestd.2014.6991462, December 2014,
<http://ieeexplore.ieee.org/servlet/
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,
<http://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <http://www.rfc-editor.org/info/rfc1981>. 1996, <https://www.rfc-editor.org/info/rfc1981>.
[RFC2983] Black, D., "Differentiated Services and Tunnels", [RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, DOI 10.17487/RFC2983, October 2000, RFC 2983, DOI 10.17487/RFC2983, October 2000,
<http://www.rfc-editor.org/info/rfc2983>. <https://www.rfc-editor.org/info/rfc2983>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005,
<https://www.rfc-editor.org/info/rfc3985>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <http://www.rfc-editor.org/info/rfc6040>. 2010, <https://www.rfc-editor.org/info/rfc6040>.
[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,
<http://www.rfc-editor.org/info/rfc6935>. <https://www.rfc-editor.org/info/rfc6935>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<http://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for Data Center (DC) Network Rekhter, "Framework for Data Center (DC) Network
Virtualization", RFC 7365, DOI 10.17487/RFC7365, October Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
2014, <http://www.rfc-editor.org/info/rfc7365>. 2014, <https://www.rfc-editor.org/info/rfc7365>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
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,
<http://www.rfc-editor.org/info/rfc7637>. <https://www.rfc-editor.org/info/rfc7637>.
[VL2] Greenberg et al, , "VL2: A Scalable and Flexible Data
Center Network", 2009.
Proc. ACM SIGCOMM 2009 [VL2] Greenberg, A., et al., "VL2: A Scalable and Flexible Data
Center Network", ACM SIGCOMM Computer Communication
Review, DOI 10.1145/1594977.1592576, 2009,
<http://www.sigcomm.org/sites/default/files/ccr/
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)
Intel Corporation Intel Corporation
2200 Mission College Blvd. 2200 Mission College Blvd.
 End of changes. 33 change blocks. 
50 lines changed or deleted 66 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/