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. * 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. * 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. * 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. * 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. * 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. Have a nice day Zu Qiang
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
