Zu, I just noticed a typo below (an instance of the word "not" should be struck). Fixed below. - Larry
From: Larry Kreeger <[email protected]<mailto:[email protected]>> Date: Thursday, September 12, 2013 6:58 PM To: Zu Qiang <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Thomas Narten <[email protected]<mailto:[email protected]>>, David Black <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] Comment on draft-kreeger-nvo3-hypervisor-nve-cp-01 Hi Zu, Getting back to this thread, my responses are inline. - Larry From: Zu Qiang <[email protected]<mailto:[email protected]>> Date: Friday, August 30, 2013 7:29 PM To: Larry Kreeger <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Thomas Narten <[email protected]<mailto:[email protected]>>, David Black <[email protected]<mailto:[email protected]>> Subject: RE: Comment on draft-kreeger-nvo3-hypervisor-nve-cp-01 Hello, Larry Thanks for your quick response. See my comments inline below. Have a nice weekend Zu Qiang From: Larry Kreeger (kreeger) [mailto:[email protected]] Sent: Friday, August 30, 2013 6:43 PM To: Zu Qiang; [email protected]<mailto:[email protected]>; Thomas Narten; Black, David Subject: Re: Comment on draft-kreeger-nvo3-hypervisor-nve-cp-01 Hi Zu, See my responses inline. - Larry From: Zu Qiang <[email protected]<mailto:[email protected]>> Date: Friday, August 30, 2013 12:30 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Larry Kreeger <[email protected]<mailto:[email protected]>>, Thomas Narten <[email protected]<mailto:[email protected]>>, David Black <[email protected]<mailto:[email protected]>> Subject: Comment on draft-kreeger-nvo3-hypervisor-nve-cp-01 Hello, Some questions and comments on this draft: * The word "802.1Q trunk" and "VLAN trunk" is used in a few places. Is it just a proprietary concept? If not, do we need a definition somewhere? LK> No, this should be a standard trunk, but based on other discussions about VLANs in the past, this really means C-VLANs (as opposed to an S-VLAN or B-VLAN). I can clarify it to say C-VLAN. [Zu Qiang] Good, C-VLAN is much better. * 3.1.2: "When the VN is providing L3 forwarding, the NVE must have the knowledge of the TS IP addresses." This is true if the L3VNI is embedded in the NVE function which is facing the TS. However, some implementations may have the L3VNI centralized in the DC. In this case, the NVE function is split, where the L2VNI and the L3VNI function are located in different boxes. It may be better to have clear description allows more generic network architecture. LK> Our assumptions have always been that the overlays are initiated/terminated at the edge of the underlay. If the L3 routing is centralized, then it isn't really an L3 overlay, it is just an L2 overlay that connects a TS to a central router which is also at the edge of the overlay, in which case it is not implemented in the NVE. [Zu Qiang] I do agree with the assumption. But even the a L3 routing function is centralized, L3VNI is still implemented in the NVE. It is just not in the same box of the L2VNI. Maybe it is better to make it clear in the text that in the split case, the L3VNI must have the knowledge of the TS IP address. LK2> I'm not following you. First, I am assuming that a VNI typically provides either an L2 service (L2VNI) or an L3 service (L3VNI), and if a hybrid service (L2-L3VNI) were provided, it would be performed in the same NVE, not split across different NVEs. If routing is not performed centrally, I don't consider that central router an NVE. I assume it is connected to an NVE (which could be co-located in the same device, but logically separate). Is there a draft that discusses the split case you refer to? * 4.2: The two ways of TS address discovery is for MAC address discovery? IP address discovery or both? Do we allow the VM to inform the NVE directly at VN address association? Can we cover it in the text as well? LK> Our goal is the make the implementation of the VN completely hidden from the TS (VM). There should be no requirement to modify the TS to participate in address advertisement. There is also an issue of trust, we should try to avoid trusting a TS to advertise its address. [Zu Qiang] I do agree the impacts on TS shall be avoided. But why the TS address advertisement is untrusted? For instance, if the NVE is playing the role of subnet GW, is it allowed that a VM may send ARP message to advertise its address? If TS address advertisement is untrusted, then the TS cannot be trusted, meaning the data plane gleaning is also untrusted, right? LK2> IMO, whether to glean source addresses emitted by the TS would be a policy decision enforced by the entity the TSI connects to. For example, in the case of a VM, the hypervisor often knows the IP address assigned to the TSI by the orchestration system and can choose to drop any packets with source addresses that do not match it. Alternatively, the policy could be to glean addresses, but place a limit on how many to prevent a DOS attack. * 4.3: In the VNIC address disassociation procedure, it only cover the case when the VM is removed from a VNIC. Do we need to cover the case where the VM disassociates one of the addresses from the VNIC and informs the NVE? LK> I don't think the address disassociation should come directly from the VM, but you are correct that this is a missing scenario. Addresses associations should be able to be added and/or removed while the VM/VNIC is still present. I will add that. [Zu Qiang] thanks. * 4.3: For the case that VM mobility between different hypervisors under the same NVE, it’s right that notifying the NVA may be inefficient. But it doesn’t have to be disallowed, right? It shall be allowed to let the NVA to keep the track of the VM mobility. LK> Right, it should certainly be allowed, this can just be an optimization to take a load off the NVA if nothing is changing with respect to tenant address to NVE address mappings. [Zu Qiang] thanks. * 4.4: is the timer solution good enough for the case of address misconfiguration? How the NVE knows there is an address misconfiguration or it is VM mobility? LK> The timer is just a way to implement the optimization of not notifying the NVA when a VM moves and we don't have a pre-associate to tell us directly. It is related to VNIC migration, and not related to address configuration. I'm not sure what you are referring to. [Zu Qiang] there may be the case that two VMs under different NVEs are configured with the same address by mistake. In this case, the NVA may receive the VM connections notifications from both NVEs. The notification may not be received at same time. How should the NVA knows this is a VM mobility or a misconfiguration? Do we need a procedure to cover that case? LK2> I see. If a duplicate address is configured by mistake, then there is no good way to know which VM has the correct address. I'm not sure if we can guarantee that a migration event will always be communicated to the NVE, nor whether a disconnect will aways come before a connect, so it may be difficult to detect the difference between a new VM coming up and a migration. We plan to merge in some content from draft-kompella-nvo3-server2nve-02, so maybe we can address this issue as part of that. Have a nice day Zu Qiang
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
