Subject: [nvo3] FW: Questions/comments to draft-lasserre-nvo3-framework-03.txt

From: Linda Dunbar <[email-masked]>
Date: Thu, 4 Oct 2012 20:30:15 +0000

Marc, et al,

Here are my comments to the "nv03-framework" sent a month ago. Could you please address them?

I want to echo Lucy's comment that behavior might be different when NVE  is directly connected to TES via virtual link or physical link (a.k.a. Trivial L2 domain in Yakov's mobility draft) vs. there is switch( or switches) between NVE and TES.

Linda

From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Tuesday, September 04, 2012 12:41 PM
To: Bocci, Matthew (Matthew); [email-masked]; LASSERRE, MARC (MARC); Balus, Florin Stelian (Florin); [email-masked]; [email-masked]; Yakov Rekhter
Subject: [nvo3] Questions/comments to draft-lasserre-nvo3-framework-03.txt

Marc, et al,

I have a few questions on the draft, hope you can clarify:

1.      What does it mean by NVE being embedded in an End Station (as quoted from the document)?

NVE could be implemented as part of a virtual switch
within a hypervisor, a physical switch or router, a Network Service
Appliance or even be embedded within an End Station.

Do you mean a Guest OS which send IP frame directly? If yes, why need extra layer of IP encapsulation?

2.      VN Context vs. VNID: do you mean that encapsulation header includes field for VN context in addition to VNID? Why need both fields?

3.      Definition to "Virtual Data Center or Virtual DC": when you say "Managed by a single tenant, Virtual DC can contain multiple VNs and multiple Tenant End System..", is the "single tenant" in the sentence one of the "multiple Tenant" in the sentence?

Could  it be more clear to remove the phrase "Managed by a single tenant"?

Other comments:

*        2.1 Generic Reference Model:

The Figure 3 depicts all the Tenant End Systems being directly connected to NV Edge, make the network looks like closed communication pattern.

When applications in DC communicate with peers somewhere else, the NVE function might be on gateway, which connects to remote peers via Internet or secure VPN. I suggest to have a dotted line behind one or two "NV Edge" to show that some Tenant End Systems are connected to NV Edge via another network (like Internet or secure IPSec or VPN).

When "VM-a" talk to remote peer "b" and  "b" is in another DC which doesn't have NVo3 encapsulation, Then the NVE for "b" is on the Gateway of DC where "VM-a" is hosted.  In this scenario the "b" doesn't connect to its NVE via Ethernet. So the statement on P11 "either directly or via a switched network (typically

Ethernet)" is not true all the time.

*        3.1.5.1  Auto-provisioning/service discovery:

Your description states that "NVEs being able to select appropriate VNI based on state information provided by external entities".

Then it is not really "auto-provisioning". It should be classified as  "static provisioning".

"A mechanism for communicating this information between Tenant End Systems and the local NVE" can be one way, other approaches should be possible too.

It is necessary to consider the scenario that  "Tenant End Systems" doesn't have any capability to communicate with NVE. Then external controller has to communicate with the NVE for any new ES being added/removed.

*        3.2 Service Overlay Topologies:

I am confused of this intent of this section. Your second paragraph states that mesh connection between NVEs.

Since it is Layer 3 that interconnect NVEs, we should not assume that NVEs are only one hop away from each other.

*        4.1 Pros & Cons:

Should add a point that Overlay push the burden to edge devices (i.e. NVEs). For NVEs on gateway routers in DC, managing the mapping between End stations and tunnels can be challenging.

Linda Dunbar

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Matthew)
Sent: Wednesday, August 29, 2012 11:01 AM
To: [email-masked]
Subject: [nvo3] Poll for WG adoption: draft-lasserre-nvo3-framework-03.txt

This email begins a poll to help gauge consensus to adopt draft-lasserre-nvo3-framework-03.txt as an NVO3 working group document.

Since this is the second call for adoption, and only a few changes were requested during the last call for adoption, we will be running this call for 10 days, only.

If you support adoption of draft-lasserre-nvo3-framework-03.txt, please reply to this thread with 'support'.

If you do not support adoption, please reply to this thread with 'do not support', and state your reasons.

This poll will close on Friday 7th September 2012.

Regards

Matthew & Benson

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Fri, 5 Oct 2012 16:41:37 +0200

Linda,

See my replies below.

Marc

________________________________
From: Linda Dunbar [mailto:[email-masked]]
Sent: Thursday, October 04, 2012 10:30 PM
To: [email-masked]; LASSERRE, MARC (MARC); Balus, Florin Stelian (Florin); [email-masked]; [email-masked]; Yakov Rekhter
Subject: FW: [nvo3] Questions/comments to draft-lasserre-nvo3-framework-03.txt

