draft-ietf-nvo3-vmm-00.txt   draft-ietf-nvo3-vmm-01.txt 
Network Working Group B. Sarikaya Network Working Group B. Sarikaya
Internet-Draft L. Dunbar Internet-Draft
Intended status: Best Current Practice Huawei USA Intended status: Best Current Practice L. Dunbar
Expires: January 18, 2018 B. Khasnabish Expires: May 3, 2018 Huawei USA
B. Khasnabish
ZTE (TX) Inc. ZTE (TX) Inc.
T. Herbert T. Herbert
Quantonium Quantonium
S. Dikshit S. Dikshit
Cisco Systems Cisco Systems
July 17, 2017 October 30, 2017
Virtual Machine Mobility Protocol for L2 and L3 Overlay Networks Virtual Machine Mobility Protocol for L2 and L3 Overlay Networks
draft-ietf-nvo3-vmm-00.txt draft-ietf-nvo3-vmm-01.txt
Abstract Abstract
This document describes a virtual machine mobility protocol commonly This document describes a virtual machine mobility protocol commonly
used in data centers built with overlay-based network virtualization used in data centers built with overlay-based network virtualization
approach. For layer 2, it is based on using a Network Virtualization approach. For layer 2, it is based on using a Network Virtualization
Authority (NVA)-Network Virtualization Edge (NVE) protocol to update Authority (NVA)-Network Virtualization Edge (NVE) protocol to update
Address Resolution Protocol (ARP) table or neighbor cache entries at Address Resolution Protocol (ARP) table or neighbor cache entries at
the NVA and the source NVEs tunneling in-flight packets to the the NVA and the source NVEs tunneling in-flight packets to the
destination NVE after the virtual machine moves from source NVE to destination NVE after the virtual machine moves from source NVE to
skipping to change at page 1, line 37 skipping to change at page 1, line 38
connection migration after the move. connection migration after the move.
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 January 18, 2018. This Internet-Draft will expire on May 3, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
skipping to change at page 3, line 12 skipping to change at page 3, line 12
arises for connectivity between Layer 2 boundaries which can be arises for connectivity between Layer 2 boundaries which can be
achieved by the network virtualization edge (NVE) functioning as achieved by the network virtualization edge (NVE) functioning as
Layer 3 gateway routing across bridging domain such as in Warehouse Layer 3 gateway routing across bridging domain such as in Warehouse
Scale Computers (WSC). Scale Computers (WSC).
Virtualization which is being used in almost all of today's data Virtualization which is being used in almost all of today's data
centers enables many virtual machines to run on a single physical centers enables many virtual machines to run on a single physical
computer or compute server. Virtual machines (VM) need hypervisor computer or compute server. Virtual machines (VM) need hypervisor
running on the physical compute server to provide them shared running on the physical compute server to provide them shared
processor/memory/storage. Network connectivity is provided by the processor/memory/storage. Network connectivity is provided by the
network virtualization edge (NVE) [I-D.ietf-nvo3-arch], network virtualization edge (NVE) [RFC8014]. Being able to move VMs
[I-D.ietf-nvo3-nve-nva-cp-req]. Being able to move VMs dynamically, dynamically, or live migration, from one server to another allows for
or live migration, from one server to another allows for dynamic load dynamic load balancing or work distribution and thus it is a highly
balancing or work distribution and thus it is a highly desirable desirable feature [RFC7364].
feature [RFC7364].
There are many challenges and requirements related to migration, There are many challenges and requirements related to migration,
mobility, and interconnection of Virtual Machines (VMs)and Virtual mobility, and interconnection of Virtual Machines (VMs)and Virtual
Network Elements (VNEs). Retaining IP addresses after a move is a Network Elements (VNEs). Retaining IP addresses after a move is a
key requirement [RFC7364]. Such a requirement is needed in order to key requirement [RFC7364]. Such a requirement is needed in order to
maintain existing transport connections. maintain existing transport connections.
In L3 based data networks, retaining IP addresses after a move is In L3 based data networks, retaining IP addresses after a move is
simply not possible. This introduces complexity in IP address simply not possible. This introduces complexity in IP address
management and as a result transport connections need to be management and as a result transport connections need to be
skipping to change at page 3, line 40 skipping to change at page 3, line 39
there is a desire to define a standard control plane protocol for there is a desire to define a standard control plane protocol for
virtual machine mobility. The protocol should be based on IPv4 or virtual machine mobility. The protocol should be based on IPv4 or
IPv6. In this document we specify such a protocol for Layer 2 and IPv6. In this document we specify such a protocol for Layer 2 and
Layer 3 data networks. Layer 3 data networks.
2. Conventions and Terminology 2. Conventions and Terminology
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] and document are to be interpreted as described in RFC 2119 [RFC2119] and
[I-D.ietf-nvo3-arch]. [RFC8014].
This document uses the terminology defined in [RFC7364]. In addition This document uses the terminology defined in [RFC7364]. In addition
we make the following definitions: we make the following definitions:
Tasks. Tasks are the generalization of virtual machines. Tasks in Tasks. Tasks are the generalization of virtual machines. Tasks in
containers that can be migrated correspond to the virtual machines containers that can be migrated correspond to the virtual machines
that can be migrated. We use task and virtual machine that can be migrated. We use task and virtual machine
interchangeably in this document. interchangeably in this document.
Hot VM Mobility. A given VM could be moved from one server to Hot VM Mobility. A given VM could be moved from one server to
skipping to change at page 4, line 19 skipping to change at page 4, line 19
may not contain the exact same data (state information) may not contain the exact same data (state information)
Cold VM Mobility. A given VM could be moved from one server to Cold VM Mobility. A given VM could be moved from one server to
another in stopped or suspended state. another in stopped or suspended state.
Source NVE refers to the old NVE where packets were forwarded to Source NVE refers to the old NVE where packets were forwarded to
before migration. before migration.
Destination NVE refers to the new NVE after migration. Destination NVE refers to the new NVE after migration.
Packets in flight refers to the packets received by the source NVE
sent by the correspondents that have old ARP or neighbor cache entry
before VM or task migration.
3. Requirements 3. Requirements
This section states requirements on data center network virtual This section states requirements on data center network virtual
machine mobility. machine mobility.
Data center network SHOULD support virtual machine mobility in IPv6. Data center network SHOULD support virtual machine mobility in IPv6.
IPv4 SHOULD also be supported in virtual machine mobility. IPv4 SHOULD also be supported in virtual machine mobility.
Virtual machine mobility protocol MAY support host routes to Virtual machine mobility protocol MAY support host routes to
skipping to change at page 5, line 27 skipping to change at page 5, line 31
new destination one. During this period, a tunnel is needed so that new destination one. During this period, a tunnel is needed so that
source NVE forwards packets to the destination NVE. source NVE forwards packets to the destination NVE.
In IPv4, the virtual machine immediately after the move sends a In IPv4, the virtual machine immediately after the move sends a
gratuitous ARP request message containing its IPv4 and Layer 2 or MAC gratuitous ARP request message containing its IPv4 and Layer 2 or MAC
address in its new NVE, destination NVE. This message's destination address in its new NVE, destination NVE. This message's destination
address is the broadcast address. NVE receives this message. NVE address is the broadcast address. NVE receives this message. NVE
should update VM's ARP entry in the central directory at the NVA. should update VM's ARP entry in the central directory at the NVA.
NVE asks NVA to update its mappings to record IPv4 address of VM NVE asks NVA to update its mappings to record IPv4 address of VM
along with MAC address of VM, and NVE IPv4 address. An NVE-to-NVA along with MAC address of VM, and NVE IPv4 address. An NVE-to-NVA
protocol is used for this purpose [I-D.ietf-nvo3-arch]. protocol is used for this purpose [RFC8014].
Reverse ARP (RARP) which enables the host to discover its IPv4 Reverse ARP (RARP) which enables the host to discover its IPv4
address when it boots from a local server [RFC0903] is not used by address when it boots from a local server [RFC0903] is not used by
VMs because the VM already knows its IPv4 address. IPv4/v6 address VMs because the VM already knows its IPv4 address. IPv4/v6 address
is assigned to a newly created VM, possibly using Dynamic Host is assigned to a newly created VM, possibly using Dynamic Host
Configuration Protocol (DHCP). There are some vendor deployments Configuration Protocol (DHCP). There are some vendor deployments
(diskless systems or systems without configuration files) wherein VM (diskless systems or systems without configuration files) wherein VM
users, i.e. end-user clients ask for the same MAC address upon users, i.e. end-user clients ask for the same MAC address upon
migration. This can be achieved by the clients sending RARP request migration. This can be achieved by the clients sending RARP request
reverse message which carries the old MAC address looking for an IP reverse message which carries the old MAC address looking for an IP
skipping to change at page 6, line 18 skipping to change at page 6, line 21
IPv6 operation is slightly different: IPv6 operation is slightly different:
In IPv6, the virtual machine immediately after the move sends an In IPv6, the virtual machine immediately after the move sends an
unsolicited neighbor advertisement message containing its IPv6 unsolicited neighbor advertisement message containing its IPv6
address and Layer-2 MAC address in its new NVE, the destination NVE. address and Layer-2 MAC address in its new NVE, the destination NVE.
This message is sent to the IPv6 Solicited Node Multicast Address This message is sent to the IPv6 Solicited Node Multicast Address
corresponding to the target address which is VM's IPv6 address. NVE corresponding to the target address which is VM's IPv6 address. NVE
receives this message. NVE should update VM's neighbor cache entry receives this message. NVE should update VM's neighbor cache entry
in the central directory at the NVA. IPv6 address of VM, MAC address in the central directory at the NVA. IPv6 address of VM, MAC address
of VM and NVE IPv6 address are recorded to the entry. An NVE-to-NVA of VM and NVE IPv6 address are recorded to the entry. An NVE-to-NVA
protocol is used for this purpose [I-D.ietf-nvo3-arch]. protocol is used for this purpose [RFC8014].
All NVEs communicating with this virtual machine uses the old All NVEs communicating with this virtual machine uses the old
neighbor cache entry. If any VM in those NVEs need to talk to the neighbor cache entry. If any VM in those NVEs need to talk to the
new VM in the destination NVE, it uses the old neighbor cache entry. new VM in the destination NVE, it uses the old neighbor cache entry.
Thus the packets are delivered to the source NVE. The source NVE Thus the packets are delivered to the source NVE. The source NVE
MUST tunnel these in-flight packets to the destination NVE. MUST tunnel these in-flight packets to the destination NVE.
When a neighbor cache entry in those VMs times out, their When a neighbor cache entry in those VMs times out, their
corresponding NVEs should access the NVA for an update. corresponding NVEs should access the NVA for an update.
skipping to change at page 6, line 43 skipping to change at page 6, line 46
accomplished seamlessly in L3 data center networks by just giving accomplished seamlessly in L3 data center networks by just giving
each virtual network an IP subnet and a default route that points to each virtual network an IP subnet and a default route that points to
NVE. This means no explosion of ARP/ neighbor cache in guests (just NVE. This means no explosion of ARP/ neighbor cache in guests (just
one ARP/ neighbor cache entry for default route) and we do not need one ARP/ neighbor cache entry for default route) and we do not need
to have Ethernet header in encapsulation [RFC7348] which saves at to have Ethernet header in encapsulation [RFC7348] which saves at
least 16 bytes. least 16 bytes.
In L3 based data center networks, since IP address of the task has to In L3 based data center networks, since IP address of the task has to
change after move, an IP based task migration protocol is needed. change after move, an IP based task migration protocol is needed.
The protocol mostly used is the identifier locator addressing or ILA The protocol mostly used is the identifier locator addressing or ILA
[I-D.herbert-nvo3-ila]. Address and connection migration introduce [I-D.herbert-intarea-ila]. Address and connection migration
complications in task migration protocol as we discuss below. introduce complications in task migration protocol as we discuss
Especially informing the communicating hosts of the migration becomes below. Especially informing the communicating hosts of the migration
a major issue. Also, in L3 based networks, because broadcasting is becomes a major issue. Also, in L3 based networks, because
not available, multicast of neighbor solicitations in IPv6 would need broadcasting is not available, multicast of neighbor solicitations in
to be emulated. IPv6 would need to be emulated.
Task migration involves the following steps: Task migration involves the following steps:
Stop running the task. Stop running the task.
Package the runtime state of the job. Package the runtime state of the job.
Send the runtime state of the task to the destination NVE where the Send the runtime state of the task to the destination NVE where the
task is to run. task is to run.
skipping to change at page 10, line 27 skipping to change at page 10, line 30
2. Receiving an acknowledgement from the NVA regarding availability 2. Receiving an acknowledgement from the NVA regarding availability
and usability of virtualized resources and interface package and usability of virtualized resources and interface package
3. Sending a confirmation message to the NVA with request for 3. Sending a confirmation message to the NVA with request for
approval to adapt/adjust/modify the virtualized resources and approval to adapt/adjust/modify the virtualized resources and
interface package for utilization in a service. interface package for utilization in a service.
9. Security Considerations 9. Security Considerations
Security threats for the data and control plane are discussed in Security threats for the data and control plane are discussed in
[I-D.ietf-nvo3-arch]. There are several issues in a multi-tenant [RFC8014]. There are several issues in a multi-tenant environment
environment that create problems. In L2 based data center networks, that create problems. In L2 based data center networks, lack of
lack of security in VXLAN, corruption of VNI can lead to delivery to security in VXLAN, corruption of VNI can lead to delivery to wrong
wrong tenant. Also, ARP in IPv4 and ND in IPv6 are not secure tenant. Also, ARP in IPv4 and ND in IPv6 are not secure especially
especially if we accept gratuitous versions. When these are done if we accept gratuitous versions. When these are done over a UDP
over a UDP encapsulation, like VXLAN, the problem is worse since it encapsulation, like VXLAN, the problem is worse since it is trivial
is trivial for a non trusted application to spoof UDP packets. for a non trusted application to spoof UDP packets.
In L3 based data center networks, the problem of address spoofing may In L3 based data center networks, the problem of address spoofing may
arise. As a result the destinations may contain untrusted hosts. arise. As a result the destinations may contain untrusted hosts.
This usually happens in cases like the virtual machines running third This usually happens in cases like the virtual machines running third
part applications. This requires the usage of stronger security part applications. This requires the usage of stronger security
mechanisms. mechanisms.
10. IANA Considerations 10. IANA Considerations
This document makes no request to IANA. This document makes no request to IANA.
11. Acknowledgements 11. Acknowledgements
The authors are grateful to Qiang Zu, Andrew Malis for helpful The authors are grateful to Dave R. Worley, Qiang Zu, Andrew Malis
comments. for helpful comments.
12. Change Log 12. Change Log
o submitted version -00 as a working group draft after adoption o submitted version -00 as a working group draft after adoption
o submitted version -01 with these changes: references are updated,
added packets in flight definition to Section 2
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-nvo3-arch]
Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T.
Narten, "An Architecture for Data Center Network
Virtualization Overlays (NVO3)", draft-ietf-nvo3-arch-08
(work in progress), September 2016.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37, Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982, RFC 826, DOI 10.17487/RFC0826, November 1982,
<http://www.rfc-editor.org/info/rfc826>. <https://www.rfc-editor.org/info/rfc826>.
[RFC0903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A [RFC0903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
Reverse Address Resolution Protocol", STD 38, RFC 903, Reverse Address Resolution Protocol", STD 38, RFC 903,
DOI 10.17487/RFC0903, June 1984, DOI 10.17487/RFC0903, June 1984,
<http://www.rfc-editor.org/info/rfc903>. <https://www.rfc-editor.org/info/rfc903>.
[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>.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999, DOI 10.17487/RFC2629, June 1999,
<http://www.rfc-editor.org/info/rfc2629>. <https://www.rfc-editor.org/info/rfc2629>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[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>.
[RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L., [RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L.,
Kreeger, L., and M. Napierala, "Problem Statement: Kreeger, L., and M. Napierala, "Problem Statement:
Overlays for Network Virtualization", RFC 7364, Overlays for Network Virtualization", RFC 7364,
DOI 10.17487/RFC7364, October 2014, DOI 10.17487/RFC7364, October 2014,
<http://www.rfc-editor.org/info/rfc7364>. <https://www.rfc-editor.org/info/rfc7364>.
[RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T.
Narten, "An Architecture for Data-Center Network
Virtualization over Layer 3 (NVO3)", RFC 8014,
DOI 10.17487/RFC8014, December 2016,
<https://www.rfc-editor.org/info/rfc8014>.
13.2. Informative references 13.2. Informative references
[I-D.herbert-nvo3-ila] [I-D.herbert-intarea-ila]
Herbert, T. and P. Lapukhov, "Identifier-locator Herbert, T. and P. Lapukhov, "Identifier-locator
addressing for IPv6", draft-herbert-nvo3-ila-04 (work in addressing for IPv6", draft-herbert-intarea-ila-00 (work
progress), March 2017. in progress), October 2017.
[I-D.ietf-nvo3-nve-nva-cp-req]
Kreeger, L., Dutt, D., Narten, T., and D. Black, "Network
Virtualization NVE to NVA Control Protocol Requirements",
draft-ietf-nvo3-nve-nva-cp-req-05 (work in progress),
March 2016.
Authors' Addresses Authors' Addresses
Behcet Sarikaya Behcet Sarikaya
Huawei USA
5340 Legacy Dr. Building 3
Plano, TX 75024
Email: sarikaya@ieee.org Email: sarikaya@ieee.org
Linda Dunbar Linda Dunbar
Huawei USA Huawei USA
5340 Legacy Dr. Building 3 5340 Legacy Dr. Building 3
Plano, TX 75024 Plano, TX 75024
Email: linda.dunbar@huawei.com Email: linda.dunbar@huawei.com
 End of changes. 26 change blocks. 
56 lines changed or deleted 54 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/