[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-rekhter-nvo3-vm-mobility-issues) 00 01 02 03

Network Working Group                                         Y. Rekhter
Internet Draft                                          Juniper Networks
Category: Standards Track
Expiration Date: December 2014
                                                           W. Henderickx
                                                          Alcatel-Lucent

                                                              R. Shekhar
                                                        Juniper Networks

                                                             Luyuan Fang
                                                           Cisco Systems

                                                            Linda Dunbar
                                                                  Huawei

                                                             Ali Sajassi
                                                           Cisco Systems

                                                             June 2 2014


                   Network-related VM Mobility Issues


               draft-ietf-nvo3-vm-mobility-issues-03.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.





Rekhter                                                         [Page 1]


Internet Draft  draft-ietf-nvo3-vm-mobility-issues-03.txt      June 2014


Copyright and License Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.



Abstract

   This document describes a set of network-related issues presented by
   the desire to support seamless Virtual Machine mobility in the data
   center and between data centers. In particular, it looks at the
   implications of meeting the requirements for "seamless mobility".
















Rekhter                                                         [Page 2]


Internet Draft  draft-ietf-nvo3-vm-mobility-issues-03.txt      June 2014


Table of Contents

 1          Specification of requirements  .........................   3
 2          Introduction  ..........................................   3
 2.1        Terminology  ...........................................   4
 3          Problem Statement  .....................................   7
 3.1        Usage of VLAN-IDs  .....................................   7
 3.2        Maintaining Connectivity in the Presence of VM Mobility  ...8
 3.3        Layer 2 Extension  .....................................   8
 3.4        Optimal IP Routing  ....................................   9
 3.5        Preserving Policies  ...................................  10
 4          IANA Considerations  ...................................  10
 5          Security Considerations  ...............................  10
 6          Acknowledgements  ......................................  10
 7          References  ............................................  10
 8          Author's Address  ......................................  11






1. Specification of requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2. Introduction

   An important feature of data centers identified in [nvo3-problem] is
   the support of Virtual Machine (VM) mobility within the data center
   and between data centers. This document describes a set of network-
   related issues presented by the desire to support seamless Virtual
   Machine mobility in the data center, where seamless mobility is
   defined as the ability to move a VM from one server in the data
   center to another server in the same or different data center, while
   retaining the IP and MAC address of the VM. In the context of this
   document the term mobility, or a reference to moving a VM should be
   considered to imply seamless mobility, unless otherwise stated.

   Note that in the scenario where a VM is moved between servers located



Rekhter                                                         [Page 3]


Internet Draft  draft-ietf-nvo3-vm-mobility-issues-03.txt      June 2014


   in different data centers, there are certain issues related to the
   current state of the art of the Virtual Machine technology, the
   bandwidth that may be available between the data centers, the
   distance between the data centers, the ability to manage and operate
   such VM mobility, storage-related issues (the moved VM has to have
   access to the same virtual disk), etc.  Discussion of these issues is
   outside the scope of this document.


2.1. Terminology

   In this document the term "Top of Rack Switch (ToR)" is used to refer
   to a switch in a data center that is connected to the servers that
   host VMs. A data center may have multiple ToRs. When External Bridge
   Port Extenders (as defined by 802.1BR) are used to connect the
   servers to the data center network, the ToR switch is the Controlling
   Bridge.

   Several data centers could be connected by a network. In addition to
   providing interconnect among the data centers, such a network could
   provide connectivity between the VMs hosted in these data centers and
   the sites that contain hosts communicating with such VMs. Each data
   center has one or more Data Center Border Router (DCBR) that connects
   the data center to the network, and provides (a) connectivity between
   VMs hosted in the data center and VMs hosted in other data centers,
   and (b) connectivity between VMs hosted in the data center and hosts
   communicating with these VMs.

   The following figure illustrates the above:


                   __________
                  (          )
                 ( Data Center)
                ( Interconnect )-------------------------
                 (  Network   )                          |
                  (__________)                           |
                     |    |                              |
                 ----      ----                          |
                |              |                         |
        --------+--------------+---------------        -------------
       |        |              |       Data     |     |             |
       |     ------          ------    Center   |     | Data Center |
       |    | DBCR |        | DBCR |            |     |             |
       |     ------          ------             |      -------------
       |        |              |                |
       |         ---        ---                 |
       |         ___|______|__                  |