Marc, et al,

I want to echo Lucy's comment that behavior might be different when NVE  is directly connected to TES via virtual link or physical link (a.k.a. Trivial L2 domain in Yakov's mobility draft) vs. there is switch( or switches) between NVE and TES.
Sure the behaviour is different but this does not call for another TES-NVE interface type besides a VAP. Several private emails have been exchanged with Lucy on this topic.

Linda

Marc, et al,

[ml] Since it should have read "... within an tenant system", this makes it redundant as tenant system can be any of the elements mentioned before in this sentence.
[ml] I will clarify this in -01.

[ml] You should read the text carefully. The draft says that in section 3.1.3 that a VNID can be used as a VN context when globally significant.

[ml] The sentence says: "Managed by a single tenant, a Virtual DC can contain multiple VNs and multiple Tenant End Systems  that are connected to one or more of these VNs."

[ml] Hence, a tenant manages multiples tenant end systems and not multiple tenants.

Other comments:

[ml] Agreed, but this is generic reference model where all connectivity details can not represented.

[ml] To make it clearer and more generic, how about saying "either directly or indirectly"?

[ml] That state can be provided in a non-static way - hence auto-provisioning.

[ml] Yes, and an external controller is such a mechanism. The original sentence includes this possibility.

[ml] The intent was not to assume that full mesh connectivity is required.

*        4.1 Pros & Cons:

Linda Dunbar

Regards

Matthew & Benson

---

From: Lucy yong <[email-masked]>
Date: Fri, 5 Oct 2012 16:23:50 +0000

Marc,

I have exchanged the opinion with Linda and we are agree that we should differentiate two cases in the architecture model. If you argue that even TES and NVE are connected via a switched network, you can still model them by a virtual link, which would be the interface. Then my argument on that is where you expect to the protocol to exist, between NVE and TES or between NVE and a switch. As you know that today IEEE VDP protocol is between hypervisor and external switch, not VM to external switch.  I think that such protocol should exist between NVE and switch interface.  Does it make sense?

Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of LASSERRE, MARC (MARC)
Sent: Friday, October 05, 2012 9:42 AM
To: Linda Dunbar; [email-masked]; Balus, Florin Stelian (Florin); [email-masked]; [email-masked]; Yakov Rekhter
Subject: Re: [nvo3] Questions/comments to draft-lasserre-nvo3-framework-03.txt

Linda,

See my replies below.

Marc

Linda

Marc, et al,

Other comments:

*        4.1 Pros & Cons:

Linda Dunbar

Regards

Matthew & Benson

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Fri, 5 Oct 2012 14:30:16 -0500

In-line, while Marc is asleep. :)

From: Lucy yong [mailto:[email-masked]]
Sent: Friday, October 05, 2012 9:24 AM
To: LASSERRE, MARC (MARC); Linda Dunbar; [email-masked]; Balus, Florin Stelian (Florin); [email-masked]; [email-masked]; Yakov Rekhter
Subject: RE: [nvo3] Questions/comments to draft-lasserre-nvo3-framework-03.txt

Marc,

I have exchanged the opinion with Linda and we are agree that we should differentiate two cases in the architecture model. If you argue that even TES and NVE are connected via a switched network, you can still model them by a virtual link, which would be the interface.

[FB>] You seem to mix the data plane service connectivity (VAP) with the control plane path. VAP is used by service connectivity, whatever protocol is used to do auto-discovery does not go through the VAPs of the VNI.

Then my argument on that is where you expect to the protocol to exist, between NVE and TES or between NVE and a switch.
[FB>] NVE and TES. When the NVE is hypervisor and TES is a local VM it is an internal process. When NVE is a ToR and the TES is an appliance or a VM on a hypervisor with VLAN-based uplink then the AD protocol is whatever we decide to be  - Kireeti has a draft where he started a debate on that subject.
As you know that today IEEE VDP protocol is between hypervisor and external switch, not VM to external switch.  I think that such protocol should exist between NVE and switch interface.  Does it make sense?
[FB>] I think Marc already said this: there is a fine balance between the architecture/framework and solution details. To answer your questions:  when the NVE is on the ToR a process inside the system that owns the TES (hypervisor or internal appliance process) will act on behalf of the TES to advertise to the NVE ToR the TES events.

These are solution details though that will not help at this point in time the overall solution progress in my opinion. This does not have though anything to do with the data plane: i.e.  changing/adding to the VAP definition...

