Hi Yakov, I read the draft once again to see why we think differently on the text meaning and am glad to find where I missed.
In this document, you define l2-based CUG, l2 physical domain, trivial L2 physical domain and non-trivial l2 physical domain, and the relationship between l2-based BGU and L2 physical domain. These definitions are clear in the introduction. The first paragraph in 3.1 is to discuss l2 based CUG is implemented by a non-trivial l2 physical network, and specify the rules. This may apply to NVE in TOR and VMs on servers, where server and TOR are part of the non-trivial l2 physical network. The second paragraph in 3.1 state that a trail l2 physical domain may not have VLAN ID at all. this implies that it may use too. Now I think that the problem is the description in the third paragraph, which assumes that Guess OS sends packets that carry VLAN-ID. We have to describe it in trivial l2 physical domain and non-trivial l2 physical domain separately. In a trivial L2 physical domain, the L2 domain identifier is not the VLAN-ID, regardless if the frames from guest OS have VLAN-ID or not; in the non-trivial l2 physical domain, if the VLAN-ID from the guest OS also identifies the domain, i.e. the device in the domain uses it to differ the forwarding tables, it has to follow the rule described in the 3.1 first paragraph; if the VLAN-ID from the guest OS is not used to identify the domain. For example, the former uses c-tag, the latter uses s-tag, this is equivalent to the trivial l2 physical domain case. In both cases, it requires that the domain maintains the Guest VLAN ID transparency. I think this paragraph description mixes these cases together. The last two paragraphs in 3.1 cause the confusion too 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. As I mention above, in the context of nvo3, for a trivial l2 physical domain, VLAN-ID is not used to identify the domain at all. So these statement is not right. 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
