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
