Yakov, > -----Original Message----- > From: Yakov Rekhter [mailto:[email protected]] > Sent: Thursday, October 04, 2012 9:57 AM > To: Lucy yong > Cc: Yakov Rekhter; [email protected] > Subject: Re: comment on rekhter-vm-mobility > > Lucy, > > > Hi Yakov, > > > > It is carefully written about L2-based CUG. > > > > The scenarios that the draft describe are about that VMs in a CUG are > exposed > > 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 where > > 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. > > The draft covers both the "NVE on ToR and VM on server" case, and > the case where both NVE and VM are on server. The former is described > as a "non-trivial L2 physical domain"; the latter as "trivial L2 > physical domain". > > From 2.1 of the draft: > > A trivial L2 physical domain consists of just one server. [Lucy] I think using the term "trivial L2 physical domain" to reference the case where both NVE and VM are on a server is a bit of confusing. In the context of NVO3, we distinguish the overlay network and underlay network. The latter is referred to as a physical network. The text:
We say that an L2 physical domain contains a given VM (or that a given VM is in a given L2 physical domain), if the server presently hosting this VM is part of that domain, or the server is connected to a ToR that is part of that domain. Do you say that this text covers the NVE and VM on a server? If NVE on a sever, server and ToR are not part of that domain in my opinion. The text: We say that a given L2-based CUG is present within a given data center if one or more VMs that are part of that CUG are presently hosted by the servers located in that data center. In the context of this document when we talk about VLAN-ID used by a given VM, we refer to the VLAN-ID carried by the traffic that is within the same L2 physical domain as the VM, and that is either originated or destined to that VM - e.g., VLAN-ID only has local significance within the L2 physical domain, unless it is stated otherwise. This text applies more today situation when L2-basd CUG is not implemented by NVO3. If using NVO3 and all NVEes are on a server, there is no reason for VMs to use VLAN-ID any more. However, if NVE are on ToR switch and VLANs are used between Server and TORs, then you are back to the today's situation. This is why I feel that the document only cover the NVE on ToR case. > > > Comment I want to give is that, one motivation to do NVO for DC is to > create > > 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 > > networks which has a lot of constrain to support VM mobility. You > draft has > > specified 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. > > > > It is clear that, in nvo3, we want to support that NVE 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 wire 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. > > The draft does this - from 3.1: > > This document assumes that within a trivial L2 physical domain > traffic from/to VMs that are in this domain may not have VLAN-IDs at > all. [Lucy] OK. Right Assumption. However, there is the text in 3.1: If a given VM's Guest OS sends packets that carry VLAN-ID, then when the VM moves from one L2 physical domain to another the VLAN-ID used by the Guest OS can not change (this is irrespective of whether L2 physical domains are trivial or non-trivial). Will this description controversial with the assumption? It is indicate that the VM moves from one L2 physical domain to another L2 physical domain but the VLAN ID used by the Guest OS can not change. If NVE is on a server, will this still relevant? If yes, please explain why? Section 3.3 also has the text that do not apply to when NVE on server. > > > Assuming an NVE is on server, a VM can be moved from one server to > another > > 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 think > > that the draft should mention this case and distinct it from when NVE > > is 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. > > Could you please propose the text that you think is necessary. [Lucy] how about this text for 3.3 first paragraph: Consider a scenario where a VM that is a member of a given L2-based CUG moves from one server to another. Three cases may exist. 1) another server is in the same L2 physical domain; 2) another server is not in "L2 physical domain"; 3) another server is in different L2 physical domains, where these domains may be located in the same or different data centers. In order to enable communication between this VM and other VMs of that L2-based CUG, the case 1 works naturally; in case 2, the server has to be configured as a member of the same L2-physical domain or a member in a different L2-physical domain first. (the latter, in turn, becomes case 3); in case 3, the new L2 physical domain must become interconnected with the other L2 physical domain(s) that presently contain the rest of the VMs of that CUG, and the interconnect must not violate the L2-based CUG requirement to preserve source and destination MAC addresses in the Ethernet header of the packets exchange between this VM and other members of that CUG. > > > 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 performance > optimization. > > Without NVE on server, you have these constrains (or rules) to deal > with. > > IETF 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. [Lucy] Do you think if the draft should state out this? If all the NVE are on the servers, then it becomes the case that one "trivial L2 physical domain" spans across multiple servers, in which VM mobility is in a true virtual environment, i.e. no need to deal with these rules described in this document. Regards, Lucy > > > > I agree, regardless of NVE on server or on ToR, the issue in section > 3.4 we > > need to solve in nvo3 solution. > > Ok. > > Yakov. > > > > > Regards, > > Lucy > > > > > > > > > > > > > > > > > > --_000_2691CE0099834E4A9C5044EEC662BB9D4481598Ddfweml505mbx_ > > 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:"\@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;} > > span.EmailStyle17 > > {mso-style-type:personal-compose; > > font-family:"Calibri","sans-serif"; > > color:windowtext;} > > .MsoChpDefault > {mso-style-type:export-only;} > > @page WordSection1 > > {size:8.5in 11.0in; > > margin:1.0in 1.0in 1.0in 1.0in;} > > div.WordSection1 > > {page:WordSection1;} > > --></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">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> > > </body> > > </html> > > > > --_000_2691CE0099834E4A9C5044EEC662BB9D4481598Ddfweml505mbx_-- _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
