Hi Dave, Thank you for your comments, I will put them as update file reference. As your comment:
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. I have read some standards, found that also provides state machine process, although there will be different when people complete the actual function. Could I change it to optional reference suggest? “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. **** Yes, I had read the draft, so, the description should be deleted. And other repeated place should be merged. Many thanks for guidance. Regard. Richard On Fri, Oct 26, 2012 at 4:22 AM, Martin, David <[email protected]> wrote: > 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