Lucy

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of LASSERRE, MARC (MARC)
Sent: Friday, October 05, 2012 9:42 AM
To: Linda Dunbar; [email-masked]<mailto:[email-masked]>; Balus, Florin Stelian (Florin); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Yakov Rekhter
Subject: Re: [nvo3] Questions/comments to draft-lasserre-nvo3-framework-03.txt

Linda,

See my replies below.

Marc

To: [email-masked]<mailto:[email-masked]>; LASSERRE, MARC (MARC); Balus, Florin Stelian (Florin); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Yakov Rekhter

Linda

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Tuesday, September 04, 2012 12:41 PM
To: Bocci, Matthew (Matthew); [email-masked]<mailto:[email-masked]>; LASSERRE, MARC (MARC); Balus, Florin Stelian (Florin); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Yakov Rekhter
Subject: [nvo3] Questions/comments to draft-lasserre-nvo3-framework-03.txt

Marc, et al,

Other comments:

*        4.1 Pros & Cons:

Linda Dunbar

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Matthew)
Sent: Wednesday, August 29, 2012 11:01 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [nvo3] Poll for WG adoption: draft-lasserre-nvo3-framework-03.txt

Regards

Matthew & Benson

---

From: Lucy yong <[email-masked]>
Date: Fri, 5 Oct 2012 21:43:07 +0000

I have quite private discussions with framework co-authors on the reference model regarding to VAPs and did not realize this response is on the public list. I apology if this makes other people confused.

Florin,

In current reference model, i.e. figure 4 or 5, and text in section 3.1.1,

Tenant End Systems are connected to the VNI Instance through Virtual
       Access Points (VAPs). The VAPs can be in reality physical ports on a
       ToR or virtual ports identified through logical interface
       identifiers (VLANs, internal VSwitch Interface ID leading to a VM).

It is not clearly to me that if one or more TESes are connected to a VNI instance via one VAP or if one TES has to use one VAP to connect VNI. The latter is a p2p relationship, which indicates that these is no need any protocol, NVE can know the TES state. IMO: this applies to  1) TES and NVE on a server; 2)  a physical server connects to an NVE on ToR directly. The first means that multiple TESes can use ONE VAP connecting to an VNI, in this case, a protocol is necessary on NVE to know individual TES state. IMO: this applies to 1) VMs on a server and NVE on ToR; 2)  several physical servers or VM server connect to a VLAN that connects to an NVE on ToR.

I think that the architecture reference model should clearly distinguish one on one case and multiple on one case  because NVE performs different functions in each case. Without separating them, it is hard to describe the requirements clearly.

If you say that a VAP represents the service connectivity between NVE and TES, then it does not apply to the multiple on one case. How can you have one VAP represent multiple of connectivity?  You can only mean the connectivity to a VLAN, right?  Regardless of a protocol necessary or not, the current architecture does not even make this clear in data plane. If you say that current model means multiple TESes using one VAP connecting a VNI, which covers one TES on one VAP too. Then I strongly suggest to separate two in the reference model  because 1) implementation of one-on-one case is much simple, NVE knows TES state without any protocol.  2) one on one case provides a true virtual network environment, i.e. TES communications are completely decoupled from a physical network end-to-end. In multiple on one case, TES communications are not completely decoupled from the physical network because TES and NVE are not co-located. Therefore, they have to deal with physical network configuration one way or another, see Yakov's vm mobility draft. The optimal goal for NVo3 is the communications among TES in a true virtual environment. However, given reality situation, it is necessary to support multiple on one case too.

Do you think that my description here relates any solution or lead to any particular solution?  It is not. It is purely about how to model these. If we distinguish these two cases in the architecture reference model, we can much easier describe the requirement documents and reduces a lot of confusion.

In short, current document is very weak and unclear on VAP specification.  It needs to specify more and clearly in one way or another. In addition, it needs clearly specify that one TES may attach to one or multiple VNIs. Again, there are one on one case and multiple on one case. For the latter, it means a TES participating multiple VLANs and each connect to a VNI.

Regards,
Lucy

From: Balus, Florin Stelian (Florin) [mailto:[email-masked]]
Sent: Friday, October 05, 2012 2:30 PM
To: Lucy yong; LASSERRE, MARC (MARC); Linda Dunbar; [email-masked]; [email-masked]; [email-masked]; Yakov Rekhter
Subject: RE: [nvo3] Questions/comments to draft-lasserre-nvo3-framework-03.txt

Marc,

Lucy

Linda,

See my replies below.

Marc

Linda

Marc, et al,

Other comments:

*        4.1 Pros & Cons:

Linda Dunbar

Regards

Matthew & Benson