Very good document.. A few comments
Live Migration I agree with Ivan, If mobility is required across a site boundary, the L2 CUG Site must already exist due to the need to access shared storage (I.e. VMFS, ISCSI, etc..). This knowledge needs to be known a priori (I.e. Before the operator tries to migrate the host). Under some live migration scenarios all data structures and state remain intact with usually only a gratuitous ARP Reply to signal something changed..obviously complicating the optimal routing scenario. Terminology The definition of ToR is also confusing IMHO and we are missing the more noticeable virtual switch in this design architecture. Because of the limitations in mobility (the target of this draft) under hypervisor bypass and IOV implementations there must be a virtual edge switch described. Usage of VLAN IDs VM's that belong to the same L2-CUG and are in different sites MAY use the same or different VLAN-Ids. I think there is an issue in defining the L2-CUG in terms of a locally significant namespace (I.e. VLAN-ID). This will make policy enforcement much more complicated as the VM's need to be re-associated with a new VLAN-ID. Wouldn't it be more appropriate to utilize a large enough non-conflicting namespace which is associated with the L2-CUG even across L2-sites managed by the same autonomous entity? Yes this is similar to what is implemented in NVP and also represented as the RLOC in LISP. I think I would have expected some conversations to that effect in this draft. Mobility in General Why do we presume that the only purpose for mobility is for VM to VM and not just any generalized service which is bound to an IP address? The more generalized problem is the dynamic-multihoming support which is not restricted by physical topology and locally significant name spaces like VLANs. For instance, what if I am Google and I have fully populated my service exhausting the ports associated with my L2-CUG. There are free ports on an adjacent rack but they are stranded because I can't expand my service due to the L2 adjacency problem. The very benefit of the overlay and a new namespace (aka Network Virtualization) allows for the decoupling of macs-to-vlans-to-ports allowing for the mobility without reconfiguring the underlying physical network. Tks -g On 8/21/12 11:10 AM, "Ivan Pepelnjak" <[email protected]> wrote: >Dear all, > >A few comments on an otherwise excellent draft: > >2. Introduction >=============== >You might want to differentiate between cold VM mobility - VM is stopped >or paused, moved to another hypervisor/cluster/DC and restarted/resumed - >where IP address preservation is desired or required, and hot VM >mobility, where a running VM is moved to another location >(hypervisor/cluster/DC). Fundamental differences between the two are: > >* Convergence time requirements - obviously highly relevant to hot VM >mobility but not for the cold case; >* ARP cache expiration - after a cold VM move, the hypervisor can bounce >the VM virtual LAN interface (the TCP sessions are gone anyway) hopefully >clearing the ARP cache. > >You might also want to mention storage-related issues (the moved VM has >to have access to the same virtual disk), obviously in the "out-of-scope" >part of the introduction. > >2.1 Terminology >=============== >You might want to make the ToR definition more precise in case of >port/fabric extenders. Reference to "controlling bridge" from EVB and >802.1BR would probably make most sense. > >Also, when defining L2 CUG, it would make sense to specify whether a VM >participating in multiple L2 CUGs has multiple (logical) interfaces (one >per L2 CUG), requiring simple VPNs, or one interface in multiple L2 CUGs, >requiring overlapping VPNs. > >The rest of the text implies a VLAN-per-CUG approach, which translates >into logical interface per L2 CUG, but it might be worth spelling out. > >3.1 VLAN IDs >============ >I would assume that most people familiar with network virtualization come >to an immediate conclusion that you either need multiple (non-tagged) >interfaces per VM or a VLAN-tagged VM interface, but these conclusions >might be worth documenting. > >3.4 Optimal IP routing >====================== >There might be cases where the only L3-7 networking device between a VM >and the outside world is a router (in which case the optimal IP routing >is the biggest problem you have), but in most cases the headaches are >caused by stateful devices in the path (load balancers, address >translators and/or firewalls). > >Solving optimal IP routing is "easy" (at least we have demonstrable >solutions), network device state transfer and session preservation on hot >VM move is a much harder problem (with the exception of a >hypervisor-based firewall). > >It would make sense to either expand the problem statement to include >stateful devices, or make them explicitly out-of-scope. > >Kind regards, >Ivan > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Yakov Rekhter >> Sent: Monday, August 20, 2012 9:49 PM >> To: [email protected] >> Subject: [nvo3] draft-rekhter-nvo3-vm-mobility-issues-00.txt >> >> fyi, and comments... >> ------- Forwarded Message >> >> Date: Mon, 20 Aug 2012 12:44:08 -0700 >> From: [email protected] >> To: [email protected] >> Subject: I-D Action: draft-rekhter-nvo3-vm-mobility-issues-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Network-related VM Mobility Issues >> Author(s) : Yakov Rekhter >> Wim Henderickx >> Ravi Shekhar >> Luyuan Fang >> Linda Dunbar >> Ali Sajassi >> Filename : draft-rekhter-nvo3-vm-mobility-issues-00.txt >> Pages : 10 >> Date : 2012-08-20 >> >> 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". >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-rekhter-nvo3-vm-mobility-issues >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-rekhter-nvo3-vm-mobility-issues-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> ------- End of Forwarded Message >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