Rekhter                                                         [Page 4]


Internet Draft  draft-ietf-nvo3-vm-mobility-issues-03.txt      June 2014


       |        (             )                 |
       |       (  Data Center  )                |
       |        (   Network   )                 |
       |         (___________)                  |
       |            |      |                    |
       |        ----        ----                |
       |       |                |               |
       |  ------------        -----             |
       | | ToR Switch |      | ToR |            |
       |  ------------        -----             |
       |   |                    |               |
       |   |   ----------       |   ----------  |
       |   |--| Server   |      |--| Server   | |
       |   |  |          |      |   ----------  |
       |   |  |  ----    |      |               |
       |   |  | | VM |   |      |   ----------  |
       |   |  |  -----   |       --| Server   | |
       |   |  |  | VM |  |          ----------  |
       |   |  |   -----  |                      |
       |   |  |   | VM | |                      |
       |   |  |    ----  |                      |
       |   |   ----------                       |
       |   |                                    |
       |   |   ----------                       |
       |   |--| Server   |                      |
       |   |   ----------                       |
       |   |                                    |
       |   |   ----------                       |
       |    --| Server   |                      |
       |       ----------                       |
       |                                        |
        ----------------------------------------






   The data centers and the network that interconnects them may be
   either (a) under the same administrative control, or (b) controlled
   by different administrations.

   Consider a set of VMs that (as a matter of policy) are allowed to
   communicate with each other, and a collection of devices that
   interconnect these VMs. If communication among any VMs in that set
   could be accomplished in such a way as to preserve MAC source and
   destination addresses in the Ethernet header of the packets exchanged
   among these VMs (as these packets traverse from their sources to



Rekhter                                                         [Page 5]


Internet Draft  draft-ietf-nvo3-vm-mobility-issues-03.txt      June 2014


   their destinations), we will refer to such set of VMs as an Layer 2
   based Closed User Group (L2-based CUG).

   A given VM may be a member of more than one L2-based CUG.

   In terms of IP address assignment this document assumes that all VMs
   of a given L2-based CUG have their IP addresses assigned out of a
   single IP prefix. Thus, in the context of this document a single IP
   subnet corresponds to a single L2-based CUG.  If a given VM is a
   member of more than one L2-based CUG, this VM would have multiple IP
   addresses and multiple logical interface, one IP address and one
   logical interface per each such CUG.

   A VM that is a member of a given L2-based CUG may (as a matter of
   policy) be allowed to communicate with VMs that belong to other
   L2-based CUGs, or with other hosts. Such communication involves IP
   forwarding, and thus would result in changing MAC source and
   destination addresses in the Ethernet header of the packets being
   exchanged.

   In this document the term "L2 physical domain" refers to a collection
   of interconnected devices that perform forwarding based on the
   information carried in the Ethernet header. A trivial L2 physical
   domain consists of just one server. In a non-trivial L2 physical
   domain (domain that contains multiple forwarding entities) forwarding
   could be provided by such layer 2 technologies as Spanning Tree
   Protocol (STP), etc...  Note that any multi-chassis LAG can not span
   more than one L2 physical domain. This document assumes that a layer
   2 access domain is an L2 physical domain.

   A physical server connected to a given L2 physical domain may host
   VMs that belong to different L2-based CUGs (while each of these CUGs
   may span multiple L2 physical domains). If an L2 physical domain
   contains servers that host VMs belonging to different L2-based CUGs,
   then enforcing L2-based CUGs boundaries among these VMs within that
   domain is accomplished by relying on Layer 2 mechanisms (e.g.,
   VLANs).

   We say that an L2 physical domain contains a given VM (or that a
   given VM is in a given L2 physical domain), if the server presently
   hosting this VM is part of that domain, or the server is connected to
   a ToR that is part of that domain.

   We say that a given L2-based CUG is present within a given data
   center if one or more VMs that are part of that CUG are presently
   hosted by the servers located in that data center.

   In the context of this document when we talk about VLAN-ID used by a



Rekhter                                                         [Page 6]


Internet Draft  draft-ietf-nvo3-vm-mobility-issues-03.txt      June 2014


   given VM, we refer to the VLAN-ID carried by the traffic that is
   within the same L2 physical domain as the VM, and that is either
   originated or destined to that VM - e.g., VLAN-ID only has local
   significance within the L2 physical domain, unless it is stated
   otherwise.


