Hi Aldrin, Thank you so much the explanation. It makes a lot of sense. I think that Yakov new text reflects that aspect. Please see below.
From: Aldrin Isaac [mailto:[email protected]] Sent: Thursday, October 04, 2012 6:25 PM To: Lucy yong Cc: Linda Dunbar; Yakov Rekhter; [email protected] Subject: [nvo3] comment on rekhter-vm-mobility Hub-spoke and other operator or customer defined virtual network are a reality today. However I do think the conversation may have gone off track. In regard to VMs, a VM is generally associated to a network service profile. In the simplest case the profile implements a basic VLAN. In another case, the profile defines the spoke aspect of a hub and spoke VPN. [Lucy] This is equivalent to say that one is plain vanilla VPLS, another is like e-tree case. When a VM is moved within an administrative domain, it's profile remains associated to it -- no matter where it moves in the administrative domain, the nature of its network service remains the same. [Lucy] fully agree. It is very important to understand that in the VM case the service profile is mapped to the VM, not the NVE, physical port, or other thing. [Lucy] Agree. This is to say that the service features apply to VMs not NVE, or ect. Thanks again. Lucy On Thursday, October 4, 2012, Lucy yong wrote: Linda, > > I think you are making it more complicated than it needs to. [Lucy] I don't think so. Look at Aldrin POC case. Hub-Spoke is used. > > Traditional VPN hub-spoke is defined (or configured) by the network > operators. > > But the "Hub-Spoke" relationship among a group of VMs (or hosts) are > triggered by hosts (VMs) themselves, such as IGMP Join/Leave, instead > of by network operators. [Lucy] my text does not apply to this case. The case I give is that DC may configure a NVO with hub-spoke topology instead of a full mesh topology. > > When hosts (VMs) need to form their own Hub-Spoke relationship, they > send out IGMP Join/Leave report. VMs migrated to the new location can > send out a new IGMP Report (Join), then all the switches will learn the > relationship. > > VMware Hypervisor even triggers a fake IGMP Query after a new VM is > instantiated on the local server, so the IGMP Report can be sent out > quickly for all the switches to update the "hub-spoke" relationship. > > > I don't think network operators need to configure the Hub-Spokes > relationship for all the VMs groups. There will be too many, not > scalable. Besides, VMs leased out to clients are totally under the > control of clients, which is not under the control of network operators. [Lucy] Again, look Aldrin's PoC case. I agree that there are a lot of applications that just need a full-mesh topology. However, other applications may need different topologies. That is why it is worth to point out it in the document, so both tenant operator and network operator are aware that vm moves may break the policy designed originally or may cause some unexpected problem. Lucy > > Linda > > > -----Original Message----- > > From: Lucy yong > > Sent: Thursday, October 04, 2012 11:03 AM > > To: Yakov Rekhter > > Cc: [email protected]; Linda Dunbar > > Subject: RE: [nvo3] comment on rekhter-vm-mobility > > > > 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. > > > > > > > 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 each other in the CE network (without touch VPN at
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
