Lucy, > 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?
Yes. > If NVE on a sever, server and ToR are not part of that domain in > my opinion. If NVE is on a server, then the server is part of that domain, although this is a "trivial L2 physical domain"; the ToR connected to the server is *not* part of that domain. > 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. The document covers both the case where the NVE is on a ToR, and when NVE is on servers. If NVEs are on servers, then we are dealing with trivial L2 physical domain, in which case (quoting from 3.1 of the draft): 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. > > > > > 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. I would let Linda comment on this, as the case where VM's Guest OS sends packets that carry VLAN-ID was proposed by Linda. > > > 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 doma in > or a member in a different L2-physical domain first. (the latter, in tur n, > becomes case 3); in case 3, the new L2 physical domain must become inter connected > 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 Ethe rnet header > of the packets exchange between this VM and other members of that > CUG. The above seems more like an outline of possible solutions. As such this text is outside the scope of the draft (as the draft focuses on listing the problems/issues). Yakov. > > > 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 en vironment, 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
