Hi Yakov, I think: this is why the draft does not apply to NVE on server well although it defines that a trivial L2 physical domain consists of just one server.
IMO: when NVE on a server, VMs on a server and the server exist on two different L2 physical domain. Thus when VMs on a server belong to different L2-based CUGs, for L2-based CUGs boundaries among these VMs, it is necessary to use some (l2) mechanisms to segregate the L2 physical domain" that VMs belong, but not on the L2 physical domain that the server belong to. This is the key for the virtualization overlay, i.e. VMs L2 physical domain can exist in a true virtual environment that is completely decoupled from a physical network including the server where VM resides. Thus the text in the draft (copy below) does not apply to this case because it assumes that the server and VMs belong to the same L2 physical domain. A physical server connected to a given L2 physical domain may host VMs that belong to different L2-based CUGs (while each of these CUGs may span multiple L2 physical domains). If an L2 physical domain contains servers that host VMs belonging to different L2-based CUGs, then enforcing L2-based CUGs boundaries among these VMs within that domain is accomplished by relying on Layer 2 mechanisms (e.g., VLANs). The same issue for this 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. If my logic is correct, when NVE is on server, both server and ToR do not belong to the L2 physical domain that the VM belongs to. Do you agree on this analogy? Should we differentiate the two l2 physical domains to address NVE on server case? IMO, yes. I am on vacation for two weeks and off work for a while, which means I barely check e-mail from now. Regards, Lucy > -----Original Message----- > From: Yakov Rekhter [mailto:[email protected]] > Sent: Sunday, October 07, 2012 12:53 PM > To: Lucy yong > Cc: [email protected] > Subject: Re: comment on rekhter-vm-mobility > > 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
