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, regardless 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 at 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 identified by VID in order to reach that VM. Thus, the rules are caused by physical 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 subnets, 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 Virtual Switch. Linda From: [email protected] [mailto:[email protected]] On Behalf Of Lucy 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 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. 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. 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 case 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 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. Regards, Lucy
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
