< draft-mahalingam-dutt-dcops-vxlan-08.txt   draft-mahalingam-dutt-dcops-vxlan-09.txt >
Internet Engineering Task Force M. Mahalingam Internet Engineering Task Force M. Mahalingam
Internet Draft Storvisor Internet Draft Storvisor
Intended Status: Experimental D. Dutt Intended Status: Informational D. Dutt
Expires: August 3, 2014 Cumulus Networks Expires: October 10, 2014 Cumulus Networks
K. Duda K. Duda
Arista Arista
P. Agarwal P. Agarwal
Broadcom Broadcom
L. Kreeger L. Kreeger
Cisco Cisco
T. Sridhar T. Sridhar
VMware VMware
M. Bursell M. Bursell
Citrix Citrix
C. Wright C. Wright
Red Hat Red Hat
February 3, 2014 April 10, 2014
VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over
Layer 3 Networks Layer 3 Networks
draft-mahalingam-dutt-dcops-vxlan-08.txt draft-mahalingam-dutt-dcops-vxlan-09.txt
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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 8, 2013. This Internet-Draft will expire on October 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 carefully, as they describe your rights and restrictions with
respect to this document. respect to this document.
Abstract Abstract
This document describes Virtual eXtensible Local Area Network This document describes Virtual eXtensible Local Area Network
(VXLAN), which is used to address the need for overlay networks (VXLAN), which is used to address the need for overlay networks
within virtualized data centers accommodating multiple tenants. The within virtualized data centers accommodating multiple tenants. The
scheme and the related protocols can be used in cloud service scheme and the related protocols can be used in cloud service
provider and enterprise data center networks. This memo documents the provider and enterprise data center networks. This memo documents the
deployed VXLAN protocol for the benefit of the IETF community. The deployed VXLAN protocol for the benefit of the IETF community.
IETF consensus on this RFC represents consensus to publish this memo,
and not consensus on the text itself.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Acronyms & Definitions....................................4 1.1. Acronyms & Definitions....................................4
2. Conventions used in this document..............................5 2. Conventions used in this document..............................5
3. VXLAN Problem Statement........................................5 3. VXLAN Problem Statement........................................5
3.1. Limitations imposed by Spanning Tree & VLAN Ranges........5 3.1. Limitations imposed by Spanning Tree & VLAN Ranges........5
3.2. Multitenant Environments..................................6 3.2. Multitenant Environments..................................6
3.3. Inadequate Table Sizes at ToR Switch......................7 3.3. Inadequate Table Sizes at ToR Switch......................6
4. Virtual eXtensible Local Area Network (VXLAN)..................7 4. Virtual eXtensible Local Area Network (VXLAN)..................7
4.1. Unicast VM to VM communication............................8 4.1. Unicast VM to VM communication............................8
4.2. Broadcast Communication and Mapping to Multicast..........9 4.2. Broadcast Communication and Mapping to Multicast..........9
4.3. Physical Infrastructure Requirements.....................10 4.3. Physical Infrastructure Requirements.....................10
5. VXLAN Frame Format............................................11 5. VXLAN Frame Format............................................10
6. VXLAN Deployment Scenarios....................................16 6. VXLAN Deployment Scenarios....................................16
6.1. Inner VLAN Tag Handling..................................19 6.1. Inner VLAN Tag Handling..................................19
7. Security Considerations.......................................19 7. Security Considerations.......................................19
8. IANA Considerations...........................................21 8. IANA Considerations...........................................21
9. References....................................................21 9. References....................................................21
9.1. Normative References.....................................21 9.1. Normative References.....................................21
9.2. Informative References...................................21 9.2. Informative References...................................21
10. Acknowledgments..............................................22 10. Acknowledgments..............................................22
1. Introduction 1. Introduction
Server virtualization has placed increased demands on the physical Server virtualization has placed increased demands on the physical
network infrastructure. A physical server now has multiple virtual network infrastructure. A physical server now has multiple virtual
machines (VMs) each with its own MAC address. This requires larger machines (VMs) each with its own MAC address. This requires larger
MAC address tables in the switched Ethernet network due to potential MAC address tables in the switched Ethernet network due to potential
attachment of and communication among hundreds of thousands of VMs. attachment of and communication among hundreds of thousands of VMs.
In the case when the VMs in a data center are grouped according to In the case when the VMs in a data center are grouped according to
their Virtual LAN (VLAN, one might need thousands of VLANs to their Virtual LAN (VLAN, one might need thousands of VLANs to
partition the traffic according to the specific group that the VM partition the traffic according to the specific group that the VM
may belong to. The current VLAN limit of 4094 is inadequate in such may belong to. The current VLAN limit of 4094 is inadequate in such
situations. situations.
Another type of demand that is being placed on data centers is the Data centers are often required to host multiple tenants, each with
need to host multiple tenants, each with their own isolated network their own isolated network domain. Since it is not economical to
domain. This is not economical to realize with dedicated realize this with dedicated infrastructure, network administrators
infrastructure, so network administrators opt to implement this over opt to implement isolation over a shared network. In such scenarios,
a shared network. A common problem is that each tenant may a common problem is that each tenant may independently assign MAC
independently assign MAC addresses and VLAN IDs leading to potential addresses and VLAN IDs leading to potential duplication of these on
duplication of these on the physical network. the physical network.
Another requirement for virtualized environments using a Layer 2 An important requirement for virtualized environments using a Layer
physical infrastructure is having the Layer 2 network scale across 2 physical infrastructure is having the Layer 2 network scale across
the entire data center or even between data centers for efficient the entire data center or even between data centers for efficient
allocation of compute, network and storage resources. In such allocation of compute, network and storage resources. In such
networks, using traditional approaches like the Spanning Tree networks, using traditional approaches like the Spanning Tree
Protocol (STP) for a loop free topology can result in a large number Protocol (STP) for a loop free topology can result in a large number
of disabled links. of disabled links.
The last scenario is the case where the network operator prefers to The last scenario is the case where the network operator prefers to
use IP for interconnection of the physical infrastructure (e.g. to use IP for interconnection of the physical infrastructure (e.g. to
achieve multipath scalability through Equal Cost Multipath (ECMP), achieve multipath scalability through Equal Cost Multipath (ECMP),
thus avoiding disabled links). Even in such environments, there is a thus avoiding disabled links). Even in such environments, there is a
need to preserve the Layer 2 model for inter-VM communication. need to preserve the Layer 2 model for inter-VM communication.
The scenarios described above lead to a requirement for an overlay The scenarios described above lead to a requirement for an overlay
network. This overlay is used to carry the MAC traffic from the network. This overlay is used to carry the MAC traffic from the
individual VMs in an encapsulated format over a logical "tunnel". individual VMs in an encapsulated format over a logical "tunnel".
This document details a framework termed Virtual eXtensible Local This document details a framework termed Virtual eXtensible Local
Area Network (VXLAN) which provides such an encapsulation scheme to Area Network (VXLAN) which provides such an encapsulation scheme to
address the various requirements specified above. This memo address the various requirements specified above. This memo
documents the deployed VXLAN protocol for the benefit of the IETF documents the deployed VXLAN protocol for the benefit of the IETF
community. The IETF consensus on this RFC represents consensus to community.
publish this memo, and not consensus on the text itself.
1.1. Acronyms & Definitions 1.1. Acronyms & Definitions
ACL - Access Control List ACL - Access Control List
ECMP - Equal Cost Multipath ECMP - Equal Cost Multipath
IGMP - Internet Group Management Protocol IGMP - Internet Group Management Protocol
MTU - Maximum Transmission Unit MTU - Maximum Transmission Unit
skipping to change at page 4, line 42 skipping to change at page 4, line 37
ToR - Top of Rack ToR - Top of Rack
TRILL - Transparent Interconnection of Lots of Links TRILL - Transparent Interconnection of Lots of Links
VXLAN - Virtual eXtensible Local Area Network VXLAN - Virtual eXtensible Local Area Network
VXLAN Segment - VXLAN Layer 2 overlay network over which VMs VXLAN Segment - VXLAN Layer 2 overlay network over which VMs
communicate communicate
VXLAN Overlay Network - another term for VXLAN Segment VXLAN Overlay Network - VXLAN Segment
VXLAN Gateway - an entity which forwards traffic between VXLAN VXLAN Gateway - an entity which forwards traffic between VXLAN
and non-VXLAN environments and non-VXLAN environments
VTEP - VXLAN Tunnel End Point - an entity which originates VTEP - VXLAN Tunnel End Point - an entity which originates
and/or terminates VXLAN tunnels and/or terminates VXLAN tunnels
VLAN - Virtual Local Area Network VLAN - Virtual Local Area Network
VM - Virtual Machine VM - Virtual Machine
VNI - VXLAN Network Identifier (or VXLAN Segment ID) VNI - VXLAN Network Identifier (or VXLAN Segment ID)
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
skipping to change at page 5, line 43 skipping to change at page 5, line 37
more ports and links than they can really use. In addition, more ports and links than they can really use. In addition,
resiliency due to multipathing is not available with the STP model. resiliency due to multipathing is not available with the STP model.
Newer initiatives such as TRILL [RFC6325] and SPB[802.1aq]) have Newer initiatives such as TRILL [RFC6325] and SPB[802.1aq]) have
been proposed to help with multipathing and thus surmount some of been proposed to help with multipathing and thus surmount some of
the problems with STP. STP limitations may also be avoided by the problems with STP. STP limitations may also be avoided by
configuring servers within a rack to be on the same Layer 3 network configuring servers within a rack to be on the same Layer 3 network
with switching happening at Layer 3 both within the rack and between with switching happening at Layer 3 both within the rack and between
racks. However, this is incompatible with a Layer 2 model for inter- racks. However, this is incompatible with a Layer 2 model for inter-
VM communication. VM communication.
Another characteristic of Layer 2 data center networks is their use A key characteristic of Layer 2 data center networks is their use of
of Virtual LANs (VLANs) to provide broadcast isolation. A 12 bit Virtual LANs (VLANs) to provide broadcast isolation. A 12 bit VLAN
VLAN ID is used in the Ethernet data frames to divide the larger ID is used in the Ethernet data frames to divide the larger Layer 2
Layer 2 network into multiple broadcast domains. This has served network into multiple broadcast domains. This has served well for
well for several data centers which require fewer than 4094 VLANs. several data centers which require fewer than 4094 VLANs. With the
With the growing adoption of virtualization, this upper limit is growing adoption of virtualization, this upper limit is seeing
seeing pressure. Moreover, due to STP, several data centers limit pressure. Moreover, due to STP, several data centers limit the
the number of VLANs that could be used. In addition, requirements number of VLANs that could be used. In addition, requirements for
for multitenant environments accelerate the need for larger VLAN multitenant environments accelerate the need for larger VLAN limits,
limits, as discussed in Section 3.3. as discussed in Section 3.3.
3.2. Multitenant Environments 3.2. Multitenant Environments
Cloud computing involves on demand elastic provisioning of resources Cloud computing involves on demand elastic provisioning of resources
for multi-tenant environments. The most common example of cloud for multi-tenant environments. The most common example of cloud
computing is the public cloud, where a cloud service provider offers computing is the public cloud, where a cloud service provider offers
these elastic services to multiple customers/tenants over the same these elastic services to multiple customers/tenants over the same
physical infrastructure. physical infrastructure.
Isolation of network traffic by tenant could be done via Layer 2 or Isolation of network traffic by tenant could be done via Layer 2 or
Layer 3 networks. For Layer 2 networks, VLANs are often used to Layer 3 networks. For Layer 2 networks, VLANs are often used to
segregate traffic - so a tenant could be identified by its own VLAN, segregate traffic - so a tenant could be identified by its own VLAN,
for example. Due to the large number of tenants that a cloud for example. Due to the large number of tenants that a cloud
provider might service, the 4094 VLAN limit is often inadequate. In provider might service, the 4094 VLAN limit is often inadequate. In
addition, there is often a need for multiple VLANs per tenant, which addition, there is often a need for multiple VLANs per tenant, which
exacerbates the issue. exacerbates the issue.
Another use case is cross pod expansion. A pod typically consists of A related use case is cross pod expansion. A pod typically consists
one or more racks of servers with associated network and storage of one or more racks of servers with associated network and storage
connectivity. Tenants may start off on a pod and, due to expansion, connectivity. Tenants may start off on a pod and, due to expansion,
require servers/VMs on other pods, especially in the case when require servers/VMs on other pods, especially in the case when
tenants on the other pods are not fully utilizing all their tenants on the other pods are not fully utilizing all their
resources. This use case requires a "stretched" Layer 2 environment resources. This use case requires a "stretched" Layer 2 environment
connecting the individual servers/VMs. connecting the individual servers/VMs.
Layer 3 networks are not a comprehensive solution for multi tenancy Layer 3 networks are not a comprehensive solution for multi tenancy
either. Two tenants might use the same set of Layer 3 addresses either. Two tenants might use the same set of Layer 3 addresses
within their networks which requires the cloud provider to provide within their networks which requires the cloud provider to provide
isolation in some other form. Further, requiring all tenants to use isolation in some other form. Further, requiring all tenants to use
skipping to change at page 10, line 19 skipping to change at page 10, line 7
packets, a protocol like PIM-bidir (see [RFC5015]) would be more packets, a protocol like PIM-bidir (see [RFC5015]) would be more
efficient. efficient.
The destination VM sends a standard ARP response using IP unicast. The destination VM sends a standard ARP response using IP unicast.
This frame will be encapsulated back to the VTEP connecting the This frame will be encapsulated back to the VTEP connecting the
originating VM using IP unicast VXLAN encapsulation. This is originating VM using IP unicast VXLAN encapsulation. This is
possible since the mapping of the ARP response's destination MAC to possible since the mapping of the ARP response's destination MAC to
the VXLAN tunnel end point IP was learned earlier through the ARP the VXLAN tunnel end point IP was learned earlier through the ARP
request. request.
Another point to note is that multicast frames and "unknown MAC Note that multicast frames and "unknown MAC destination" frames are
destination" frames are also sent using the multicast tree, similar also sent using the multicast tree, similar to the broadcast frames.
to the broadcast frames.
4.3. Physical Infrastructure Requirements 4.3. Physical Infrastructure Requirements
When IP multicast is used within the network infrastructure, a When IP multicast is used within the network infrastructure, a
multicast routing protocol like PIM-SM can be used by the individual multicast routing protocol like PIM-SM can be used by the individual
Layer 3 IP routers/switches within the network. This is used to Layer 3 IP routers/switches within the network. This is used to
build efficient multicast forwarding trees so that multicast frames build efficient multicast forwarding trees so that multicast frames
are only sent to those hosts which have requested to receive them. are only sent to those hosts which have requested to receive them.
Similarly, there is no requirement that the actual network Similarly, there is no requirement that the actual network
connecting the source VM and destination VM should be a Layer 3 connecting the source VM and destination VM should be a Layer 3
network - VXLAN can also work over Layer 2 networks. In either case, network - VXLAN can also work over Layer 2 networks. In either case,
efficient multicast replication within the Layer 2 network can be efficient multicast replication within the Layer 2 network can be
achieved using IGMP snooping. achieved using IGMP snooping.
VTEPs MUST not fragment VXLAN packets. Intermediate routers may VTEPs MUST NOT fragment VXLAN packets. Intermediate routers may
fragment encapsulated VXLAN packets due to the larger frame size. fragment encapsulated VXLAN packets due to the larger frame size.
The destination VTEP MAY silently discard such VXLAN fragments. To The destination VTEP MAY silently discard such VXLAN fragments. To
ensure end to end traffic delivery without fragmentation, it is ensure end to end traffic delivery without fragmentation, it is
RECOMMENDED that the MTUs (Maximum Transmission Units) across the RECOMMENDED that the MTUs (Maximum Transmission Units) across the
physical network infrastructure be set to a value that accommodates physical network infrastructure be set to a value that accommodates
the larger frame size due to the encapsulation. Other techniques the larger frame size due to the encapsulation. Other techniques
like Path MTU discovery (see [RFC1191 and [RFC1981]) MAY be used to like Path MTU discovery (see [RFC1191] and [RFC1981]) MAY be used to
address this requirement as well. address this requirement as well.
5. VXLAN Frame Format 5. VXLAN Frame Format
The VXLAN frame format is shown below. Parsing this from the bottom The VXLAN frame format is shown below. Parsing this from the bottom
of the frame - above the outer frame check sequence (FCS), there is of the frame - above the outer frame check sequence (FCS), there is
an inner MAC frame with its own Ethernet header with source, an inner MAC frame with its own Ethernet header with source,
destination MAC addresses along with the Ethernet type plus an destination MAC addresses along with the Ethernet type plus an
optional VLAN. See Section 6 for further details of inner VLAN tag optional VLAN. See Section 6 for further details of inner VLAN tag
handling. handling.
skipping to change at page 11, line 39 skipping to change at page 11, line 27
o Reserved fields (24 bits and 8 bits) - MUST be set to zero on o Reserved fields (24 bits and 8 bits) - MUST be set to zero on
transmit and ignored on receive. transmit and ignored on receive.
O Outer UDP Header: This is the outer UDP header with a source O Outer UDP Header: This is the outer UDP header with a source
port provided by the VTEP and the destination port being a well- port provided by the VTEP and the destination port being a well-
known UDP port. IANA has assigned the value 4789 for the VXLAN UDP known UDP port. IANA has assigned the value 4789 for the VXLAN UDP
port and this value SHOULD be used by default as the destination UDP port and this value SHOULD be used by default as the destination UDP
port. Some early implementations of VXLAN have used other values port. Some early implementations of VXLAN have used other values
for the destination port. To enable interoperability with these for the destination port. To enable interoperability with these
implementations, the destination port SHOULD be configurable. It is implementations, the destination port SHOULD be configurable. It is
recommended that the source port number be calculated using a hash recommended that the UDP source port number be calculated using a
of fields from the inner packet - one example being a hash of the hash of fields from the inner packet - one example being a hash of
inner Ethernet frame`s headers. This is to enable a level of entropy the inner Ethernet frame`s headers. This is to enable a level of
for ECMP/load balancing of the VM to VM traffic across the VXLAN entropy for ECMP/load balancing of the VM to VM traffic across the
overlay. VXLAN overlay. When calculating the UDP source port number in this
manner, it is RECOMMENDED that the value be in the dynamic/private
port range 49152-65535 [RFC6335].
The UDP checksum field SHOULD be transmitted as zero. When a packet The UDP checksum field SHOULD be transmitted as zero. When a packet
is received with a UDP checksum of zero, it MUST be accepted for is received with a UDP checksum of zero, it MUST be accepted for
decapsulation. Optionally, if the encapsulating endpoint includes a decapsulation. Optionally, if the encapsulating endpoint includes a
non-zero UDP checksum, it MUST be correctly calculated across the non-zero UDP checksum, it MUST be correctly calculated across the
entire packet including the IP header, UDP header, VXLAN header and entire packet including the IP header, UDP header, VXLAN header and
encapsulated MAC frame. When a decapsulating endpoint receives a encapsulated MAC frame. When a decapsulating endpoint receives a
packet with a non-zero checksum it MAY choose to verify the checksum packet with a non-zero checksum it MAY choose to verify the checksum
value. If it chooses to perform such verification, and the value. If it chooses to perform such verification, and the
verification fails, the packet MUST be dropped. If the verification fails, the packet MUST be dropped. If the
skipping to change at page 18, line 6 skipping to change at page 18, line 6
| |VM2-3 | |VM2-4 | | | |VM2-3 | |VM2-4 | |
| |VNI 98 | |VNI 22 | | | |VNI 98 | |VNI 22 | |
| | | | | | | | | | | |
| +---------+ +---------+ | | +---------+ +---------+ |
| Hypervisor VTEP (IP2) | | Hypervisor VTEP (IP2) |
+--------------------------+ +--------------------------+
Figure 3 VXLAN Deployment - VTEPs across a Layer 3 Network Figure 3 VXLAN Deployment - VTEPs across a Layer 3 Network
One deployment scenario is where the tunnel termination point is a One deployment scenario is where the tunnel termination point is a
physical server which understands VXLAN. Another scenario is where physical server which understands VXLAN. An alternate scenario is
nodes on a VXLAN overlay network need to communicate with nodes on where nodes on a VXLAN overlay network need to communicate with
legacy networks which could be VLAN based. These nodes may be nodes on legacy networks which could be VLAN based. These nodes may
physical nodes or virtual machines. To enable this communication, a be physical nodes or virtual machines. To enable this communication,
network can include VXLAN gateways (see Figure 4 below with a switch a network can include VXLAN gateways (see Figure 4 below with a
acting as a VXLAN gateway) which forward traffic between VXLAN and switch acting as a VXLAN gateway) which forward traffic between
non-VXLAN environments. VXLAN and non-VXLAN environments.
Consider Figure 4 for the following discussion. For incoming frames Consider Figure 4 for the following discussion. For incoming frames
on the VXLAN connected interface, the gateway strips out the VXLAN on the VXLAN connected interface, the gateway strips out the VXLAN
header and forwards to a physical port based on the destination MAC header and forwards to a physical port based on the destination MAC
address of the inner Ethernet frame. Decapsulated frames with the address of the inner Ethernet frame. Decapsulated frames with the
inner VLAN ID SHOULD be discarded unless configured explicitly to be inner VLAN ID SHOULD be discarded unless configured explicitly to be
passed on to the non-VXLAN interface. In the reverse direction, passed on to the non-VXLAN interface. In the reverse direction,
incoming frames for the non-VXLAN interfaces are mapped to a incoming frames for the non-VXLAN interfaces are mapped to a
specific VXLAN overlay network based on the VLAN ID in the frame. specific VXLAN overlay network based on the VLAN ID in the frame.
Unless configured explicitly to be passed on in the encapsulated Unless configured explicitly to be passed on in the encapsulated
skipping to change at page 22, line 8 skipping to change at page 22, line 8
[802.1aq] "Standard for Local and Metropolitan Area Networks / [802.1aq] "Standard for Local and Metropolitan Area Networks /
Virtual Bridged Local Area Networks / Amendment20: Shortest Virtual Bridged Local Area Networks / Amendment20: Shortest
Path Bridging, IEEE P802.1aq-2012". Path Bridging, IEEE P802.1aq-2012".
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC1191,
November 1990. November 1990.
[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, August 1996. for IP version 6", RFC 1981, August 1996.
[RFC6335] Cotton, M, Eggert, L., Touch, J., Westerlund, M., and
Cheshire, S., "Internet Assigned Numbers Authority (IANA) Procedures
for the Management of the Service Name and Transport Protocol Port
Number Registry", RFC 6335, August 2011.
10. Acknowledgments 10. Acknowledgments
The authors wish to thank Ajit Sanzgiri for contributions to the The authors wish to thank Ajit Sanzgiri for contributions to the
Security Considerations section and editorial inputs, Joseph Cheng, Security Considerations section and editorial inputs, Joseph Cheng,
Margaret Petrus, Milin Desai, Nial de Barra, Jeff Mandin and Siva Margaret Petrus, Milin Desai, Nial de Barra, Jeff Mandin and Siva
Kollipara for their editorial reviews, inputs and comments. Kollipara for their editorial reviews, inputs and comments.
Authors' Addresses Authors' Addresses
Mallik Mahalingam Mallik Mahalingam
skipping to change at page 23, line 4 skipping to change at page 23, line 7
Santa Clara, CA 95054 Santa Clara, CA 95054
Email: kduda@aristanetworks.com Email: kduda@aristanetworks.com
Puneet Agarwal Puneet Agarwal
Broadcom Corporation Broadcom Corporation
3151 Zanker Road 3151 Zanker Road
San Jose, CA 95134 San Jose, CA 95134
Email: pagarwal@broadcom.com Email: pagarwal@broadcom.com
Lawrence Kreeger Lawrence Kreeger
Cisco Systems, Inc. Cisco Systems, Inc.
170 W. Tasman Avenue 170 W. Tasman Avenue
Palo Alto, CA 94304 San Jose, CA 95134
Email: kreeger@cisco.com Email: kreeger@cisco.com
T. Sridhar T. Sridhar
VMware Inc. VMware Inc.
3401 Hillview 3401 Hillview
Palo Alto, CA 94304 Palo Alto, CA 94304
Email: tsridhar@vmware.com Email: tsridhar@vmware.com
 End of changes. 24 change blocks. 
55 lines changed or deleted 58 lines changed or added

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