Hi Yakov and Linda, I was in hurry to finish the below e-mail yesterday and made one mistake.
Last two paragraphs in the section 3.1 are stated correctly. > > This document assumes that within a given non-trivial L2 physical > domain traffic from/to VMs that are in that domain, and belong to > different L2-based CUG MUST have different VLAN-IDs. > > The above assumptions about VLAN-IDs are driven by (a) the > assumption > that within a given L2 physical domain VLANs are used to identify > individual L2-based CUGs, and (b) the need to overcome the > limitation > on the number of different VLAN-IDs. This is right for a non-trivial L2 physical domain traffic. It does not apply to a trivial L2 physical domain because the domain does not use the VLAN ID. 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
