Gary, Response to your comments are inserted below:
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Gary Berger (gaberger) > Sent: Tuesday, August 21, 2012 4:49 PM > To: Ivan Pepelnjak; 'Yakov Rekhter'; [email protected] > Subject: [nvo3] Comments on Live Migration and VLAN-IDs > > 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 [Linda] Most likely, if not all, the storage interfaces are separate from front end access. Very often they are even on different physical ports of a server. So a VM's ISCSI port and VLAN is different from the VM's front-end interface to other peers in same CUG or different CUGs. The draft deals with the VMs front-end IP addresses, VLANs, etc for communication between End Stations (or peers). The draft states clearly that the how far VMs can move and back-end interfaces are out of the scope of draft. > 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. > > [Linda] The "TOR" in the draft refers to a physical switch connected to servers on a rack. The serves can be hosting one OS, or multiple OSs (in the form of VM). The servers can have embedded virtual switches, VEPA, or none at all. > 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? [Linda] Yes, it might be better with different identifier other than VLAN. But we have to deal with existing OSs sending out IEEE802.1Q VID encoded data frames, and virtual switches deployed today attaching IEEE802.1Q VIDs. Linda Dunbar > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
