draft-ietf-nvo3-vmm-12.txt   draft-ietf-nvo3-vmm-13.txt 
Network Working Group L. Dunbar Network Working Group L. Dunbar
Internet Draft Futurewei Internet Draft Futurewei
Intended status: Informational B. Sarikaya Intended status: Informational B. Sarikaya
Expires: September 30, 2020 Denpel Informatique Expires: October 1, 2020 Denpel Informatique
B.Khasnabish B.Khasnabish
Independent Independent
T. Herbert T. Herbert
Intel Intel
S. Dikshit S. Dikshit
Aruba-HPE Aruba-HPE
March 30, 2020 April 1, 2020
Virtual Machine Mobility Solutions for L2 and L3 Overlay Networks Virtual Machine Mobility Solutions for L2 and L3 Overlay Networks
draft-ietf-nvo3-vmm-12 draft-ietf-nvo3-vmm-13
Abstract Abstract
This document describes virtual machine mobility solutions commonly This document describes virtual machine mobility solutions commonly
used in data centers built with overlay-based network. This document used in data centers built with overlay-based network. This document
is intended for describing the solutions and the impact of moving is intended for describing the solutions and the impact of moving
VMs (or applications) from one Rack to another connected by the VMs (or applications) from one Rack to another connected by the
Overlay networks. Overlay networks.
For layer 2, it is based on using an NVA (Network Virtualization For layer 2, it is based on using an NVA (Network Virtualization
skipping to change at page 6, line 25 skipping to change at page 6, line 25
4.1. Inter-VNs and External Communication 4.1. Inter-VNs and External Communication
Inter VNs (Virtual Networks) communication refers to communication Inter VNs (Virtual Networks) communication refers to communication
among tenants (or hosts) belonging to different VNs. Those tenants among tenants (or hosts) belonging to different VNs. Those tenants
can be attached to the NVEs co-located in the same Data Center or can be attached to the NVEs co-located in the same Data Center or
in different Data centers. When a VM communicates with an external in different Data centers. When a VM communicates with an external
entity, the VM is effectively communicating with a peer in a entity, the VM is effectively communicating with a peer in a
different network or a globally reachable host. different network or a globally reachable host.
This document assumes that the inter-VNs communication and the This document assumes that the inter-VNs communication and
communication with external entities are via the NVO3 Gateway as the communication with external entities are via NVO3 Gateway
described in RFC8014 (NVO3 Architecture). RFC 8014 (Section 5.3) functionality as described in Section 5.3 of RFC 8014
describes the NVO3 Gateway function which is to relay traffic onto [RFC8014]. NVO3 Gateways relay traffic onto and off of a virtual
and off of a virtual network, i.e. among different VNs. network, enabling communication both across different VNs and with
external entities.
There are different policies on the NVO3 Gateway to govern the NVO3 Gateway functionality enforces appropriate policies to
communication among VNs and with external entities (or hosts). control communication among VNs and with external entities (e.g.,
hosts).
After a VM is moved to a new NVE, the VM's corresponding Gateway After a VM is moved to a new NVE, the VM's corresponding Gateway
may need to change as well. If such a change is not possible, then may need to change as well. If there is no other entity (or node)
the path to the external entities need to be hair-pinned to the to take over the corresponding NVO3 Gateway function for the VM
NVO3 Gateway used prior to the VM move. under the new NVE, the network path between the VM and the
external entities needs to be hair-pinned to the NVO3 Gateway used
prior to the VM move.
4.2. VM Migration in Layer 2 Network 4.2. VM Migration in Layer 2 Network
In a Layer-2 based approach, VM moving to another NVE does not In a Layer-2 based approach, VM moving to another NVE does not
change its IP address. But this VM is now under a new NVE, change its IP address. But this VM is now under a new NVE,
previously communicating NVEs may continue sending their packets previously communicating NVEs may continue sending their packets
to the Old NVE. Therefore, Address Resolution Protocol (ARP) to the Old NVE. Therefore, Address Resolution Protocol (ARP)
cache in IPv4 [RFC0826] or neighbor cache in IPv6 [RFC4861] in the cache in IPv4 [RFC0826] or neighbor cache in IPv6 [RFC4861] in the
NVEs that have attached VMs communicating with the VM being moved NVEs that have attached VMs communicating with the VM being moved
need to be updated promptly. If the VM being moved has need to be updated promptly. If the VM being moved has
skipping to change at page 12, line 23 skipping to change at page 12, line 26
condition changes, or others. Hot, Warm and Cold mobility are condition changes, or others. Hot, Warm and Cold mobility are
planned activities which are managed by VM management system. planned activities which are managed by VM management system.
For unexpected events, such as unexpected failure, a VM might need For unexpected events, such as unexpected failure, a VM might need
to move to a new NVE, which is called Hot VM Failover in this to move to a new NVE, which is called Hot VM Failover in this
document. For Hot VM Failover, there are redundant primary and document. For Hot VM Failover, there are redundant primary and
secondary VMs whose states are synchronized by means that are secondary VMs whose states are synchronized by means that are
outside the scope of this draft. If the VM in the primary NVE outside the scope of this draft. If the VM in the primary NVE
fails, there is no need to actively move the VM to the secondary fails, there is no need to actively move the VM to the secondary
NVE because the VM in the secondary NVE can immediately pick up NVE because the VM in the secondary NVE can immediately pick up
the processing. Details of how state is synchronized between the the processing.
primary and secondary VMs are beyond the scope of this document.
The VM Failover to the new NVE is transparent to the peers that The VM Failover to the new NVE is transparent to the peers that
communicate with this VM. This can be achieved by both active VM communicate with this VM. This can be achieved by both active VM
and standby VM share the same TCP port and same IP address, and and standby VM share the same TCP port and same IP address, and
using distributed load balancing functionality that controls which using distributed load balancing functionality that controls which
VM responds to each service request. In the absence of a failure, VM responds to each service request. In the absence of a failure,
the new VM can pick up providing service while the sender (peer) the new VM can pick up providing service while the sender (peer)
still continues to receive Ack from the old VM. If the situation still continues to receive Ack from the old VM. If the situation
(loading condition of the primary responding VM) changes the (loading condition of the primary responding VM) changes the
secondary responding VM may start providing service to the sender secondary responding VM may start providing service to the sender
skipping to change at page 13, line 45 skipping to change at page 13, line 45
some more effort to ensure that the intercepted traffic is some more effort to ensure that the intercepted traffic is
eventually delivered to the victim. eventually delivered to the victim.
The locator-identifier mechanism given as an example (ILA) doesn't The locator-identifier mechanism given as an example (ILA) doesn't
include secure binding. It doesn't discuss how to securely bind include secure binding. It doesn't discuss how to securely bind
the new locator to the identifier. the new locator to the identifier.
Because of those threats, VM management system needs to apply Because of those threats, VM management system needs to apply
stronger security mechanisms when add a VM to an NVE. Some tenants stronger security mechanisms when add a VM to an NVE. Some tenants
may have requirement that prohibit their VMs to be co-attached to may have requirement that prohibit their VMs to be co-attached to
the NVEs with other tenants. Some Data Centers have their NVO3 the NVEs with other tenants. Some Data Centers deploy additional
Gateways to be equipped with capability to mitigate ARP/ND functionality in their NVO3 Gateways for mitigation of ARP/ND
threats, such as periodically exchanging its ARP/ND cache with threats, e.g., periodically sending each Gateway's ARP/ND cache
NVA's central control system to validate the ARP/ND cache learned contents to the NVA or other central control system to check for
by the NVE with the VM Management System. ARP/ND cache entries that are not consistent with the locations of
VMs and their IP addresses indicated by the VM Management System.
11. IANA Considerations 11. IANA Considerations
This document makes no request to IANA. This document makes no request to IANA.
12. Acknowledgments 12. Acknowledgments
The authors are grateful to Bob Briscoe, David Black, Dave R. The authors are grateful to Bob Briscoe, David Black, Dave R.
Worley, Qiang Zu, Andrew Malis for helpful comments. Worley, Qiang Zu, Andrew Malis for helpful comments.
 End of changes. 8 change blocks. 
20 lines changed or deleted 24 lines changed or added

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