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.
> 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).
> 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.
> 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
