Good Yours irrespectively,
John > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Yakov Rekhter > Sent: Thursday, October 04, 2012 9:23 AM > To: Lucy yong > Cc: [email protected]; Linda Dunbar > Subject: Re: [nvo3] comment on rekhter-vm-mobility > > Lucy, > > > 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. > > If a particular VM suppose to act as a spoke, then one can *not* move > this VM from an EVI/VRF provisioned as a spoke to an EVI/VRF > provisioned as a hub (as doing this would violate policies that control > inter-VM connectivity). > > To cover this I would propose to add the following to the draft > (perhaps, as you suggested, in a separate section): > > Moving VM from one L2 physical domain to another means > (among other things) that the NVE in the new domain that > provides connectivity between this VM and VMs in other L2 > physical domains must be able to implement the policies > that control connectivity between this VM and VMs in other > L2 physical domains. In other words, the policies that > control connectivity between a given VM and its peers > MUST NOT change as the VM moves from one L2 physical domain > to another. All of the above is irrespective of whether > the L2 physical domains are trivial or not. > > Yakov. > > > > > 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 eac h 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 si tes 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
