Hello Pat Thaler: Thank you for your comments, I will feedback them in turn.
We can accomplish L3-migration by the suggested technologies listed in my draft, combined with technologies like VXLAN and NVGRE. They are not contradictory. There is a problem with NVGRE alluded to but not explained: And, NVGRE “[draft-sridharan-virtualization-nvgre-00] attempts to solve similar problems, but artificially causes interoperability problems between domains.” Why? The method of a VXLAN connecting external devices is to use virtual L3 network equipments, such as vShield Edge and F5 load balancer. One vNIC is required in one physical VLAN, however, one or more vNICs are required in VXLAN. Based on some premises, we can run VXLAN in any extension IP network: Based on the premise that multicast is supported between data centers, a remote VM migration can be implemented by Vxlan technology. But the long-distance traffic delay cannot be handled by VXLAN. However, it must be able to do this when VM migrates between multiple data centers in the same logical subnet. To realize seamless migration in wide range is one of our goals, but currently VM migration tools is likely to require: the distance between two places cannot be more than 50KM (or a larger value, but not too much). We know that disaster recovery point should be as far as possible from the local. Are we going to accomplish remote VM migration through multiple relay backup? I hope it will not be so much trouble. On Wed, Oct 24, 2012 at 6:58 AM, Pat Thaler <[email protected]> wrote: > 3 – migration from system to system that stays within the same data > center and administrative domain isn’t listed.**** > > ** ** > > In 3 (C), IEEE 802.1Q PBB already provides for a larger (24-bit) ID when > the 12-bit VLAN ID isn’t large enough. VXLAN and NVGRE aren’t needed to > address that problem. What VXLAN and NVGRE provide that PBB doesn’t is the > ability to carry L2 over an underlying layer 3 network – so VXLAN and NVGRE > should be in (D) but aren’t.**** > > ** ** > > There is a problem with NVGRE alluded to but not explained: And, NVGRE**** > > “[draft-sridharan-virtualization-nvgre-00] attempts to solve similar*** > * > > problems, but artificially causes interoperability problems between**** > > domains.”**** > > Why?**** > > ** ** > > Also, 24 bits is to address the scaling needs within an administrative > domain. It isn’t clear that it provides enough space to allocate compatible > assignments between administrative domains. Mapping may be needed at the > boundary between administrative domains.**** > > ** ** > > (E) Aren’t A through D about mobility of VMs? I don’t see what this adds.* > *** > > ** ** > > 3.1**** > > “In addition, when re-configuring the VLAN in the traditional DC**** > > network, STP (MSTP) will lead to the VLAN isolation. It is a very**** > > serious problem in the DC network, especially in the storage network,** > ** > > because the services that storage networks support demand**** > > uninterrupted operation. In the Cloud computing and DC network, the*** > * > > problem with VM migration is fatal.”**** > > ?? STP or MSTP don’t cause VLAN isolation and IEEE 802.1Q defines MVRP to > handle dynamic configuration and distribution of VLAN membership > information. That there are times when a data center operator chooses to > structure their data center(s) with multiple layer 3 subnets and make that > transparent to VMs operating in their own IP address space doesn’t need to > be justified by attacking the capabilities of Layer 2.**** > > ** ** > > “For example, in the process of VM migration in IDC, there are**** > > scenarios that VM in the traditional three-tier topological network**** > > is migrated through WAN to Fat-Tree topological network, or to a**** > > variety of other topological networks. For the seamless online**** > > migration in these scenarios, a very intelligent seamless VM online**** > > migration is needed to be implemented on the control plane.”**** > > ** ** > > Lacks specificity – what problem is posed here and what features need to > be provided in the control plane to solve it?**** > > ** ** > > “If VM migration is only implemented in the L2 domain, its concern on**** > > the network is that the expansion of the number of VLANs or isolated**** > > domains, such as the 16,000,000 isolated domains in PBB.”**** > > 24 bits is the same size as used by VXLAN and NVGRE so they also provide > for 16 million tenant domains.**** > > **** > > “How the source network environment adapts its configuration to the**** > > target environment?”**** > > What do you mean by source network environment – “source” is used in the > Framework and problem statement as the sending end of the data plane path; > i.e. as source and destination, but that doesn’t seem to be how you are > using it here. Also explain “target environment”.**** > > ** ** > > 3.1.2 Part of the purpose of NVO is to make VM addresses independent of > the underlying network addressing or routing and we have examples that do > so by using an outer IP address for routing. Furthermore, we want these > addresses to remain unchanged on moves so location independence for them is > a requirement. This section appears to be saying that they still should be > location and underlying topology dependent and I disagree. The only > constraint on them should be to be unique within the virtual network.**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Richard Bin liu > *Sent:* Thursday, October 18, 2012 9:44 AM > *To:* [email protected] > *Subject:* [nvo3] draft-khasnabish-vmmi-problems-02**** > > ** ** > > Greeting all, > > > We had published this draft and wanted to bring it to the NVO3 WG's > attention. We plan to present/discuss this draft at the upcoming meeting > as well, consequently please discuss here on the maillist as well. > > Thanks, > > Bhumip Khasnabish, et al. > > > A new version of I-D, draft-khasnabish-vmmi-problems-02.txt > has been successfully submitted by Bin Liu and posted to the > IETF repository. > Filename: draft-khasnabish-vmmi-problems > Revision: 02 > Title: Requirements for Mobility and Interconnection of Virtual > Machine and Virtual Network Elements > Creation date: 2012-10-15 > WG ID: Individual Submission > Number of pages: 46 > URL: > http://www.ietf.org/internet-drafts/draft-khasnabish-vmmi-problems-02.txt > Status: > http://datatracker.ietf.org/doc/draft-khasnabish-vmmi-problems > Htmlized: > http://tools.ietf.org/html/draft-khasnabish-vmmi-problems-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-khasnabish-vmmi-problems-02 > Abstract: > In this draft, we discuss the challenges and requirements related to > migration, mobility, and interconnection of Virtual Machines (VMs)and > Virtual Network Elements (VNEs). VM migration scheme across IP > subnets is needed to implement virtual computing resources sharing > across multiple network administrative domains. For the seamless > online migration in various scenarios, many problems are needed to be > resolved on the control plane. The VM migration process should be > adapted to these aspects. We also describe the limitations of > various types of virtual local area networking (VLAN) and virtual > private networking (VPN) techniques that are traditionally expected > to support such migration, mobility, and interconnections.**** > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
