Subject: [nvo3] Questions to draft-ietf-nvo3-nve-nva-cp-req-00

From: Linda Dunbar <[email-masked]>
Date: Mon, 9 Sep 2013 20:30:40 +0000

Larry, et al,

Section 3 of the draft states that the scenario of NVE residing on a physical network switch is not in the scope being discussed in this draft (last sentence of the second paragraph).

But the bullet 3 in the same section states:

Are those "End Devices" different from the "Tenant System"? Are there any indication to differentiate "End Devices" from "Tenant Systems"?

Another question, why have two places to define the  NVE-NVA requirement, one for NVE being embedded on Hypervisor, one for NVE being on separate physical switches?

I see the requirement for both scenarios quite similar. Can you elaborate the major differences?

Linda

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Mon, 9 Sep 2013 22:58:13 +0000

Hi Linda,

Please see inline.

 - Larry

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 9, 2013 1:30 PM
To: Larry Kreeger <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Questions to draft-ietf-nvo3-nve-nva-cp-req-00

Larry, et al,

LK> Right, it says it is covered in draft-kreeger-nvo3-hypervisor-nve-cp-req which is recently expired, but I am in the process of updating (so it will be back).

Are those “End Devices” different from the “Tenant System”? Are there any indication to differentiate “End Devices” from “Tenant Systems”?

LK> Yes, these End Devices are not Tenant Systems.  As you quoted above "a hypervisor or a Network Service Appliance" is not a Tenant System.  Here is the definition from draft-ietf-nvo3-framework:

LK>"End Device: A physical device that connects directly to the DC Underlay Network. This is in contrast to a tenant system, which connects to a corresponding tenant VN. An End Device is administered by the DC operator rather than a tenant, and is part of the DC infrastructure. An End Device may implement NVO3 technology in support of NVO3 functions. Examples of an End Device include hosts (e.g., server or server blade), storage systems (e.g., file servers, iSCSI storage systems), and network devices (e.g., firewall, load-balancer, IPSec gateway). "

LK> The requirements for the NVE to NVA control plane are exactly the same regardless of whether the NVE is embedded within and End Device (e.g. Hypervisor), or in a physical switch.  The second paragraph of section 3 is trying to say that the Hypervisor to NVE protocol is covered in draft-kreeger-nvo3-hypervisor-nve-cp-req, not that that embedded NVEs is out of scope for the NVE to NVA control plane.  Please let me know how I can reword it to make it more clear.

LK> It think they are identical.

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 10 Sep 2013 20:43:59 +0000

Larry,

Glad to learn that you agree that the NVE to NVA control plane requirement is exactly the same regardless of whether the NVE is embedded in Hypervisor, in End Device, or on a separate physical switch.

Then, I would suggestion re-wording the second paragraph of Section 3 to the following to avoid other people from getting confused:

There are two aspects of control plane for NVE: one is the protocol between NVE and NVA for NVE to be populated with the mapping tables  to tunnel traffic across the underlying networks; another one is the protocol between Tenant Systems and NVE for NVE to be promptly updated of TS's status. The latter control plane aspect is not discussed in this document, but is covered in [I-D.kreeger-nvo3-hypervisor-nve-cp-req]. The requirements for the NVE to NVA control plane are exactly the same regardless of whether the NVE is embedded within and End Device (e.g. Hypervisor), or in a physical switch.

I suggest to either remove the Figure 1, or change Figure 1 to show that NVE can be either embedded or separate:

 --------

Figure 2 shows the Net Service Instances being attached to NVE. How is it different from VMs being attached to NVE from control plane perspective?

Linda

---

From: Melinda Shore <[email-masked]>
Date: Wed, 11 Sep 2013 14:30:28 -0800

On 9/10/2013 12:43 PM, Linda Dunbar wrote:
> /There are two aspects of control plane for NVE: one is the protocol
> between NVE and NVA for NVE to be populated with the mapping tables  to
> tunnel traffic across the underlying networks; another one is the
> protocol between Tenant Systems and NVE for NVE to be promptly updated
> of TS’s status. The latter control plane aspect is not discussed in this
> document, but is covered in
> [I-D.kreeger-nvo3-hypervisor-nve-cp-req].//The requirements for the NVE
> to NVA control plane are exactly the same regardless of whether the NVE
> is embedded within and End Device (e.g. Hypervisor), or in a physical
> switch./ //

Larry, I think that architecturally this is an important
point.  While you may want to change the language a bit
I think it would be a good idea to include something along
these lines to provide both clarity around the architecture
and linkage between documents (which otherwise might be
lost).  This should be uncontroversial, since there's already
agreement that this description is correct.

Melinda

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Wed, 11 Sep 2013 23:32:19 +0000

Hi Linda,

See below for my responses.  - Larry

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 10, 2013 1:43 PM
To: Larry Kreeger <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] Questions to draft-ietf-nvo3-nve-nva-cp-req-00

Larry,

