Gentle people, These nodes generally won't know their role as a hub or spoke, and there probably isn't a formal connectivity policy. Successfully moving them shouldn't change their roles, as their topology should generally be preserved as a part of their move ?
Hope all is most excellent, Carter Carter Bullard, QoSient, LLC 150 E. 57th Street Suite 12D New York, New York 10022 +1 212 588-9133 Phone +1 212 588-9134 Fax On Oct 4, 2012, at 12:23 PM, Yakov Rekhter <[email protected]> wrote: > Lucy, > >> Hi Yakov, >> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf Of >>> Yakov Rekhter >>> Sent: Thursday, October 04, 2012 10:32 AM >>> To: Lucy yong >>> Cc: [email protected]; Linda Dunbar >>> Subject: Re: [nvo3] comment on rekhter-vm-mobility >>> >>> Lucy, >>> >>>> Hi Linda and Yakov, >>>> >>>> Beside previous comment. I also want to add other two comments or say >>> two s= >>>> uggestions. >>>> >>>> >>>> 1) Suggest to add a new section (section 3.5) to address policy >>> impact. >>>> It can describe that although a virtual overlay network can be >>> implemented >>>> with a full mesh topology in general, it is possible to implement >>> with >>>> different topologies by using policy. This is very often cases in >>> IP/MPLS >>>> L3VPN, which allows tenant implementing firewall, security control, >>> gateway >>>> function, and etc in certain places. However, the policy implemented >>> topology >>>> may cause the performance change significantly when moving VMs. For >>> example, >>>> when an NVO is implemented with hub-spoke topology, moving a VM from >>> a >>>> Hub NVE place to a spoke NVE place will conduct the communication >>> from a >>>> VM in other spoke NVE places to go through the hub-NVE first, which >>> may cause >>>> observable traffic delay. This performance change is caused by the >>> policy, >>> which is different from the performance change due to physical >>> location.= >>> >>> What you described in the above seems like changing VM from being a hub >>> to being a spoke. This has nothing to do with VM mobility, as changing >>> VM from being a hub to being a spoke could be accomplished without >>> moving VM at all, but by just changing import/export RTs of the EVI/VRF >>> associated with the VM. >> [Lucy] Let me make it clear. What I want to say is about moving a VM at a hub >> site to a spoke site. This is not about if an operator want to change >> a hub site into a spoke site. > > If a particular VM suppose to act as a spoke, then one can *not* > move this VM from an EVI/VRF provisioned as a spoke to an EVI/VRF > provisioned as a hub (as doing this would violate policies that > control inter-VM connectivity). > > To cover this I would propose to add the following to the draft > (perhaps, as you suggested, in a separate section): > > Moving VM from one L2 physical domain to another means > (among other things) that the NVE in the new domain that > provides connectivity between this VM and VMs in other L2 > physical domains must be able to implement the policies > that control connectivity between this VM and VMs in other > L2 physical domains. In other words, the policies that > control connectivity between a given VM and its peers > MUST NOT change as the VM moves from one L2 physical domain > to another. All of the above is irrespective of whether > the L2 physical domains are trivial or not. > > Yakov. > >>>> In addition, another VM on the same spoke NVE now can directly talk >>> to the >>>> moved VM without going through hub-NVE, which may impact the initial >>> design >>>> goal. I think this is fairly important to describe in this document, >>> so >>>> DC operator has to pay attention on these factors when moving VMs. >>> >>> Two spokes should not allow to talk to each other directly, >>> irrespective >>> of the location of these two spokes. And if they do, then there is >>> an implementation bug. As a side comment, in the context of >>> "usual" 2547 VPN that means that even if two spokes are connected to >>> the same PE, they can not talk to each other directly (via this PE). >> [Lucy] good point. Setting a policy at spoke site can achieve that. However, > in L3VPN case, SP VPN may not able to limit hosts at CE site to communicate > eac > h other in the CE network (without touch VPN at all). Thus, the main purpose > of > hub-spoke implementation is to prohibit the communication between two spoke si > tes directly in my opinion. >>> >>> >>>> 2) The doc. should mention that when a VM moves from one server >>> to ano= >>>> ther server, if the destination virtual network is implemented with >>> differe= >>>> nt address family, VM IP address has to change to match the >>> destination net= >>>> work supported address family. For example, a VM with IPv4 address >>> is mo= >>>> ved to an virtual network that supports IPv6 only. (I know this is >>> obvious,= >>>> but it should be the rule) >>> >>> The scope of the draft is on seamless mobility, and seamless mobility, >>> by definition, means that VM's IP address does not change. From >>> section 2: >>> >>> .... seamless mobility is >>> defined as the ability to move a VM from one server in the data >>> center to another server in the same or different data center, while >>> retaining the IP and MAC address of the VM. >>> >>> Changing VM's IP address family would certainly imply changing VM's >>> IP address, and thus is outside the scope of the draft. >> [Lucy] I see. I did not read this carefully. Agree that is outside the scope > of the draft. >> >> Lucy >>> >>>> It is good we have one document to capture all VM mobility issues >>> that DC o= >>>> perators need to know. >>> >>> Yakov. >>> >>>> >>>> Regards, >>>> Lucy >>>> >>>> >>>> >>>> From: Linda Dunbar >>>> Sent: Wednesday, October 03, 2012 3:13 PM >>>> To: Linda Dunbar; Lucy yong; Yakov Rekhter >>>> Cc: [email protected] >>>> Subject: RE: comment on rekhter-vm-mobility >>>> >>>> One more point, if destination VMs don't expect VIDs, then the NVE >>> can remo= >>>> ve the VID encoded in the data frame after the decapsulation, >>> regardless wh= >>>> ere NVE is. Of course, if NVE is many hops away from the VMs, there >>> is high= >>>> er chance that the local VID is needed in the data frame after the >>> decapsul= >>>> ation. >>>> >>>> Linda >>>> >>>> From: Linda Dunbar >>>> Sent: Wednesday, October 03, 2012 3:10 PM >>>> To: Lucy yong; Yakov Rekhter >>>> Cc: [email protected] >>>> Subject: RE: comment on rekhter-vm-mobility >>>> >>>> Lucy, >>>> >>>> If the destination VMs also expect VIDs in the data frame, the target >>> NVE (= >>>> or egress NVE) should not take away the VID embedded in the data >>> frames, re= >>>> gardless where NVE is. >>>> >>>> The point is that the VIDs used by those VMs are globally significant. >>>> >>>> LInda >>>> >>>> From: Lucy yong >>>> Sent: Wednesday, October 03, 2012 2:57 PM >>>> To: Linda Dunbar; Yakov Rekhter >>>> Cc: [email protected] >>>> Subject: RE: comment on rekhter-vm-mobility >>>> >>>> Linda, >>>> >>>> Regardless the frame from VM having VID or not, the frame is >>> encapsulated a= >>>> t NVE and sent to a peer NVE. If peer NVE is also on a server, it >>> can pass= >>>> the frame to VM directly based on the destination address. Therefore, >>> the = >>>> VID is not used at all. >>>> >>>> I agree if the peer NVE is on ToR, it will send the frame to a VLAN >>> identif= >>>> ied by VID in order to reach that VM. Thus, the rules are caused by >>> physica= >>>> l network configuration. Is that right? >>>> >>>> That is my point. The draft should clarify this. Do you agree? >>>> >>>> Lucy >>>> >>>> From: Linda Dunbar >>>> Sent: Wednesday, October 03, 2012 2:48 PM >>>> To: Lucy yong; Yakov Rekhter >>>> Cc: [email protected] >>>> Subject: RE: comment on rekhter-vm-mobility >>>> >>>> Lucy, >>>> >>>> For VMs instantiated with applications which need to sit in multiple >>> subnet= >>>> s, the VIDs are encoded in the data frames sent out from the VMs. For >>> this = >>>> scenario, even if the NVE is on server, VIDs are there between VMs >>> and Virt= >>>> ual Switch. >>>> >>>> Linda >>>> >>>> From: [email protected] [mailto:[email protected]] On Behalf >>> Of Luc= >>>> y yong >>>> Sent: Monday, October 01, 2012 2:17 PM >>>> To: Yakov Rekhter >>>> Cc: [email protected] >>>> Subject: [nvo3] comment on rekhter-vm-mobility >>>> >>>> Hi Yakov, >>>> >>>> It is carefully written about L2-based CUG. >>>> >>>> The scenarios that the draft describe are about that VMs in a CUG are >>> expos= >>>> ed 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 whe= >>>> re 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. >>>> >>>> Comment I want to give is that, one motivation to do NVO for DC is to >>> creat= >>>> e 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 n= >>>> etworks which has a lot of constrain to support VM mobility. You >>> draft has= >>>> specified these necessary constrains. However, if we just want to >>> impleme= >>>> nt in this way, we do not achieve our objective here: to create a >>> true virt= >>>> ual 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 thi= >>>> s 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 m= >>>> ore. 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. >>>> >>>> Assuming an NVE is on server, a VM can be moved from one server to >>> anothe= >>>> r 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 th= >>>> ink that the draft should mention this case and distinct it from when >>> NVE i= >>>> s 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. >>>> >>>> I think, this draft motivates us more to have NVE on server when DC >>> operato= >>> r 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. I= >>>> ETF 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. >>>> >>>> Regards, >>>> Lucy >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> --_000_2691CE0099834E4A9C5044EEC662BB9D44816464dfweml505mbx_ >>>> 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:Tahoma; >>>> panose-1:2 11 6 4 3 5 4 4 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;} >>>> p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph >>>> {mso-style-priority:34; >>>> margin-top:0i _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
