Hi Richard, A few comments in blue text/[DWM].
Clause 3.5 The Evolution Problems... "Note that although Ethernet and IP protocols are meant to support arbitrary topology, these Layer-2 and Layer-3 network protocols are not flexible enough for use in Data Center environments. The lack of flexibility may result in lack of scalability, management difficulties, inflexible communications, and poor fault tolerance." [DWM] This is a rather broad statement and should really be followed by a detailed critique of the issues - although I suppose that's the goal of the document. In any case, just so you're aware, besides the Equal Cost Trees outlined in SPB (which are Backbone Edge Bridge to BEB in extent), there is a project in-flight to add support for hop-by-hop ECMP (P802.1Qbp). Clauses 3.6.1, 3.6.2 Requirements... [DWM] I didn't find any actual equipment requirements, just brief descriptions of what the equipment does. Clause 3.6.4 Fault Tolerance... "After the VM migration, it is required to consider the impact on the switching network, such as whether the new network environment will have the problem of insufficient bandwidth." [DWM] Good one, although it isn't really fault-related. The Virtual Station Interface Discovery and Configuration Protocol (VDP) that Pat mentioned from 802.1Qbg can be used by the target HV to register the migrating VM/VSI with the physical port on the attached bridge (e.g., ToR). That protocol exchange includes the VM/VSI Type which can be used by the switching network management system to allocate resources accordingly. All this can be performed at the destination prior to the VM migration using the 'pre-associate with resource reservation' VDP TLV type. Clause 3.6.10.2 Requirements for Live Migration of Virtual Machines [DWM] The list should include more than just the requirement to have an IP address. For example, the maximum latency between source DC and destination DC hypervisors is 10ms RTT for a VMware vSphere 5.0 vMotion. Clause 3.6.11 Access and Migration of VMs without users' Perception [DWM] There should be a target requirement for the application pause time (aka VM blackout time) experienced by the user, for example <4 seconds. Clause 3.6.13 The East-West Traffic Problem "In addition, TRILL..., nor it provides any solution to the requirement of supporting more than 4K VLANs." [DWM] You should take a look at the draft-ietf-trill-fine-labeling-00 (December 8, 2011) which added the EX-Tag. Clause 3.6.18 Routing Control - Multicast Processing "There also exist additional overheads because each customer multicast group is associated with the forwarding tree network throughout the Ethernet switching network. Consequently, development and standardization of efficient Layer-2 multicast mechanism to support intra- and inter-DC VM mobility would be very useful." [DWM] I don't follow these statements. Efficient multicast is an advantage of a bridged network, as opposed to source replication. What specific improvement would VM mobility need? Clause 3.6.19 Problems and Requirement related to DMTF [DWM] Why is this in an IETF draft? Clauses 4.1.1 - 4.1.3 Migration... [DWM] While the inspection, authentication and resource allocation steps are necessary, a HV can only do what's within its span of control (leveraging 802.1Qbg). Only the VM cluster manager and higher level DC management applications (e.g., vCloud Director) have a broad enough scope to do all this. Clause 4.1.4 Standardization of Migration State [DWM] Is the intent to standardize the steps of a VM migration? It's a very vendor specific operation. Clauses 4.2 - 4.3 Mobility... [DWM] Suggest deleting these as they repeat material from clause 3. ...Dave From: [email protected] [mailto:[email protected]] On Behalf Of Richard Bin liu Sent: Thursday, October 18, 2012 12:44 PM 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