3. Problem Statement

   This section describes the specific problems/issues that need to be
   addressed to enable seamless VM mobility.


3.1. Usage of VLAN-IDs

   This document assumes that within a given non-trivial L2 physical
   domain traffic from/to VMs that are in that domain, and belong to the
   same L2-based CUG MUST have the same VLAN-ID. This document assumes
   that in different non-trivial L2 physical domains traffic from/to VMs
   that are in these domains and belong to the same L2-based CUG MAY
   have either the same or different VLAN-IDs.  Thus when a given VM
   moves from one non-trivial L2 physical domain to another, the VLAN-ID
   of the traffic from/to VM in the former may be different than in the
   latter, and thus can not assume to stay the same.

   This document assumes that within a trivial L2 physical domain
   traffic from/to VMs that are in this domain may not have VLAN-IDs at
   all.

   If a given VM's Guest OS sends packets that carry VLAN-ID, then when
   the VM moves from one L2 physical domain to another the VLAN-ID used
   by the Guest OS can not change (this is irrespective of whether L2
   physical domains are trivial or non-trivial). In other words, the
   VLAN-IDs used by a tagged VM network interface are part of the VM's
   state and cannot be changed when the VM moves from one L2 physical
   domain to another, even though it is possible for an entity, such as
   hypervisor virtual switch, to change the VLAN-ID from the value used
   by NVE to the value expected by the VM (in contrast, a VLAN tag
   assigned by a hypervisor for use with an untagged VM network
   interface can change). If the L2 physical domain is extended to
   include VM tagged interfaces, the hypervisor virtual switch, and the
   DC bridged network, then special consideration is needed in
   assignment of VLAN tags for the VMs, the L2 physical domain and other
   domains into which the VM may move.

   This document assumes that within a given non-trivial L2 physical
   domain traffic from/to VMs that are in that domain, and belong to
   different L2-based CUG MUST have different VLAN-IDs.



Rekhter                                                         [Page 7]


Internet Draft  draft-ietf-nvo3-vm-mobility-issues-03.txt      June 2014


   The above assumptions about VLAN-IDs are driven by (a) the assumption
   that within a given L2 physical domain VLANs are used to identify
   individual L2-based CUGs, and (b) the need to overcome the limitation
   on the number of different VLAN-IDs.


3.2. Maintaining Connectivity in the Presence of VM Mobility

   In the context of this document the ability to maintain connectivity
   in the presence of VM mobility means the ability to exchange traffic
   between a VM and its peer(s), as the VM moves from one server to
   another, where the peer(s) may be either other VM(s) or hosts.
   Furthermore, the peer(s) need not be within the same data center as
   the VM itself.

   A given VM could be moved from one server to another in stopped or
   suspended state ("cold" VM mobility), or the hypervisors might move a
   running VM ("hot" VM mobility). IP address preservation is sometimes
   highly desired for cold VM mobility; it's mandatory to preserve
   transport connections when a running VM is moved.

   VM mobility may result in transient loss of IP connectivity between
   VM and its peers. In the case of hot VM mobility the upper bound on
   the duration of such transients is (much) lower than in the case of
   cold VM mobility (due to the requirement of preserving transport
   connections and potential additional application requirements).

   Furthermore, while with cold VM mobility one may assume that VM's ARP
   cache gets flushed once VM moves to another server, one can not make
   such an assumption with hot VM mobility.


3.3. Layer 2 Extension

   Consider a scenario where a VM that is a member of a given L2-based
   CUG moves from one server to another, and these two servers are in
   different L2 physical domains, where these domains may be located in
   the same or different data centers. In order to enable communication
   between this VM and other VMs of that L2-based CUG, the new L2
   physical domain must become interconnected with the other L2 physical
   domain(s) that presently contain the rest of the VMs of that CUG, and
   the interconnect must not violate the L2-based CUG requirement to
   preserve source and destination MAC addresses in the Ethernet header
   of the packets exchange between this VM and other members of that
   CUG.

   Moreover, if the previous L2 physical domain no longer contains any
   VMs of that CUG, the previous domain no longer needs to be



Rekhter                                                         [Page 8]


