Ivan, Thank you very much for the comments. Responses to your comments are inserted below:
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Ivan Pepelnjak > Sent: Tuesday, August 21, 2012 10:10 AM > To: 'Yakov Rekhter'; [email protected] > Subject: [nvo3] Comments to draft-rekhter-nvo3-vm-mobility-issues- > 00.txt > > 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; [Linda] Can you be specific on which issues described by the draft are impacted by the "convergence time"? If VMs maintain the same IP addresses in the new location, regardless of "Hot" or "Cold" with different convergence time, all the issues described in the draft still exists: e.g. Usage of VLAN-IDs, L2 extension, and the Optimal routing (in-bound & out-bound), etc > * 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. [Linda] With Hot migration, most, it not all, hypervisors today send out a gratuitous ARP when the new VMs are instantiated in the new place. So the Cache would have been refreshed. Besides, you can't depend on various ARP cache timer in different OSs. Therefore you can't say that because it is "cold" migration therefore no need to address wrong cache entries. > > 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. [Linda] I thought the draft stated that "storage issues are out of the scope" in the last paragraph of "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. [Linda] Do you refer to IEEE802.1Qbg? The TOR in this draft doesn't mean the "controlling bridge". The ToR is the first external switch connecting to servers. Of course, servers could be embedded with blade switch or virtual switch. The "controlling bridge" have different meaning. > > 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. [Linda] The draft states " If a given VM is a member of more than one L2-based CUG, this VM would have multiple IP addresses, one per each such CUG.". If network administrator needs to map multiple "subnets" to "one VPN", they can. They can also map one "subnet" to "one VPN". > > 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. [Linda] Do you mean each VM have multiple (non-tagged) physical interfaces? Thanks, Linda > > 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
