Subject: [nvo3] Updated Charter

From: Benson Schliesser <[email-masked]>
Date: Tue, 27 Mar 2012 19:11:35 +0200

Dear NVO3 Participants -

Please see the revised draft charter, below.  Based on mailing list feedback, the BOF chairs and Thomas have attempted to re-factor and simplify the text.

Cheers,
-Benson, Matthew, Thomas

NVO3: Network Virtualization Overlays (Version 2012032705)

Support for multi-tenancy has become a core requirement of data centers (DCs), especially in the context of data centers supporting virtualized servers known as virtual machines (VMs).  A key multi-tenancy requirement is traffic isolation, so that a tenant's traffic (and internal address usage) is not visible to any other tenant and does not collide with addresses used within the data center itself. Another key requirement is to support the placement and live migration of VMs anywhere within a data center, without being limited by DC network constraints such as the IP subnet boundaries of the underlying DC network. (Note: Although this charter uses the term VM throughout, the scope of NVO3 is intended to include non-virtualized end systems.)

This WG will develop an approach to multi-tenancy that does not rely on any underlying L2 isolation mechanisms to support multi-tenancy. In particular, the WG will develop an approach where multi-tenancy is provided at the IP layer using an encapsulation header that resides above IP. This approach should provide an Ethernet service. It may provide an IP service; an important goal is to develop a "layer agnostic" framework and architecture meeting data center requirements.

NVO3 will document the problem statement, the applicability, and an architectural framework for overlay networks within a data center environment. Within this framework, functional blocks will be defined to allow the dynamic attachment / detachment of VMs to the overlay network, the mapping of "inner" (tenant VM) addresses into "outer" (underlying network) addresses in order to tunnel a packet to the destination VM, and the migration of VMs within the network in a dynamic fashion. 

Based on this framework, the WG will develop requirements for both control plane protocol(s) and data plane encapsulation format(s), and perform a gap analysis of existing candidate mechanisms. Driven by the requirements and consistent with the gap analysis, the WG will document solutions consisting of one or more data plane(s) and control plane(s), as applicable. 

The WG will investigate interconnection and interoperation issues between overlays and VPNs to determine if any specific work is needed.

The WG will liaise with the appropriate external organizations including the IEEE, as appropriate. 

Milestones:

0) Problem Statement (Informational RFC)

1) Framework document (Informational RFC)

2) Control plane requirements document (Informational RFC)

3) Data plane requirements document (Informational RFC)

4) Gap Analysis (Informational RFC)

5) Recharter for Standards Track solution document(s) as appropriate

---

From: Benson Schliesser <[email-masked]>
Date: Fri, 30 Mar 2012 01:13:38 +0200

Dear NVO3 Participants -

Based on feedback received during the BOF on Wednesday, we have made a few minor updates to the draft charter text. Specifically, we added a sentence to the 4th paragraph that explicitly says NVO3 will consider maintenance, troubleshooting, and security requirements. We also added dates to the milestones.

Please note that this is still a draft charter, pending IESG approval. My understanding is that the IESG will be discussing this at their meeting tomorrow and making a decision (on whether to form an NVO3 WG) at their 12-April meeting.

Cheers,
-Benson

NVO3: Network Virtualization Overlays

Based on this framework, the WG will develop requirements for both control plane protocol(s) and data plane encapsulation format(s), and perform a gap analysis of existing candidate mechanisms. In addition to functional and architectural requirements, NVO3 will develop maintenance, troubleshooting, and security requirements. Driven by the requirements and consistent with the gap analysis, the WG will document solutions consisting of one or more data plane(s) and control plane(s), as applicable. 

Milestones:

0) Problem Statement (Informational RFC) - August 2012

1) Framework document (Informational RFC) - August 2012

2) Control plane requirements document (Informational RFC) - November 2012

3) Data plane requirements document (Informational RFC) - November 2012

4) Gap Analysis (Informational RFC) - November 2012

5) Recharter for Standards Track solution document(s) as appropriate - November 2012

---

From: "Mcdysan, David E" <[email-masked]>
Date: Fri, 30 Mar 2012 04:43:06 -0400

Hi,

This looks good, with one major comment.

I suggest that the charter needs to better describe the scope because this
will impact the virtual tenant namespace requrements. The text below could
be interpreted as:
1) a single data center
2) a set of data centers under control of one administrative domain
3) multiple sets of data centers under control of multiple administrative
domains

1 and 2 are probably easier, but if the scope could at least consider 3.
Using definition 3 we may not have to introduce additional levels on
indirection as alluded to in David Black's slides or the comment Kireeti
made at the mike that this is reminiscent of inter-AS VPNs, which is
complexity I suggest that we strive to avoid.

Thanks,

Dave

On 3/29/12 7:13 PM, "Benson Schliesser" <[email-masked]> wrote:

>Dear NVO3 Participants -
>
>Based on feedback received during the BOF on Wednesday, we have made a
>few minor updates to the draft charter text. Specifically, we added a
>sentence to the 4th paragraph that explicitly says NVO3 will consider
>maintenance, troubleshooting, and security requirements. We also added
>dates to the milestones.
>
>Please note that this is still a draft charter, pending IESG approval. My
>understanding is that the IESG will be discussing this at their meeting
>tomorrow and making a decision (on whether to form an NVO3 WG) at their
>12-April meeting.
>
>Cheers,
>-Benson
>
>
>Support for multi-tenancy has become a core requirement of data centers
>(DCs), especially in the context of data centers supporting virtualized
>servers known as virtual machines (VMs).  A key multi-tenancy requirement
>is traffic isolation, so that a tenant's traffic (and internal address
>usage) is not visible to any other tenant and does not collide with
>addresses used within the data center itself. Another key requirement is
>to support the placement and live migration of VMs anywhere within a data
>center, without being limited by DC network constraints such as the IP
>subnet boundaries of the underlying DC network. (Note: Although this
>charter uses the term VM throughout, the scope of NVO3 is intended to
>include non-virtualized end systems.)
>
>This WG will develop an approach to multi-tenancy that does not rely on
>any underlying L2 isolation mechanisms to support multi-tenancy. In
>particular, the WG will develop an approach where multi-tenancy is
>provided at the IP layer using an encapsulation header that resides above
>IP. This approach should provide an Ethernet service. It may provide an
>IP service; an important goal is to develop a "layer agnostic" framework
>and architecture meeting data center requirements.
>
>NVO3 will document the problem statement, the applicability, and an
>architectural framework for overlay networks within a data center
>environment. Within this framework, functional blocks will be defined to
>allow the dynamic attachment / detachment of VMs to the overlay network,
>the mapping of "inner" (tenant VM) addresses into "outer" (underlying
>network) addresses in order to tunnel a packet to the destination VM, and
>the migration of VMs within the network in a dynamic fashion.
>
>Based on this framework, the WG will develop requirements for both
>control plane protocol(s) and data plane encapsulation format(s), and
>perform a gap analysis of existing candidate mechanisms. In addition to
>functional and architectural requirements, NVO3 will develop maintenance,
>troubleshooting, and security requirements. Driven by the requirements
>and consistent with the gap analysis, the WG will document solutions
>consisting of one or more data plane(s) and control plane(s), as
>applicable. 
>
>The WG will investigate interconnection and interoperation issues between
>overlays and VPNs to determine if any specific work is needed.
>
>_______________________________________________
>nvo3 mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/nvo3