There are two aspects of control plane for NVE: one is the protocol between NVE and NVA for NVE to be populated with the mapping tables  to tunnel traffic across the underlying networks; another one is the protocol between Tenant Systems and NVE for NVE to be promptly updated of TS’s status. The latter control plane aspect is not discussed in this document, but is covered in [I-D.kreeger-nvo3-hypervisor-nve-cp-req].The requirements for the NVE to NVA control plane are exactly the same regardless of whether the NVE is embedded within and End Device (e.g. Hypervisor), or in a physical switch.

LK> There is no protocol from a Tenant System to the NVE.  Tenant Systems should not have to be modified to participate in any NVO3 protocols.  It is the End Devices (e.g. Hypervisor, Network Service Appliance) that does this.  Otherwise, I will put in some text similar to above to clarify what this draft is covering and what is covered in draft-kreeger-nvo3-hypervisor-nve-cp-req.

 --------

LK> A figure similar to the one above is in draft-kreeger-nvo3-hypervisor-nve-cp-req, I can put it in here too.

LK> It is no different, this is just showing two plausible examples of embedded NVEs.  Similar to the hypervisor figure, there is also a figure in draft-kreeger-nvo3-hypervisor-nve-cp-req that shows a Network Service Appliance using an external NVE.  Do you think I should put that figure in here as well?

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 12 Sep 2013 15:36:52 +0000

Larry,

Thanks for the clarification. So the following is more accurate?

There are two aspects of control plane for NVE: one is the protocol between NVE and NVA for NVE to be populated with the mapping tables  to tunnel traffic across the underlying networks; another one is the protocol between Hypervisor and NVE for NVE to be promptly updated of TS's status. The latter control plane aspect is not discussed in this document, but is covered in [I-D.kreeger-nvo3-hypervisor-nve-cp-req].The requirements for the NVE to NVA control plane are exactly the same regardless of whether the NVE is embedded within and End Device (e.g. Hypervisor), or in a physical switch.

[Linda] Since this draft is about the control plane between NVE and NVA, it is more important to depict various possible topologies of NVAs in relative to NVEs. The following figure might be helpful. If you agree, I can convert it into text format and send it to you.

Linda

---

From: Zu Qiang <[email-masked]>
Date: Thu, 12 Sep 2013 16:04:40 +0000

Hello, Larry
                I have some clarification questions on section 3 of this draft.

-          Section 3.3: the text is a little bit confused. Please clarify it.

1)      At VN connect/disconnect, the attached/detached NVE may be notified by the hypervisor. Then the NVE will inform the NVA, where the NVA is going to update the remote NVEs with a new address mapping table.

2)      Or the NVA may learn the VN connect/disconnect from somewhere (e.g. orchestration). Then it will notify the NVE where the VN was attached/detached and update the remote NVEs with a new address mapping table.

3)      Or both 1) and 2) are allowed?

-          Because of my confusion from the reading of section 3.3, it may be good to make it more clear in section 3.1 and 3.2 on which direction the notification is sent. For instance, "A protocol is needed for the NVA to provide this inner to outer mapping and VN Context to each NVE that requires it and keep the mapping updated in  a timely manner."

-          Section 3.4: I agree that VN name into VN ID mapping may be needed. However, we may need to allow different implementations. For instance, one can have this mapping in NVA only and use VN ID in all interfaces. Therefore, supporting this mapping in NVA-NVE protocol shall be optional.

Have a nice day
Zu Qiang

---

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

Hi Zu,

My responses are inline below.

 - Larry

From: Zu Qiang <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 12, 2013 9:04 AM
To: Larry Kreeger <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Questions to draft-ietf-nvo3-nve-nva-cp-req-00

Hello, Larry

LK> In my opinion, number 1) makes the most sense.  Doing thing this way eliminates the need for a central orchestrator that must manage all NVEs regardless of where they might reside (hypervisors, ToR switches, routers, firewalls, load balancers etc).  However, section 6.1 of draft-marten-nvo3-arch leaves it open for number 2) as well.  As long as we have a protocol to federate NVAs, one might have one NVA only for hypervisors with embedded NVEs where VN connect/disconnect is communicated directly to the NVA (perhaps through an internal software interface), and another NVA for various physical NVEs.

-          Because of my confusion from the reading of section 3.3, it may be good to make it more clear in section 3.1 and 3.2 on which direction the notification is sent. For instance, “A protocol is needed for the NVA to provide this inner to outer mapping and VN Context to each NVE that requires it and keep the mapping updated in  a timely manner.”

LK> Yes, this section is meant to express the need for an NVE to get a mapping from the NVA.  I can add the text you suggest above to make it clearer.  However your comment made me realize that the other direction (NVE telling the NVA what inner addresses to outer mappings it terminates) is missing.  I can add subsections to 3.1 to cover each direction of inner/outer mapping information flow.

LK> I agree that it is optional.  The wording in section 3.4 was trying to convey this.  It mentions both approaches. It is probably better to come out and say this is optional instead of inferring it with statements such as "Thus, it may be useful for the NVE-to-NVA protocol to support an operation that maps VN Names into VN IDs.".

