Or say, only move a VM within hub site or within a spoke site. Lucy
> -----Original Message----- > From: Linda Dunbar > Sent: Thursday, October 04, 2012 4:02 PM > To: Lucy yong; Yakov Rekhter > Cc: [email protected] > Subject: RE: [nvo3] comment on rekhter-vm-mobility > > For the NVO with hub-spoke topology configured by operator, like the > scenario in Aldrin's PoC case, maybe it is better for those VMs not to > move. > > Linda > > > -----Original Message----- > > From: Lucy yong > > Sent: Thursday, October 04, 2012 1:42 PM > > To: Linda Dunbar; Yakov Rekhter > > Cc: [email protected] > > Subject: RE: [nvo3] comment on rekhter-vm-mobility > > > > Linda, > > > > > > I think you are making it more complicated than it needs to. > > [Lucy] I don't think so. Look at Aldrin POC case. Hub-Spoke is used. > > > > > > Traditional VPN hub-spoke is defined (or configured) by the network > > > operators. > > > > > > But the "Hub-Spoke" relationship among a group of VMs (or hosts) > are > > > triggered by hosts (VMs) themselves, such as IGMP Join/Leave, > instead > > > of by network operators. > > [Lucy] my text does not apply to this case. The case I give is that > DC > > may configure a NVO with hub-spoke topology instead of a full mesh > > topology. > > > > > > When hosts (VMs) need to form their own Hub-Spoke relationship, > they > > > send out IGMP Join/Leave report. VMs migrated to the new location > can > > > send out a new IGMP Report (Join), then all the switches will learn > > the > > > relationship. > > > > > > VMware Hypervisor even triggers a fake IGMP Query after a new VM is > > > instantiated on the local server, so the IGMP Report can be sent > out > > > quickly for all the switches to update the "hub-spoke" relationship. > > > > > > > > > I don't think network operators need to configure the Hub-Spokes > > > relationship for all the VMs groups. There will be too many, not > > > scalable. Besides, VMs leased out to clients are totally under the > > > control of clients, which is not under the control of network > > operators. > > [Lucy] Again, look Aldrin's PoC case. I agree that there are a lot of > > applications that just need a full-mesh topology. However, other > > applications may need different topologies. That is why it is worth > to > > point out it in the document, so both tenant operator and network > > operator are aware that vm moves may break the policy designed > > originally or may cause some unexpected problem. > > > > Lucy > > > > > > Linda > > > > > > > -----Original Message----- > > > > From: Lucy yong > > > > Sent: Thursday, October 04, 2012 11:03 AM > > > > To: Yakov Rekhter > > > > Cc: [email protected]; Linda Dunbar > > > > Subject: RE: [nvo3] comment on rekhter-vm-mobility > > > > > > > > Hi Yakov, > > > > > > > > > -----Original Message----- > > > > > From: [email protected] [mailto:[email protected]] On > > > Behalf > > > > Of > > > > > Yakov Rekhter > > > > > Sent: Thursday, October 04, 2012 10:32 AM > > > > > To: Lucy yong > > > > > Cc: [email protected]; Linda Dunbar > > > > > Subject: Re: [nvo3] comment on rekhter-vm-mobility > > > > > > > > > > Lucy, > > > > > > > > > > > Hi Linda and Yakov, > > > > > > > > > > > > Beside previous comment. I also want to add other two > comments > > or > > > > say > > > > > two s= > > > > > > uggestions. > > > > > > > > > > > > > > > > > > 1) Suggest to add a new section (section 3.5) to > address > > > > policy > > > > > impact. > > > > > > It can describe that although a virtual overlay network can > be > > > > > implemented > > > > > > with a full mesh topology in general, it is possible to > > implement > > > > > with > > > > > > different topologies by using policy. This is very often > cases > > in > > > > > IP/MPLS > > > > > > L3VPN, which allows tenant implementing firewall, security > > > control, > > > > > gateway > > > > > > function, and etc in certain places. However, the policy > > > > implemented > > > > > topology > > > > > > may cause the performance change significantly when moving > VMs. > > > For > > > > > example, > > > > > > when an NVO is implemented with hub-spoke topology, moving a > VM > > > > from > > > > > a > > > > > > Hub NVE place to a spoke NVE place will conduct the > > > communication > > > > > from a > > > > > > VM in other spoke NVE places to go through the hub-NVE first, > > > which > > > > > may cause > > > > > > observable traffic delay. This performance change is caused > by > > > the > > > > > policy, > > > > > > which is different from the performance change due to > physical > > > > > location.= > > > > > > > > > > What you described in the above seems like changing VM from > being > > a > > > > hub > > > > > to being a spoke. This has nothing to do with VM mobility, as > > > > changing > > > > > VM from being a hub to being a spoke could be accomplished > > without > > > > > moving VM at all, but by just changing import/export RTs of the > > > > EVI/VRF > > > > > associated with the VM. > > > > [Lucy] Let me make it clear. What I want to say is about moving a > > VM > > > at > > > > a hub site to a spoke site. This is not about if an operator want > > to > > > > change a hub site into a spoke site. > > > > > > > > > > > In addition, another VM on the same spoke NVE now can > > directly > > > > talk > > > > > to the > > > > > > moved VM without going through hub-NVE, which may impact the > > > > initial > > > > > design > > > > > > goal. I think this is fairly important to describe in this > > > > document, > > > > > so > > > > > > DC operator has to pay attention on these factors when moving > > VMs. > > > > > > > > > > > > > > > > Two spokes should not allow to talk to each other directly, > > > > > irrespective > > > > > of the location of these two spokes. And if they do, then there > > is > > > > > an implementation bug. As a side comment, in the context of > > > > > "usual" 2547 VPN that means that even if two spokes are > > connected > > > to > > > > > the same PE, they can not talk to each other directly (via this > > PE). > > > > [Lucy] good point. Setting a policy at spoke site can achieve > that. > > > > However, in L3VPN case, SP VPN may not able to limit hosts at CE > > site > > > > to communicate each other in the CE network (without touch VPN at > > > all). > > > > Thus, the main purpose of hub-spoke implementation is to prohibit > > the > > > > communication between two spoke sites directly in my opinion. > > > > > > > > > > > > > > > > 2) The doc. should mention that when a VM moves from one > > > > server > > > > > to ano= > > > > > > ther server, if the destination virtual network is > implemented > > > with > > > > > differe= > > > > > > nt address family, VM IP address has to change to match the > > > > > destination net= > > > > > > work supported address family. For example, a VM with IPv4 > > > > address > > > > > is mo= > > > > > > ved to an virtual network that supports IPv6 only. (I know > this > > > is > > > > > obvious,= > > > > > > but it should be the rule) > > > > > > > > > > The scope of the draft is on seamless mobility, and seamless > > > mobility, > > > > > by definition, means that VM's IP address does not change. From > > > > > section 2: > > > > > > > > > > .... seamless mobility > > is > > > > > defined as the ability to move a VM from one server in the > > data > > > > > center to another server in the same or different data > center, > > > > while > > > > > retaining the IP and MAC address of the VM. > > > > > > > > > > Changing VM's IP address family would certainly imply changing > > VM's > > > > > IP address, and thus is outside the scope of the draft. > > > > [Lucy] I see. I did not read this carefully. Agree that is > outside > > > the > > > > scope of the draft. > > > > > > > > Lucy > > > > > > > > > > > It is good we have one document to capture all VM mobility > > issues > > > > > that DC o= > > > > > > perators need to know. > > > > > > > > > > Yakov. > > > > > > > > > > > > > > > > > Regards, > > > > > > Lucy > > > > > > > > > > > > > > > > > > > > > > > > From: Linda Dunbar > > > > > > Sent: Wednesday, October 03, 2012 3:13 PM > > > > > > To: Linda Dunbar; Lucy yong; Yakov Rekhter > > > > > > Cc: [email protected] > > > > > > Subject: RE: comment on rekhter-vm-mobility > > > > > > > > > > > > One more point, if destination VMs don't expect VIDs, then > the > > > NVE > > > > > can remo= > > > > > > ve the VID encoded in the data frame after the decapsulation, > > > > > regardless wh= > > > > > > ere NVE is. Of course, if NVE is many hops away from the VMs, > > > there > > > > > is high= > > > > > > er chance that the local VID is needed in the data frame > after > > > the > > > > > decapsul= > > > > > > ation. > > > > > > > > > > > > Linda > > > > > > > > > > > > From: Linda Dunbar > > > > > > Sent: Wednesday, October 03, 2012 3:10 PM > > > > > > To: Lucy yong; Yakov Rekhter > > > > > > Cc: [email protected] > > > > > > Subject: RE: comment on rekhter-vm-mobility > > > > > > > > > > > > Lucy, > > > > > > > > > > > > If the destination VMs also expect VIDs in the data frame, > the > > > > target > > > > > NVE (= > > > > > > or egress NVE) should not take away the VID embedded in the > > data > > > > > frames, re= > > > > > > gardless where NVE is. > > > > > > > > > > > > The point is that the VIDs used by those VMs are globally > > > > significant. > > > > > > > > > > > > LInda > > > > > > > > > > > > From: Lucy yong > > > > > > Sent: Wednesday, October 03, 2012 2:57 PM > > > > > > To: Linda Dunbar; Yakov Rekhter > > > > > > Cc: [email protected] > > > > > > Subject: RE: comment on rekhter-vm-mobility > > > > > > > > > > > > Linda, > > > > > > > > > > > > Regardless the frame from VM having VID or not, the frame is > > > > > encapsulated a= > > > > > > t NVE and sent to a peer NVE. If peer NVE is also on a > server, > > > it > > > > > can pass= > > > > > > the frame to VM directly based on the destination address. > > > > Therefore, > > > > > the = > > > > > > VID is not used at all. > > > > > > > > > > > > I agree if the peer NVE is on ToR, it will send the frame to > a > > > VLAN > > > > > identif= > > > > > > ied by VID in order to reach that VM. Thus, the rules are > > caused > > > by > > > > > physica= > > > > > > l network configuration. Is that right? > > > > > > > > > > > > That is my point. The draft should clarify this. Do you agree? > > > > > > > > > > > > Lucy > > > > > > > > > > > > From: Linda Dunbar > > > > > > Sent: Wednesday, October 03, 2012 2:48 PM > > > > > > To: Lucy yong; Yakov Rekhter > > > > > > Cc: [email protected] > > > > > > Subject: RE: comment on rekhter-vm-mobility > > > > > > > > > > > > Lucy, > > > > > > > > > > > > For VMs instantiated with applications which need to sit in > > > > multiple > > > > > subnet= > > > > > > s, the VIDs are encoded in the data frames sent out from the > > VMs. > > > > For > > > > > this = > > > > > > scenario, even if the NVE is on server, VIDs are there > between > > > VMs > > > > > and Virt= > > > > > > ual Switch. > > > > > > > > > > > > Linda > > > > > > > > > > > > From: [email protected] [mailto:[email protected]] On > > > > Behalf > > > > > Of Luc= > > > > > > y yong > > > > > > Sent: Monday, October 01, 2012 2:17 PM > > > > > > To: Yakov Rekhter > > > > > > Cc: [email protected] > > > > > > Subject: [nvo3] comment on rekhter-vm-mobility > > > > > > > > > > > > Hi Yakov, > > > > > > > > > > > > It is carefully written about L2-based CUG. > > > > > > > > > > > > The scenarios that the draft describe are about that VMs in a > > CUG > > > > are > > > > > expos= > > > > > > ed to a physical network, as it is referred to "L2 physical > > > domain" > > > > > in the = > > > > > > doc. To use NVO3 framework terms, it is the case when NVE on > > TOR > > > > and > > > > > VM on= > > > > > > servers. The connection between Servers and TOR is via a > > > physical > > > > > wire whe= > > > > > > re VLAN is implemented. The draft describes the necessary > rules > > > of > > > > > usage of= > > > > > > VLAN-IDs to enable VM move in a L2-based CUG. I agree these > > > rules. > > > > > > > > > > > > Comment I want to give is that, one motivation to do NVO for > DC > > > is > > > > to > > > > > creat= > > > > > > e a true virtual network environment for the VMs in a closed > > > user > > > > > group to= > > > > > > communicate and to decouple the virtual environment from the > > > > > physical DC n= > > > > > > etworks which has a lot of constrain to support VM mobility. > > You > > > > > draft has= > > > > > > specified these necessary constrains. However, if we just > > want > > > to > > > > > impleme= > > > > > > nt in this way, we do not achieve our objective here: to > create > > a > > > > > true virt= > > > > > > ual network environment that is decoupled from a physical > > network. > > > > > > > > > > > > It is clear that, in nvo3, we want to support that NVE is on > > > Server. > > > > > In thi= > > > > > > s case, it will create a true virtual networking for VM > > > > > communications. The= > > > > > > traffic from a VM will not directly expose on a wire and DC > > > > switches > > > > > any m= > > > > > > ore. Thus, VM mobility does not face these VLAN ID issues and > > no > > > > need > > > > > such = > > > > > > constrains. It will be good for the draft to point out or > > clarify > > > > > that. > > > > > > > > > > > > Assuming an NVE is on server, a VM can be moved from one > > server > > > > to > > > > > anothe= > > > > > > r if NVEs on both servers are members of the same VN or if > NVEs > > > on > > > > > the both= > > > > > > servers are member of different VNs but two VNs have > > > > interconnection. > > > > > I th= > > > > > > ink that the draft should mention this case and distinct it > > from > > > > when > > > > > NVE i= > > > > > > s on ToRs. > > > > > > > > > > > > In section 3.3, the scenarios should cover both when another > > > server > > > > > is not = > > > > > > in the L2 physical domain or in the different L2 physical > > domain > > > > > that are = > > > > > > connected to this L2 physical domain. IMO, two have > different. > > > The > > > > > first c= > > > > > > ase need to let NVE on server to join the L3 physical domain > > > first. > > > > > > > > > > > > I think, this draft motivates us more to have NVE on server > > when > > > DC > > > > > operato= > > > > > > r want to a lot of vm mobility for resource and performance > > > > > optimization. = > > > > > > Without NVE on server, you have these constrains (or rules) > to > > > deal > > > > > with. I= > > > > > > ETF is to work out the solutions that allow these > configuration > > > and > > > > > device = > > > > > > still can interwork under different configurations. It is up > to > > > DC > > > > > operator= > > > > > > to chose which configuration is proper for their business. > > > > > > > > > > > > I agree, regardless of NVE on server or on ToR, the issue in > > > > section > > > > > 3.4 we= > > > > > > need to solve in nvo3 solution. > > > > > > > > > > > > Regards, > > > > > > Lucy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --_000_2691CE0099834E4A9C5044EEC662BB9D44816464dfweml505mbx_ > > > > > > Content-Type: text/html; charset="us-ascii" > > > > > > Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > <html xmlns:v=3D"urn:schemas-microsoft-com:vml" > > > > > xmlns:o=3D"urn:schemas-micr= > > > > > > osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft- > > > > > com:office:word" = > > > > > > xmlns:x=3D"urn:schemas-microsoft-com:office:excel" > > > > > xmlns:p=3D"urn:schemas-m= > > > > > > icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas- > > microsoft- > > > > > com:office= > > > > > > :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F- > 00AA00C14882" > > > > > xmlns:s=3D"= > > > > > > uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" > > > xmlns:rs=3D"urn:schemas- > > > > > microsof= > > > > > > t-com:rowset" xmlns:z=3D"#RowsetSchema" > xmlns:b=3D"urn:schemas- > > > > > microsoft-co= > > > > > > m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft- > > > > > com:office:spreadshee= > > > > > > t" xmlns:c=3D"urn:schemas-microsoft- > > > > com:office:component:spreadsheet" > > > > > xmlns= > > > > > > :odc=3D"urn:schemas-microsoft-com:office:odc" > > > > > xmlns:oa=3D"urn:schemas-micro= > > > > > > soft-com:office:activation" > > > xmlns:html=3D"http://www.w3.org/TR/REC- > > > > > html40" = > > > > > > xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/"; > > > > > xmlns:rtc=3D"http://m= > > > > > > icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" > > > > > xmlns:Repl=3D"http://= > > > > > > schemas.microsoft.com/repl/" > > > > > xmlns:mt=3D"http://schemas.microsoft.com/share= > > > > > point/soap/meetings/" > > > > > xmlns:x2=3D"http://schemas.microsoft.com/office/excel= > > > > > > /2003/xml" > xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd"; > > > > > xmlns:ois= > > > > > > =3D"http://schemas.microsoft.com/sharepoint/soap/ois/"; > > > > > xmlns:dir=3D"http://= > > > > > > schemas.microsoft.com/sharepoint/soap/directory/" > > > > > xmlns:ds=3D"http://www.w3= > > > > > > .org/2000/09/xmldsig#" > > > > > xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= > > > > > > /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc"; > > > > > xmlns:xsd=3D"http= > > > > > > ://www.w3.org/2001/XMLSchema" > > > > > xmlns:sub=3D"http://schemas.microsoft.com/sha= > > > > > > repoint/soap/2002/1/alerts/" > > > > > xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= > > > > > > xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/"; > > > > > xmlns:sps=3D"http://= > > > > > > schemas.microsoft.com/sharepoint/soap/" > > > > > xmlns:xsi=3D"http://www.w3.org/2001= > > > > > > /XMLSchema-instance" > > > > > xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= > > > > > > ap" > > xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile"; > > > > > xmlns:udc= > > > > > > p2p=3D"http://schemas.microsoft.com/data/udc/parttopart"; > > > > > xmlns:wf=3D"http:/= > > > > > > /schemas.microsoft.com/sharepoint/soap/workflow/" > > > > > xmlns:dsss=3D"http://sche= > > > > > > mas.microsoft.com/office/2006/digsig-setup" > > > > > xmlns:dssi=3D"http://schemas.mi= > > > > > > crosoft.com/office/2006/digsig" > > > > > xmlns:mdssi=3D"http://schemas.openxmlformat= > > > > > > s.org/package/2006/digital-signature" > > > > > xmlns:mver=3D"http://schemas.openxmlf= > > > > > > ormats.org/markup-compatibility/2006" > > > > > xmlns:m=3D"http://schemas.microsoft.c= > > > > > > om/office/2004/12/omml" > > > > > xmlns:mrels=3D"http://schemas.openxmlformats.org/pa= > > > > > > ckage/2006/relationships" > > > > > xmlns:spwp=3D"http://microsoft.com/sharepoint/web= > > > > > > partpages" > > > > > > xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20= > > > > > > 06/types" > > > > > > > xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200= > > > > > > 6/messages" > > > > > > xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli= > > > > > > deLibrary/" > > > > > > xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal= > > > > > > Server/PublishedLinksService" xmlns:Z=3D"urn:schemas- > microsoft- > > > > com:" > > > > > xmlns:= > > > > > > st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40";> > > > > > > <head> > > > > > > <meta http-equiv=3D"Content-Type" content=3D"text/html; > > > > charset=3Dus- > > > > > ascii"= > > > > > > > > > > > > > <meta name=3D"Generator" content=3D"Microsoft Word 12 > (filtered > > > > > medium)"> > > > > > > <style><!-- > > > > > > /* Font Definitions */ > > > > > > @font-face > > > > > > {font-family:SimSun; > > > > > > panose-1:2 1 6 0 3 1 1 1 1 1;} > > > > > > @font-face > > > > > > {font-family:"Cambria Math"; > > > > > > panose-1:2 4 5 3 5 4 6 3 2 4;} > > > > > > @font-face > > > > > > {font-family:Calibri; > > > > > > panose-1:2 15 5 2 2 2 4 3 2 4;} > > > > > > @font-face > > > > > > {font-family:Tahoma; > > > > > > panose-1:2 11 6 4 3 5 4 4 2 4;} > > > > > > @font-face > > > > > > {font-family:"\@SimSun"; > > > > > > panose-1:2 1 6 0 3 1 1 1 1 1;} > > > > > > /* Style Definitions */ > > > > > > p.MsoNormal, li.MsoNormal, div.MsoNormal > > > > > > {margin:0in; > > > > > > margin-bottom:.0001pt; > > > > > > font-size:11.0pt; > > > > > > font-family:"Calibri","sans-serif";} > > > > > > a:link, span.MsoHyperlink > > > > > > {mso-style-priority:99; > > > > > > color:blue; > > > > > > text-decoration:underline;} > > > > > > a:visited, span.MsoHyperlinkFollowed > > > > > > {mso-style-priority:99; > > > > > > color:purple; > > > > > > text-decoration:underline;} > > > > > > p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph > > > > > > {mso-style-priority:34; > > > > > > margin-top:0in; > > > > > > margin-right:0in; > > > > > > margin-bottom:0in; > > > > > > margin-left:.5in; > > > > > > margin-bottom:.0001pt; > > > > > > font-size:11.0pt; > > > > > > font-family:"Calibri","sans-serif";} > > > > > > span.EmailStyle17 > > > > > > {mso-style-type:personal; > > > > > > font-family:"Calibri","sans-serif"; > > > > > > color:windowtext;} > > > > > > span.EmailStyle18 > > > > > > {mso-style-type:personal; > > > > > > font-family:"Calibri","sans-serif"; > > > > > > color:#1F497D;} > > > > > > span.EmailStyle19 > > > > > > {mso-style-type:personal; > > > > > > font-family:"Calibri","sans-serif"; > > > > > > color:#1F497D;} > > > > > > span.EmailStyle20 > > > > > > {mso-style-type:personal; > > > > > > font-family:"Calibri","sans-serif"; > > > > > > color:#1F497D;} > > > > > > span.EmailStyle21 > > > > > > {mso-style-type:personal; > > > > > > font-family:"Calibri","sans-serif"; > > > > > > color:#1F497D;} > > > > > > span.EmailStyle22 > > > > > > {mso-style-type:personal-reply; > > > > > > font-family:"Calibri","sans-serif"; > > > > > > color:#1F497D;} > > > > > > .MsoChpDefault > > > > > > {mso-style-type:export-only; > > > > > > font-size:10.0pt;} > > > > > > @page WordSection1 > > > > > > {size:8.5in 11.0in; > > > > > > margin:1.0in 1.0in 1.0in 1.0in;} > > > > > > div.WordSection1 > > > > > > {page:WordSection1;} > > > > > > /* List Definitions */ > > > > > > @list l0 > > > > > > {mso-list-id:844978255; > > > > > > mso-list-type:hybrid; > > > > > > mso-list-template-ids:1301811554 67698705 67698713 67698715 > > > > > 67698703 67 > > > > > 698= > > > > > > 713 67698715 67698703 67698713 67698715;} > > > > > > @list l0:level1 > > > > > > {mso-level-text:"%1\)"; > > > > > > mso-level-tab-stop:none; > > > > > > mso-level-number-position:left; > > > > > > text-indent:-.25in;} > > > > > > @list l1 > > > > > > {mso-list-id:1404599941; > > > > > > mso-list-type:hybrid; > > > > > > mso-list-template-ids:1484681866 67698705 67698713 67698715 > > > > > 67698703 67 > > > > > 698= > > > > > > 713 67698715 67698703 67698713 67698715;} > > > > > > @list l1:level1 > > > > > > {mso-level-text:"%1\)"; > > > > > > mso-level-tab-stop:none; > > > > > > mso-level-number-position:left; > > > > > > text-indent:-.25in;} > > > > > > @list l2 > > > > > > {mso-list-id:1429733409; > > > > > > mso-list-type:hybrid; > > > > > > mso-list-template-ids:-509829154 67698705 67698713 67698715 > > > > > 67698703 67 > > > > > 698= > > > > > > 713 67698715 67698703 67698713 67698715;} > > > > > > @list l2:level1 > > > > > > {mso-level-text:"%1\)"; > > > > > > mso-level-tab-stop:none; > > > > > > mso-level-number-position:left; > > > > > > text-indent:-.25in;} > > > > > > ol > > > > > > {margin-bottom:0in;} > > > > > > ul > > > > > > {margin-bottom:0in;} > > > > > > --></style><!--[if gte mso 9]><xml> > > > > > > <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> > > > > > > </xml><![endif]--><!--[if gte mso 9]><xml> > > > > > > <o:shapelayout v:ext=3D"edit"> > > > > > > <o:idmap v:ext=3D"edit" data=3D"1" /> > > > > > > </o:shapelayout></xml><![endif]--> > > > > > > </head> > > > > > > <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> > > > > > > <div class=3D"WordSection1"> > > > > > > <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hi Linda > > and > > > > > Yakov,<o:= > > > > > > p></o:p></span></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Beside > > > > previous > > > > > commen= > > > > > > t. I also want to add other two comments or say two > > > > > suggestions.<o:p></o:p>= > > > > > > </span></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <p class=3D"MsoListParagraph" style=3D"text-indent:- > .25in;mso- > > > > list:l1 > > > > > level= > > > > > > 1 lfo2"><![if !supportLists]><span > > style=3D"color:#1F497D"><span > > > > > style=3D"m= > > > > > > so-list:Ignore">1)<span style=3D"font:7.0pt "Times New > > > > > Roman"">&n= > > > > > > bsp; > > > > > > </span></span></span><![endif]><span > > > > style=3D"color:#1F497D">Suggest > > > > > to add= > > > > > > a new section (section 3.5) to address policy impact. > It > > > can > > > > > describ= > > > > > > e that although a virtual overlay network can be implemented > > > > > with a f= > > > > > > ull mesh topology in general, it is possible > > > > > > to implement with different topologies by using policy. This > > is > > > > very > > > > > often= > > > > > > cases in IP/MPLS L3VPN, which allows tenant implementing > > > firewall, > > > > > securit= > > > > > > y control, gateway function, and etc in certain places. > However, > > > > the > > > > > policy= > > > > > > implemented topology may cause > > > > > > the performance change significantly when moving VMs. For > > > example, > > > > > when an= > > > > > > NVO is implemented with hub-spoke topology, moving a VM from > a > > > Hub > > > > > NVE pla= > > > > > > ce to a spoke NVE place will conduct the communication > > from > > > a > > > > > VM in o= > > > > > > ther spoke NVE places to go through the > > > > > > hub-NVE first, which may cause observable traffic delay. > This > > > > > performance = > > > > > > change is caused by the policy, which is different from the > > > > > performance cha= > > > > > > nge due to physical location. In addition, another VM > on > > > the > > > > > same spo= > > > > > > ke NVE now can directly talk to the moved > > > > > > VM without going through hub-NVE, which may impact the > initial > > > > > design goal= > > > > > > . I think this is fairly important to describe in this > > > > document, > > > > > so D= > > > > > > C operator has to pay attention on these factors when moving > > > > > VMs.<o:p></o:p= > > > > > > ></span></p> > > > > > > <p class=3D"MsoListParagraph"><span > > > > > style=3D"color:#1F497D"><o:p> </o:= > > > > > > p></span></p> > > > > > > <p class=3D"MsoListParagraph" style=3D"text-indent:- > .25in;mso- > > > > list:l1 > > > > > level= > > > > > > 1 lfo2"><![if !supportLists]><span > > style=3D"color:#1F497D"><span > > > > > style=3D"m= > > > > > > so-list:Ignore">2)<span style=3D"font:7.0pt "Times New > > > > > Roman"">&n= > > > > > > bsp; > > > > > > </span></span></span><![endif]><span > > style=3D"color:#1F497D">The > > > > doc. > > > > > shoul= > > > > > > d mention that when a VM moves from one server to another > > server, > > > > if > > > > > the de= > > > > > > stination virtual network is implemented with different > address > > > > > family, VM = > > > > > > IP address has to change to match > > > > > > the destination network supported address > > > family. > > > > > For ex= > > > > > > ample, a VM with IPv4 address is moved to an virtual network > > that > > > > > supports = > > > > > > IPv6 only. (I know this is obvious, but it should be the > > > > > rule)<o:p></o:p></= > > > > > > span></p> > > > > > > <p class=3D"MsoListParagraph"><span > > > > > style=3D"color:#1F497D"><o:p> </o:= > > > > > > p></span></p> > > > > > > <p class=3D"MsoNormal"><span style=3D"color:#1F497D">It is > good > > > we > > > > > have one= > > > > > > document to capture all VM mobility issues that DC operators > > > need > > > > to > > > > > know.= > > > > > > <o:p></o:p></span></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D">Regards,<o:p></o:p></s= > > > > > > pan></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D">Lucy<o:p></o:p></span>= > > > > > > </p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <div> > > > > > > <div style=3D"border:none;border-top:solid #B5C4DF > > > > > 1.0pt;padding:3.0pt 0in = > > > > > > 0in 0in"> > > > > > > <p class=3D"MsoNormal"><b><span style=3D"font- > size:10.0pt;font- > > > > > family:"= > > > > > > ;Tahoma","sans-serif"">From:</span></b><span > > > > > style=3D"font-s= > > > > > > ize:10.0pt;font-family:"Tahoma","sans- > > serif""> > > > > > Linda Du= > > > > > > nbar > > > > > > <br> > > > > > > <b>Sent:</b> Wednesday, October 03, 2012 3:13 PM<br> > > > > > > <b>To:</b> Linda Dunbar; Lucy yong; Yakov Rekhter<br> > > > > > > <b>Cc:</b> [email protected]<br> > > > > > > <b>Subject:</b> RE: comment on rekhter-vm- > > > > > mobility<o:p></o:p></span></p> > > > > > > </div> > > > > > > </div> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal"><span style=3D"color:#1F497D">One more > > > point, > > > > > if des= > > > > > > tination VMs don’t expect VIDs, then the NVE can remove > > the > > > > VID > > > > > encod= > > > > > > ed in the data frame after the decapsulation, regardless > where > > > NVE > > > > is. > > > > > Of c= > > > > > > ourse, if NVE is many hops away from the VMs, > > > > > > there is higher chance that the local VID is needed in the > > data > > > > > frame afte= > > > > > > r the decapsulation. > > > > > > <o:p></o:p></span></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D">Linda<o:p></o:p></span= > > > > > > ></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <div style=3D"border:none;border-left:solid blue > > > 1.5pt;padding:0in > > > > > 0in 0in = > > > > > > 4.0pt"> > > > > > > <div> > > > > > > <div style=3D"border:none;border-top:solid #B5C4DF > > > > > 1.0pt;padding:3.0pt 0in = > > > > > > 0in 0in"> > > > > > > <p class=3D"MsoNormal"><b><span style=3D"font- > size:10.0pt;font- > > > > > family:"= > > > > > > ;Tahoma","sans-serif"">From:</span></b><span > > > > > style=3D"font-s= > > > > > > ize:10.0pt;font-family:"Tahoma","sans- > > serif""> > > > > > Linda Du= > > > > > > nbar > > > > > > <br> > > > > > > <b>Sent:</b> Wednesday, October 03, 2012 3:10 PM<br> > > > > > > <b>To:</b> Lucy yong; Yakov Rekhter<br> > > > > > > <b>Cc:</b> [email protected]<br> > > > > > > <b>Subject:</b> RE: comment on rekhter-vm- > > > > > mobility<o:p></o:p></span></p> > > > > > > </div> > > > > > > </div> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Lucy, > > > > > <o:p></o:p></spa= > > > > > > n></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <p class=3D"MsoNormal"><span style=3D"color:#1F497D">If the > > > > > destination VMs= > > > > > > also expect VIDs in the data frame, the target NVE (or > egress > > > NVE) > > > > > should = > > > > > > not take away the VID embedded in the data frames, regardless > > > where > > > > > NVE is. > > > > > > <o:p></o:p></span></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"> <o:p></o:p></spa= > > > > > > n></p> > > > > > > <p class=3D"MsoNormal"><span style=3D"color:#1F497D">The > point > > is > > > > > that the = > > > > > > VIDs used by those VMs are globally significant. > > > > > > <o:p></o:p></span></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D">LInda<o:p></o:p></span= > > > > > > ></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <div style=3D"border:none;border-left:solid blue > > > 1.5pt;padding:0in > > > > > 0in 0in = > > > > > > 4.0pt"> > > > > > > <div> > > > > > > <div style=3D"border:none;border-top:solid #B5C4DF > > > > > 1.0pt;padding:3.0pt 0in = > > > > > > 0in 0in"> > > > > > > <p class=3D"MsoNormal"><b><span style=3D"font- > size:10.0pt;font- > > > > > family:"= > > > > > > ;Tahoma","sans-serif"">From:</span></b><span > > > > > style=3D"font-s= > > > > > > ize:10.0pt;font-family:"Tahoma","sans- > > serif""> > > > > > Lucy yon= > > > > > > g > > > > > > <br> > > > > > > <b>Sent:</b> Wednesday, October 03, 2012 2:57 PM<br> > > > > > > <b>To:</b> Linda Dunbar; Yakov Rekhter<br> > > > > > > <b>Cc:</b> [email protected]<br> > > > > > > <b>Subject:</b> RE: comment on rekhter-vm- > > > > > mobility<o:p></o:p></span></p> > > > > > > </div> > > > > > > </div> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D">Linda,<o:p></o:p></spa= > > > > > > n></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <p class=3D"MsoNormal"><span > style=3D"color:#1F497D">Regardless > > > the > > > > > frame f= > > > > > > rom VM having VID or not, the frame is encapsulated at NVE > and > > > sent > > > > > to a pe= > > > > > > er NVE. If peer NVE is also on a server, it can pass > the > > > > frame > > > > > to VM = > > > > > > directly based on the destination address. > > > > > > Therefore, the VID is not used at all. <o:p></o:p></span></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <p class=3D"MsoNormal"><span style=3D"color:#1F497D">I agree > if > > > the > > > > > peer NV= > > > > > > E is on ToR, it will send the frame to a VLAN identified by > VID > > > in > > > > > order to= > > > > > > reach that VM. Thus, the rules are caused by physical > network > > > > > configuratio= > > > > > > n. Is that right?<o:p></o:p></span></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <p class=3D"MsoNormal"><span style=3D"color:#1F497D">That is > my > > > > point. > > > > > The = > > > > > > draft should clarify this. Do you agree?<o:p></o:p></span></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D">Lucy<o:p></o:p></span>= > > > > > > </p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <div> > > > > > > <div style=3D"border:none;border-top:solid #B5C4DF > > > > > 1.0pt;padding:3.0pt 0in = > > > > > > 0in 0in"> > > > > > > <p class=3D"MsoNormal"><b><span style=3D"font- > size:10.0pt;font- > > > > > family:"= > > > > > > ;Tahoma","sans-serif"">From:</span></b><span > > > > > style=3D"font-s= > > > > > > ize:10.0pt;font-family:"Tahoma","sans- > > serif""> > > > > > Linda Du= > > > > > > nbar > > > > > > <br> > > > > > > <b>Sent:</b> Wednesday, October 03, 2012 2:48 PM<br> > > > > > > <b>To:</b> Lucy yong; Yakov Rekhter<br> > > > > > > <b>Cc:</b> [email protected]<br> > > > > > > <b>Subject:</b> RE: comment on rekhter-vm- > > > > > mobility<o:p></o:p></span></p> > > > > > > </div> > > > > > > </div> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D">Lucy,<o:p></o:p></span= > > > > > > ></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <p class=3D"MsoNormal"><span style=3D"color:#1F497D">For VMs > > > > > instantiated w= > > > > > > ith applications which need to sit in multiple subnets, the > > VIDs > > > > are > > > > > encode= > > > > > > d in the data frames sent out from the VMs. For this scenario, > > > even > > > > > if the = > > > > > > NVE is on server, VIDs are there between > > > > > > VMs and Virtual Switch. <o:p></o:p></span></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D">Linda<o:p></o:p></span= > > > > > > ></p> > > > > > > <p class=3D"MsoNormal"><span > > > > > style=3D"color:#1F497D"><o:p> </o:p></spa= > > > > > > n></p> > > > > > > <div style=3D"border:none;border-left:solid blue > > > 1.5pt;padding:0in > > > > > 0in 0in = > > > > > > 4.0pt"> > > > > > > <div> > > > > > > <div style=3D"border:none;border-top:solid #B5C4DF > > > > > 1.0pt;padding:3.0pt 0in = > > > > > > 0in 0in"> > > > > > > <p class=3D"MsoNormal"><b><span style=3D"font- > size:10.0pt;font- > > > > > family:"= > > > > > > ;Tahoma","sans-serif"">From:</span></b><span > > > > > style=3D"font-s= > > > > > > ize:10.0pt;font-family:"Tahoma","sans- > > serif""> > > > > > nvo3-bou= > > > > > > [email protected] [mailto:[email protected]] > > > > > > <b>On Behalf Of </b>Lucy yong<br> > > > > > > <b>Sent:</b> Monday, October 01, 2012 2:17 PM<br> > > > > > > <b>To:</b> Yakov Rekhter<br> > > > > > > <b>Cc:</b> [email protected]<br> > > > > > > <b>Subject:</b> [nvo3] comment on rekhter-vm- > > > > > mobility<o:p></o:p></span></p> > > > > > > </div> > > > > > > </div> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal">Hi Yakov,<o:p></o:p></p> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal">It is carefully written about L2-based > > CUG. > > > > > <o:p></o= > > > > > > :p></p> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal">The scenarios that the draft describe > > are > > > > > about that= > > > > > > VMs in a CUG are exposed to a physical network, as it is > > > referred > > > > to > > > > > ̶= > > > > > > 0;L2 physical domain” in the doc. To use NVO3 > > > framework > > > > > terms, = > > > > > > it is the case when NVE on TOR and VM on servers. The > > > > > > connection between Servers and TOR is via a physical wire > > where > > > > VLAN > > > > > is im= > > > > > > plemented. The draft describes the necessary rules of usage > of > > > > VLAN- > > > > > IDs to = > > > > > > enable VM move in a L2-based CUG. I agree these > > > > rules.<o:p></o:p></p> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal">Comment I want to give is that, one > > > > motivation > > > > > to do= > > > > > > NVO for DC is to create a true virtual network > > environment > > > > for > > > > > the V= > > > > > > Ms in a closed user group to communicate and to decouple the > > > > virtual > > > > > enviro= > > > > > > nment from the physical DC networks which > > > > > > has a lot of constrain to support VM mobility. You > draft > > > has > > > > > specifi= > > > > > > ed these necessary constrains. However, if we just want > > to > > > > > implement = > > > > > > in this way, we do not achieve our objective here: to create > a > > > true > > > > > virtual= > > > > > > network environment that is decoupled from > > > > > > a physical network.<o:p></o:p></p> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal">It is clear that, in nvo3, we want to > > > > support > > > > > that N= > > > > > > VE is on Server. In this case, it will create a true virtual > > > > > networking for= > > > > > > VM communications. The traffic from a VM will not directly > > > expose > > > > on > > > > > a wir= > > > > > > e and DC switches any more. Thus, > > > > > > VM mobility does not face these VLAN ID issues and no need > > such > > > > > constrains= > > > > > > . It will be good for the draft to point out or clarify > > > > > that.<o:p></o:p></p= > > > > > > > > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal">Assuming an NVE is on server, > > > a > > > > VM > > > > > can b= > > > > > > e moved from one server to another if NVEs on both servers > are > > > > > members of t= > > > > > > he same VN or if NVEs on the both servers are member of > > different > > > > VNs > > > > > but t= > > > > > > wo VNs have interconnection. I think that the > > > > > > draft should mention this case and distinct it from when NVE > > is > > > on > > > > > ToRs.<o= > > > > > > :p></o:p></p> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal">In section 3.3, the scenarios should > > cover > > > > > both when= > > > > > > another server is not in the L2 physical domain or in the > > > > > different = > > > > > > L2 physical domain that are connected to this L2 physical > > domain. > > > > > IMO= > > > > > > , two have different. The first case need to > > > > > > let NVE on server to join the L3 physical domain > > > > > first.<o:p></o:p></p> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal">I think, this draft motivates us more > to > > > > have > > > > > NVE on= > > > > > > server when DC operator want to a lot of vm mobility for > > > resource > > > > > and perf= > > > > > > ormance optimization. Without NVE on server, you have > > these > > > > > constrain= > > > > > > s (or rules) to deal with. IETF is to work > > > > > > out the solutions that allow these configuration and device > > > still > > > > > can inte= > > > > > > rwork under different configurations. It is up to DC operator > > to > > > > > chose whic= > > > > > > h configuration is proper for their business. > > > > > > <o:p></o:p></p> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal">I agree, regardless of NVE on server > or > > on > > > > ToR, > > > > > the = > > > > > > issue in section 3.4 we need to solve in nvo3 > > > > solution.<o:p></o:p></p> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal">Regards,<o:p></o:p></p> > > > > > > <p class=3D"MsoNormal">Lucy<o:p></o:p></p> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > <p class=3D"MsoNormal"><o:p> </o:p></p> > > > > > > </div> > > > > > > </div> > > > > > > </div> > > > > > > </div> > > > > > > </body> > > > > > > </html> > > > > > > > > > > > > --_000_2691CE0099834E4A9C5044EEC662BB9D44816464dfweml505mbx_- > - > > > > > _______________________________________________ > > > > > nvo3 mailing list > > > > > [email protected] > > > > > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
