Linda, See my replies below.
Marc ________________________________ From: Linda Dunbar [mailto:[email protected]] Sent: Thursday, October 04, 2012 10:30 PM To: [email protected]; LASSERRE, MARC (MARC); Balus, Florin Stelian (Florin); [email protected]; [email protected]; Yakov Rekhter Subject: FW: [nvo3] Questions/comments to draft-lasserre-nvo3-framework-03.txt 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. 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 From: [email protected] [mailto:[email protected]] On Behalf Of Linda Dunbar Sent: Tuesday, September 04, 2012 12:41 PM To: Bocci, Matthew (Matthew); [email protected]; LASSERRE, MARC (MARC); Balus, Florin Stelian (Florin); [email protected]; [email protected]; 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? [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. 2. VN Context vs. VNID: do you mean that encapsulation header includes field for VN context in addition to VNID? Why need both fields? [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. 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? [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. 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). [ml] Agreed, but this is generic reference model where all connectivity details can not represented. 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. [ml] To make it clearer and more generic, how about saying "either directly or indirectly"? * 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". [ml] That state can be provided in a non-static way - hence auto-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. [ml] Yes, and an external controller is such a mechanism. The original sentence includes this possibility. * 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. [ml] The intent was not to assume that full mesh connectivity is required. * 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 protected] [mailto:[email protected]] On Behalf Of Bocci, Matthew (Matthew) Sent: Wednesday, August 29, 2012 11:01 AM To: [email protected] 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
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
