Subject: Re: [nvo3] comments for the framework-03 draft

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Tue, 11 Sep 2012 12:29:42 +0200

Hi Lucy,

See my comments below.

Thanks,
Marc

________________________________
From: Lucy yong [mailto:[email-masked]]
Sent: Tuesday, August 14, 2012 8:06 PM
To: LASSERRE, MARC (MARC)
Cc: [email-masked]
Subject: comments for the framework-03 draft

Hi Marc,

I think it is necessary to add server manger component in the section of functional components in the framework draft. As we know, one of main cases for nvo3 is to place NVE on a server. In which, there is no-wire between NVE and TESes. In DC today, a server manager is used to create vswitch/NVE and VMs, place VMs on a VN.  Current draft mixes this function in the control plane component, which causes a lot of confusion as seen in the mailing list. In addition, vm placement and mobility are very critical features that nvo3 need to support and these actions are initiated by the  server manger, separating control plane component and server manager component makes easy and clear for the solution development to target different parts.

The intent is indeed to describe the Network Virtualization functional components independently from the server management component - as you mentioned in your last sentence, this helps identlfying the NVO3 specific management aspects from existing datacenter management functions that have to be implemented.

Some text in section 3.5.1.1 can move server manager component section. I propose to add following subsections in server manager component:

-          NVE and a VN Creation

Note: state this applying to when NVE is on server.

-          Provisioning one or more TESes into an NVE/VNI
Note: state this applying to both NVE is on or not-on server.

Another comment: It is a bit confusion in figure 4 and 5 to show multiple VNIs with one VN context (single line).  What does mean?
The idea is to show that several VN instances can be supported concurrently and that the overlay function relies upon a VN context identification to perform its mux/demux related functions.
A sentence can be added to clarify this point.

Suggest to change section 2.3 title to "virtual network type". One NVE should be able to host both L2 VN and L3 VN. so 2.3.1 and 2.3.2 title misleading. Suggest
Replace "L2 NVE providing Ethernet LAN-like service" with "L2 virtual network providing Ethernet LAN-like service"
Replace "L3 NVE providing IP/VRF-like service" with "L3 virtual network providing IP VPN-like service"
Yes, an NVE can support both L2 and L3 VN services - like a PE can provide both L2 and L3 VPN services. The terms L2 and L3 PEs have been used extensively before, hence the L2 NVE and L3 NVE names.

In section 4.2.1, it only describes a concern on data plane driven, does not say anything on control plane driven. It should mention some traditional control plane dissemination protocol may bring big burden for each NVE to maintain the locations of all TESs.

 Good point. We will add some text in a future revision.

Regards,
Lucy

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Tue, 11 Sep 2012 12:59:28 +0200

Lucy,

I have just uploaded the new draft-nvo3-framework-00 version as per Matthew and Benson's last email.
The suggested changes below will be included in the next revision of the draft.

Thanks,
Marc

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of LASSERRE, MARC (MARC)
Sent: Tuesday, September 11, 2012 12:30 PM
To: Lucy yong
Cc: [email-masked]
Subject: Re: [nvo3] comments for the framework-03 draft

Hi Lucy,

See my comments below.

Thanks,
Marc

Hi Marc,

-          NVE and a VN Creation

Regards,
Lucy

---

From: Somesh Gupta <[email-masked]>
Date: Tue, 11 Sep 2012 13:02:55 -0700

regarding the last point on 4.2.1;

"In section 4.2.1, it only describes a concern on data plane driven, does not say anything on control plane driven. It should mention some traditional control plane dissemination protocol may bring big burden for each NVE to maintain the locations of all TESs. "

I assume "control plane" means either a traditional distributed protocol or a
centralized management/configuration control?

I am not sure why each NVE has to maintain the locations of all TESs - especially
when using a centralized management control plane that is closely coupled
with the Virtual Server and VM management system.

From: [email-masked] [mailto:[email-masked]] On Behalf Of LASSERRE, MARC (MARC)
Sent: Tuesday, September 11, 2012 3:30 AM
To: Lucy yong
Cc: [email-masked]
Subject: Re: [nvo3] comments for the framework-03 draft

Hi Lucy,

See my comments below.

Thanks,
Marc

-          NVE and a VN Creation

Regards,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Tue, 11 Sep 2012 21:30:42 +0000

Somesh,

Original comment is to point out a concern about some control plane solution that makes each NVE to maintain the locations of all TESes, which may be not necessary for NVO3.

Lucy

From: Somesh Gupta [mailto:[email-masked]]
Sent: Tuesday, September 11, 2012 3:03 PM
To: LASSERRE, MARC (MARC); Lucy yong
Cc: [email-masked]
Subject: RE: comments for the framework-03 draft

Hi Lucy,

See my comments below.

Thanks,
Marc

-          NVE and a VN Creation

Regards,
Lucy

---

From: "Reith, Lothar" <[email-masked]>
Date: Tue, 25 Sep 2012 07:28:36 +0000

Hi Mark,

The following 2 citations from today's mails on the list suggest, that the framework definition on virtual data center may have to be clarified:

Here the 2 citations:
Jon Hudson wrote: "We must remember that the use case for for many customers is to make 2+ datacenters appear as 1. So it must be as trasnparent as it can be with all the redundancy that you would see in a single local site. "

Aldrin Isaac wrote: "important use case that needs to be addressed is how to "stretch" a subnet across two or more NVO3 domain.  If two NVO3 domains connect at two separate sites, then the subnet will be stretched across these NVO3 domains at both sites.  "

Could you/the authors of the Framework for DC Network Virtualization draft-lasserre-nvo3-framework-03

please clarify, if the definition of "virtual data center" covers the use case of one virtual datacenter being stretched across two data centers?

If that is not the case, I request to include a definition of "NVO3 domain" into the framework, in the sense how Aldrin used the term.

Regards, Lothar

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von LASSERRE, MARC (MARC)
Gesendet: Dienstag, 11. September 2012 12:59
An: Lucy yong
Cc: [email-masked]
Betreff: Re: [nvo3] comments for the framework-03 draft

Lucy,

Thanks,
Marc

See my comments below.

Thanks,
Marc

-          NVE and a VN Creation

Regards,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Tue, 25 Sep 2012 15:42:26 +0000

Indeed, we need to have right terms and clear definition in the framework.
One tenant virtual network may consist of one or more network virtual overlay (NVO) instances that is referred as subnet or nvo3 domain. NVO instances may be stitched together via a logical gateway entity. In this case, the gateway has to be a member in both nvo3 instances.

IMO, a vDC can be implemented in one or more DC sites. In fact, it is described in the draft-mity-nvo3-use-case.  A customer can seamlessly access it via a VPN, which appears one vDC, or a customer can choose use IPsec (p2p) to connect each DC site, which will appear as two vDCs.  The use case draft describe these general cases.

Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Reith, Lothar
Sent: Tuesday, September 25, 2012 2:29 AM
To: LASSERRE, MARC (MARC)
Cc: [email-masked]
Subject: Re: [nvo3] comments for the framework-03 draft

Hi Mark,

Here the 2 citations:

Regards, Lothar

Lucy,

Thanks,
Marc

See my comments below.

Thanks,
Marc

-          NVE and a VN Creation

Regards,
Lucy