Internet Draft  draft-ietf-nvo3-vm-mobility-issues-03.txt      June 2014


   interconnected with the other L2 physical domains(s) that contain the
   rest of the VMs of that CUG.

   Note that supporting VM mobility implies that the set of L2 physical
   domains that contain VMs that belong to a given L2-based CUG may
   change over time (new domains added, old domains deleted).

   We will refer to this as the "layer 2 extension problem".

   Note that the layer 2 extension problem is a special case of
   maintaining connectivity in the presence of VM mobility, as the
   former restricts communicating VMs to a single/common L2-based CUG,
   while the latter does not.


3.4. Optimal IP Routing

   In the context of this document optimal IP routing, or just optimal
   routing, in the presence of VM mobility could be partitioned into two
   problems:

     + Optimal routing of a VM's outbound traffic. This means that as a
       given VM moves from one server to another, the VM's default
       gateway should be in a close topological proximity to the ToR
       that connects the server presently hosting that VM. Note that
       when we talk about optimal routing of the VM's outbound traffic,
       we mean traffic from that VM to the destinations that are outside
       of the VM's L2-based CUG. This document refers to this problem as
       the VM default gateway problem.

     + Optimal routing of VM's inbound traffic. This means that as a
       given VM moves from one server to another, the (inbound) traffic
       originated outside of the VM's L2-based CUG, and destined to that
       VM be routed via the router of the VM's L2-based CUG that is in a
       close topological proximity to the ToR that connects the server
       presently hosting that VM, without first traversing some other
       router of that L2-based CUG (the router of the VM's L2-based CUG
       may be either DCBR or ToR itself). This is also known as avoiding
       "triangular routing". This document refers to this problem as the
       triangular routing problem.

   Note that optimal routing is a special case of maintaining
   connectivity in the presence of VM mobility, as the former assumes
   not only the ability to maintain connectivity, but also that this
   connectivity is maintained using optimal routing. On the other hand,
   maintaining connectivity does not make optimal routing a pre-
   requisite.




Rekhter                                                         [Page 9]


Internet Draft  draft-ietf-nvo3-vm-mobility-issues-03.txt      June 2014


   The ability to deliver optimal routing (as defined above) in the
   presence of stateful devices is outside the scope of this document.


3.5. Preserving Policies

   Moving VM from one L2 physical domain to another means (among other
   things) that the NVE in the new domain that provides connectivity
   between this VM and VMs in other L2 physical domains must be able to
   implement the policies that control connectivity between this VM and
   VMs in other L2 physical domains. In other words, the policies that
   control connectivity between a given VM and its peers MUST NOT change
   as the VM moves from one L2 physical domain to another.  Moreover,
   policies, if any, within the L2 physical domain that contain a given
   VM MUST NOT preclude realization of the policies that control
   connectivity between this VM and its peers. All of the above is
   irrespective of whether the L2 physical domains are trivial or not.


4. IANA Considerations

   This document introduces no new IANA Considerations.


5. Security Considerations

   TBD.


6. Acknowledgements

   The authors would like to thank Adrian Farrel for his review and
   comments. The authors would also like to thank Ivan Pepelnjak and
   David Black for their contributions to this document.



7. References

   [nvo3-problem] Narten T.et al., "Overlays for Network
   Virtualization", draft-narten-nvo3-overlay-problem-statement, work in
   progress.









Rekhter                                                        [Page 10]


Internet Draft  draft-ietf-nvo3-vm-mobility-issues-03.txt      June 2014


8. Author's Address

   Yakov Rekhter
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   Email: yakov@juniper.net

   Wim Henderickx
   Alcatel-Lucent
   Email: wim.henderickx@alcatel-lucent.com

   Ravi Shekhar
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   Email: rshekhar@juniper.net

   Luyuan Fang
   Cisco Systems
   111 Wood Avenue South
   Iselin, NJ 08830
   Email: lufang@cisco.com

   Linda Dunbar
   Huawei Technologies
   5340 Legacy Drive, Suite 175
   Plano, TX 75024, USA
   Phone: (469) 277 5840
   Email: ldunbar@huawei.com

   Ali Sajassi
   Cisco Systems
   Email: sajassi@cisco.com

   Rahul Aggarwal
   Arktan, Inc
   Email: raggarwa_1@yahoo.com













Rekhter                                                        [Page 11]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/