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

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 13 Sep 2013 01:58:03 +0000

Hi Zu,

Getting back to this thread, my responses are inline.

 - Larry

From: Zu Qiang <[email-masked]<mailto:[email-masked]>>
Date: Friday, August 30, 2013 7:29 PM
To: Larry Kreeger <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Thomas Narten <[email-masked]<mailto:[email-masked]>>, David Black <[email-masked]<mailto:[email-masked]>>
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-masked]]
Sent: Friday, August 30, 2013 6:43 PM
To: Zu Qiang; [email-masked]<mailto:[email-masked]>; 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-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,
                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

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 13 Sep 2013 02:30:37 +0000

Zu, I just noticed a typo below (an instance of the word "not" should be struck).  Fixed below.  - Larry

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

Hi Zu,

 - Larry

Hello, Larry

Have a nice weekend
Zu Qiang

Hi Zu,

Hello,

Have a nice day
Zu Qiang

---

From: "Pat Thaler" <[email-masked]>
Date: Fri, 13 Sep 2013 17:36:07 +0000

A comment on the issue of trusting the TS

Hi Zu,

PAT> It is common for the hypervisor (or the NIC when the VM sends directly to it as in SR-IOV) to check at least the MAC address and VLAN ID (or to add the VLAN tag for a VM that sends untagged).  The VM shouldn't be trusted for information that is used to determine the VN at the NVE. If the TS was trusted for that, one wouldn't be providing reliable isolation between the VNs. Perhaps in some cases policy would trust a VM TS for that information, but we need to provide for common case where the VM TS isn't trusted to declare what VN it belongs to.

---

From: Zu Qiang <[email-masked]>
Date: Fri, 13 Sep 2013 18:24:20 +0000

Hello, Larry
                Thanks for your reply. Comments below with underline.

Have a nice day
Zu Qiang

From: Larry Kreeger (kreeger) [mailto:[email-masked]]
Sent: Thursday, September 12, 2013 10:31 PM
To: Larry Kreeger (kreeger); Zu Qiang; [email-masked]; Thomas Narten; Black, David
Subject: Re: [nvo3] Comment on draft-kreeger-nvo3-hypervisor-nve-cp-01

Hi Zu,

 - Larry

Hello, Larry

Have a nice weekend
Zu Qiang

Hi Zu,

Hello,

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?
[Zu Qiang] I'm referring to the use case draft, section 4.2. in this use case, the TS is attached to NVE1~4, which has L2VNI only. The L3VNI is located in NVE5~6. The requirement in your text "When the VN is providing L3 forwarding, the NVE must have the knowledge of the TS IP addresses", I believe the "NVE" in your text is referring to the NVE5 or NVE6 in the use case.

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.
[Zu Qiang] agree. Maybe it is good make it clear in the draft.

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

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.
[Zu Qiang] I think this is an issue which shall be covered in NVO3. I can provide some text on this if it is ok for you.

Have a nice day
Zu Qiang

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 13 Sep 2013 18:59:16 +0000

Hi Pat,

I completely agree with you, the only case I can think of where a VM would be trusted to choose what VNs to connect to is a case where the VM is not a Tenant System, but actually administered by the same admins running the overlay.  This could be a case where the VM is a virtualized gateway between VNs and non-overlay networks.

 - Larry

From: Pat Thaler <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 13, 2013 10:36 AM
To: Larry Kreeger <[email-masked]<mailto:[email-masked]>>, Zu Qiang <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Thomas Narten <[email-masked]<mailto:[email-masked]>>, David Black <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nvo3] Comment on draft-kreeger-nvo3-hypervisor-nve-cp-01

Hi Zu,

PAT> It is common for the hypervisor (or the NIC when the VM sends directly to it as in SR-IOV) to check at least the MAC address and VLAN ID (or to add the VLAN tag for a VM that sends untagged).  The VM shouldn’t be trusted for information that is used to determine the VN at the NVE. If the TS was trusted for that, one wouldn’t be providing reliable isolation between the VNs. Perhaps in some cases policy would trust a VM TS for that information, but we need to provide for common case where the VM TS isn’t trusted to declare what VN it belongs to.