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
