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. > 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. > 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. > 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. > > 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
