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