Have a nice day
Zu Qiang

---

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

See below. - Larry

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 12, 2013 8:36 AM
To: Larry Kreeger <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nvo3] Questions to draft-ietf-nvo3-nve-nva-cp-req-00

Larry,

There are two aspects of control plane for NVE: one is the protocol between NVE and NVA for NVE to be populated with the mapping tables  to tunnel traffic across the underlying networks; another one is the protocol between Hypervisor and NVE for NVE to be promptly updated of TS’s status. The latter control plane aspect is not discussed in this document, but is covered in [I-D.kreeger-nvo3-hypervisor-nve-cp-req].The requirements for the NVE to NVA control plane are exactly the same regardless of whether the NVE is embedded within and End Device (e.g. Hypervisor), or in a physical switch.

LK2> Yes.

LK2> Personally, I don't find these figures that helpful. It doesn't matter if an NVA is implemented in a physical or virtual form factor, but it must have access the the underlying network.  I don't see any reason to add the complication of having the overlay system's protocols running recursively over the same overlay network it is trying to control.  It seems like there would be chicken or the egg problem.  Note that section 7.1 of draft-narten-nvo3-arch-00 states "Alternatively, an NVE can obtain needed information by interacting directly with an NVA via a protocol operating over the data center underlay network."  I can add a similar sentence to this draft.

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 13 Sep 2013 16:08:56 +0000

Larry,

When NVA is attached to another NVE (say NVE#i), all other NVEs have to use NVE#i to reach the NVAs, whereas when NVAs are visible (or routed) in the underlying network, all NVEs peer with the NVAs (or may even run IGP with NVAs). So it is less about if NVA is on virtual machine or not, more about how NVAs reach NVEs.

When you define control plane requirement for NVE<->NVA, listing requirement separately for different topology can make them more complete.  If there is IGP (e.g. IS-IS) running among NVEs and NVAs, the NVE-NVA control plane can utilize the IGP.

Linda

Linda

---

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

Hello, Larry
Thanks for your response. And thanks for taking care of my comments. My comments below in green.
Have a nice day
Zu Qiang

From: Larry Kreeger (kreeger) [mailto:[email-masked]]
Sent: Thursday, September 12, 2013 9:11 PM
To: Zu Qiang
Cc: [email-masked]
Subject: Re: Questions to draft-ietf-nvo3-nve-nva-cp-req-00

Hi Zu,

 - Larry

Hello, Larry

LK> In my opinion, number 1) makes the most sense.  Doing thing this way eliminates the need for a central orchestrator that must manage all NVEs regardless of where they might reside (hypervisors, ToR switches, routers, firewalls, load balancers etc).  However, section 6.1 of draft-marten-nvo3-arch leaves it open for number 2) as well.  As long as we have a protocol to federate NVAs, one might have one NVA only for hypervisors with embedded NVEs where VN connect/disconnect is communicated directly to the NVA (perhaps through an internal software interface), and another NVA for various physical NVEs.
[Zu Qiang] I agree that both 1) and 2) shall be allowed in the standard. There is no technical reason to disallow any of it. Then the text in this section shall be make clear enough for both cases. I can propose some text if it is ok for you.

[Zu Qiang] thanks.

[Zu Qiang] thanks.

Have a nice day
Zu Qiang

---

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

Hi Linda,

Regardless of whether the NVA functionality is a VM, or in its own physical device, or a function built into the same physical device as an NVE (switch or router), I still see no reason for the NVA to be connected to an NVE directly.  They might coexist inside the same device, but they would be logically separated.  Both would connect to the underlying network, whether that underlying network connectivity is physical or virtual.

 - Larry

Date: Friday, September 13, 2013 9:08 AM

Larry,

Linda

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 17 Sep 2013 15:08:14 +0000

Larry,

Comments/questions are inserted below:

From: [email-masked] [mailto:[email-masked]] On Behalf Of Larry Kreeger (kreeger)
Sent: Friday, September 13, 2013 1:54 PM
To: Linda Dunbar
Cc: [email-masked]
Subject: Re: [nvo3] Questions to draft-ietf-nvo3-nve-nva-cp-req-00

Hi Linda,

Regardless of whether the NVA functionality is a VM, or in its own physical device, or a function built into the same physical device as an NVE (switch or router), I still see no reason for the NVA to be connected to an NVE directly.

[Linda] Here is the scenario that I am thinking of:  NVE is a ToR switch and  the NVA is a server attached to the ToR Switch as shown below:

Under this scenario, other NVEs have to use the ToR NVE's outer address to reach the NVA, i.e. NVA is not in the same routing domain as other NVEs.

The control plane for NVAs to distribute mapping entries will be different from the scenario when NVA is in the same routing domain as other NVEs.

Linda

They might coexist inside the same device, but they would be logically separated.  Both would connect to the underlying network, whether that underlying network connectivity is physical or virtual.

 - Larry

Larry,

Linda

Linda