Subject: [nvo3] Comment on draft-kreeger-nvo3-hypervisor-nve-cp-01

From: Zu Qiang <[email-masked]>
Date: Fri, 30 Aug 2013 19:30:02 +0000

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?
  *   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.
  *   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?
  *   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?
  *   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.
  *   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?

Have a nice day
Zu Qiang

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 30 Aug 2013 22:43:21 +0000

Hi Zu,

See my responses inline.  - Larry

From: Zu Qiang <[email-masked]<mailto:[email-masked]>>
Date: Friday, August 30, 2013 12:30 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Larry Kreeger <[email-masked]<mailto:[email-masked]>>, Thomas Narten <[email-masked]<mailto:[email-masked]>>, David Black <[email-masked]<mailto:[email-masked]>>
Subject: Comment on draft-kreeger-nvo3-hypervisor-nve-cp-01

Hello,

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.

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.

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.

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.

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

---

From: Zu Qiang <[email-masked]>
Date: Sat, 31 Aug 2013 02:29:56 +0000

Hello, Larry
                Thanks for your quick response. See my comments inline below.

Have a nice weekend
Zu Qiang

From: Larry Kreeger (kreeger) [mailto:[email-masked]]
Sent: Friday, August 30, 2013 6:43 PM
To: Zu Qiang; [email-masked]; Thomas Narten; Black, David
Subject: Re: Comment on draft-kreeger-nvo3-hypervisor-nve-cp-01

Hi Zu,

Hello,

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.

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.

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?

[Zu Qiang] thanks.

[Zu Qiang] thanks.

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?

Have a nice day
Zu Qiang