Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 23-Apr-2012 update

From: Stewart Bryant <[email-masked]>
Date: Mon, 23 Apr 2012 16:57:55 +0100

Based on the list discussion, I have updated the draft NVO3
charter to take into consideration the  feedback received
so far.

- Stewart

NVO3: Network Virtualization Over Layer 3

Chairs - TBD
Area - Routing
Area Director - Stewart Bryant
INT Area Adviser - TBD
OPS Area Adviser - TBD

Support for multi-tenancy has become a core requirement of data centers
(DCs), especially in the context of data centers supporting virtualized
hosts known as virtual machines (VMs). Two key requirements needed
to support multi-tenancy are traffic isolation, so that a tenant's
traffic is not visible to any other tenant, and address independence,
so that one tenant's addressing does not collide with other tenants
addressing schemes or with addresses used within the data center itself.
Another key requirement is to support the placement and migration of
VMs anywhere within the data center, without being limited by DC
network constraints such as the IP subnet boundaries of the
underlying DC network.

An NVO3 solution (known here as a Data Center Virtual Private
Network (DCVPN)) is a VPN that is viable across a scaling range of
a few thousand VMs to several million VMs running on greater
than 100K physical servers. It thus has good scaling properties
from relatively small networks to networks with several million
DCVPN endpoints and hundreds of thousands of DCVPNs within a
single administrative domain.

Note that although this charter uses the term VM throughout, NVO3 must
also support connectivity to traditional hosts e.g. hosts that do not
have hypervisors.

NVO3 will consider approaches to multi-tenancy that reside at the
network layer rather than using traditional isolation mechanisms
that rely on the underlying layer 2 technology (e.g., VLANs).
The NVO3 WG will determine which types of  service are needed by typical
DC deployments (for example, IP and/or Ethernet).

NVO3 will document the problem statement, the applicability, and an
architectural framework for DCVPNs within a data center
environment. Within this framework, functional blocks will be defined to
allow the dynamic attachment / detachment of VMs to their DCVPN,
and the interconnection of elements of the DCVPNs over
the underlying physical network. This will support the delivery
of packets to the destination VM, and provide the network functions
required for the migration of VMs within the network in a
sub-second timeframe.

Based on this framework, the NVO3 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, the NVO3 WG will develop
management, operational, maintenance, troubleshooting, security and
OAM protocol requirements.

The NVO3 WG will investigate the interconnection of the DCVPNs
and their tenants with non-NVO3 IP network(s) to determine if
any specific work is needed.

The NVO3 WG will write the following informational RFCs, which
must be substantially complete before rechartering can be
considered:
     Problem Statement
     Framework document
     Control plane requirements document
     Data plane requirements document
     Operational Requirements
     Gap Analysis

Driven by the requirements and consistent with the gap analysis,
the NVO3 WG may request being rechartered to document solutions
consisting of one or more data plane encapsulations and
control plane protocols as applicable.  Any documented solutions
will use existing IETF protocols if suitable. Otherwise,
the NVO3 WG may propose the development of new IETF protocols,
or the writing of an applicability statement for a non-IETF
protocol.

If the WG anticipates the adoption  of the technologies of
another SDO, such as the IEEE, as part of the solution, it
will liaise with that SDO to ensure the compatibility of
the approach.

Milestones:

Dec 2012 Problem Statement submitted for IESG review
Dec 2012 Framework document submitted for IESG review
Dec 2012 Data plane requirements submitted for IESG review
Dec 2012 Operational Requirements submitted for IESG review
Mar 2012 Control plane requirements submitted for IESG review
Mar 2012 Gap Analysis submitted for IESG review
Apr 2012 Recharter or close Working Group

---

From: Thomas Narten <[email-masked]>
Date: Mon, 23 Apr 2012 13:07:12 -0400

Hi Stewart.

> Apr 2012 Recharter or close Working Group

You presumably mean 2013 for the last 3.

That said, I really hope the WG can get all of its documents to the
IESG by December. That gives the WG 7-8 months and 2 IETF
meetings. Not an easy task, but if it takes the WG a full year before
it gets to doing anything beyond requirements, etc., that does not
paint a very encouraging picture.  I recall during the BOF someone
(Jon Hudson?) stating that industry is already well ahead of the IETF
in this space...

Thomas

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 23 Apr 2012 18:42:31 -0700

On 4/23/12 17:27 , Anoop Ghanwani wrote:
> On Mon, Apr 23, 2012 at 10:07 AM, Thomas Narten <[email-masked]> wrote:
> 
>> I recall during the BOF someone

Standards activities are a product of rather than a source of innovation.

> Isn't that nearly always the case?
> 
> Anoop
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Benson Schliesser <[email-masked]>
Date: Mon, 23 Apr 2012 18:48:09 -0700

Hi, Thomas.

> You presumably mean 2013 for the last 3.

Yes, that does seem like a more achievable target...

> (Jon Hudson?) stating that industry is already well ahead of the IETF

I agree, the NVO3 WG needs to move quickly. And aggressive milestone dates might help motivate speed.

On the other hand, realistic dates might improve our credibility with outside observers - it would be nice if we were on-time rather than "late" delivering on our milestones. And of course we always have the option of doing things faster than the milestones suggest. :)

Cheers,
-Benson

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 23 Apr 2012 17:27:28 -0700

Anoop

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 24 Apr 2012 21:39:06 +0000

I think that the Charter should have some text to identify the key differences between DCVPN and L2VPN/L3VPN. If the key differences aren't properly described, all the protocols developed for L2VPN and L3VPN will pop up as potential solutions. 

Here are some key differences I see:
- Majority of VMs (or End-Systems) do communicate with external peers, even though their volume may not be large. Most external peers access their VMs (or End-Systems) in Data Centers via internet or IP network until packets reach the Data Center gateway. 

- Majority of VMs are end systems, vs. nodes in L2VPN/L3VPN are not. 

Linda Dunbar

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stewart Bryant
> Sent: Monday, April 23, 2012 10:58 AM
> To: [email-masked]
> Cc: [email-masked]; IETF Discussion
> Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) -
> 23-Apr-2012 update
>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 24 Apr 2012 22:52:43 +0100

> I think that the Charter should have some text to identify the key differences between DCVPN and L2VPN/L3VPN. If the key differences aren't properly described, all the protocols developed for L2VPN…
I do not think that the charter is the place to provide a technical 
definition of the difference between DCVPN and L2VPN/L3VPN. The charter 
sets the scope of the work.

> - Majority of VMs are end systems, vs. nodes in L2VPN/L3VPN are not.
That really would be a better fit in the requirements and framework 
documents.

- Stewart

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 24 Apr 2012 17:08:33 -0500

At 04:52 PM 4/24/2012, Stewart Bryant wrote:
>>I think that the Charter should have some text to identify the key 
>>differences between DCVPN and L2VPN/L3VPN. If the key differences 
>>aren't properly described, all the protocols developed for L2VPN 
>>and L3VPN will pop up as potential solutions.
>definition of the difference between DCVPN and L2VPN/L3VPN. The 
>charter sets the scope of the work.
>
>>
>>- Majority of VMs (or End-Systems) do communicate with external 
>>peers, even though their volume may not be large. Most external 
>>peers access their VMs (or End-Systems) in Data Centers via 
>>internet or IP network until packets reach the Data Center gateway.
>>
>That really would be a better fit in the requirements and framework documents.

While I generally agree, in this case IMO it is worth mentioning in 
the charter that this difference will be covered within both the 
requirements and framework documents - to be clear to everyone 
reading the charter. Little or no details are necessary, I should think.

James

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 24 Apr 2012 22:39:30 +0000

Stewart, 

Respect your advice. However, some wording in the proposed charter are too ambiguous, is it the intent? 

For example:

  "An NVO3 solution (known here as a Data Center Virtual Private Network (DCVPN)) is a VPN that is viable across a scaling range of a few thousand VMs to several million VMs running on greater than 100K physical servers."

Do you mean "one VPN across a scaling range of million VMs"? or many VPNs combined to scale range of million VMs?

Another example: 
 	"NVO3 will consider approaches to multi-tenancy that reside at the network layer rather than using traditional isolation mechanisms that rely on the underlying layer 2 technology (e.g., VLANs)"

"network layer" can mean different things to different people. Why not simply say "NV03 will consider approaches to multi-tenancy which do not rely on Layer 2 VLANs"? 

3rd example:

	" The NVO3 WG will determine which types of  service are needed by typical DC deployments"

Data center provide Computing and storage services. Network facilitates the connection among Computing entities and storage entities. 
 Why does NV03 WG need to determine what types of "services" are needed by typical DC deployment? 

Do you mean "NV03 WG will consider network deployment by typical DC"? 

Linda Dunbar

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Tuesday, April 24, 2012 4:53 PM
> To: Linda Dunbar
> Cc: [email-masked]; [email-masked]; IETF Discussion
> Subject: Re: Key difference between DCVPN and L2VPN/L3VPN
> 
> aren't properly described, all the protocols developed for L2VPN and
> L3VPN will pop up as potential solutions.
> > - Majority of VMs (or End-Systems) do communicate with external peers,
> even though their volume may not be large. Most external peers access
> their VMs (or End-Systems) in Data Centers via internet or IP network
> until packets reach the Data Center gateway.
> >

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 25 Apr 2012 11:01:42 +0100

Hi Linda,

>   "An NVO3 solution (known here as a Data Center Virtual Private Network
> (DCVPN)) is a VPN that is viable across a scaling range of a few thousand VMs
to
> several million VMs running on greater than 100K physical servers."
> 

I don't find the text ambiguous at all. You might disagree with what it says ("a
VPN"), but you can't claim it is ambiguous.

> Another example:
>  	"NVO3 will consider approaches to multi-tenancy that reside at the
> network layer rather than using traditional isolation mechanisms that rely on
the
> underlying layer 2 technology (e.g., VLANs)"
> 
> "network layer" can mean different things to different people. Why not simply
> say "NV03 will consider approaches to multi-tenancy which do not rely on Layer
2
> VLANs"?

There are also layers above the network layer. The charter rules them out of
scope. This is good.

Stewart has clarified that "network layer" includes IP and MPLS, and that it is
the bit of the hourglass that we all know as the network layer.

> Data center provide Computing and storage services. Network facilitates the
> connection among Computing entities and storage entities.

I think s/services/connectivity services/ might address this issue. Although the
examples cited (but not quoted by you) do tend to give a strong hint.

Adrian

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 25 Apr 2012 09:57:08 -0400

A question in line.

> the bit of the hourglass that we all know as the network layer.

The charter talks about

> DC deployments (for example, IP and/or Ethernet).

I generally think of Ethernet as being Layer 2. Does this charter
envision Ethernet as being part of the
network layer? What was intended with having it mentioned there?

Regards
Marshall

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 25 Apr 2012 15:31:27 +0100

On 25/04/2012 14:57, Marshall Eubanks wrote:
> A question in line.
>
> On Wed, Apr 25, 2012 at 6:01 AM, Adrian Farrel<[email-masked]>  wrote:
>> Hi Linda,
>>
Hi Marshall

The client VMs *may* need to talk Ethernet to their peers, but it is
intended that VPNs that convey the client packets will run over the
network layer i.e. IP and or MPLS.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 25 Apr 2012 22:39:23 +0100

This version of the NVO3 charter reflects the discussions
on the list and comments received as of this afternoon.

I propose to take this to the IESG for their second
review tomorrow.

Stewart

======

Chairs - TBD
Area - Routing

Support for multi-tenancy has become a core requirement of data centers
(DCs), especially in the context of data centers supporting virtualized
hosts known as virtual machines (VMs). Three  key requirements needed
to support multi-tenancy are:

   o Traffic isolation, so that a tenant's traffic is not visible to
     any other tenant, and

   o Address independence, so that one tenant's addressing scheme does
     not collide with other tenant's addressing schemes or with addresses
     used within the data center itself.

    o Support the placement and migration of VMs anywhere within the
      data center, without being limited by DC network constraints
      such as the IP subnet boundaries of the underlying DC network.

An NVO3 solution (known here as a Data Center Virtual Private
Network (DCVPN)) is a VPN that is viable across a scaling
range of a few thousand VMs to several million VMs running on
greater than one hundred thousand physical servers. It thus has
good scaling properties from relatively small networks to
networks with several million DCVPN endpoints and hundreds of
thousands of DCVPNs within a single administrative domain.

A DCVPN also supports VM migration between physical servers
in a sub-second timeframe.

NVO3 will consider approaches to multi-tenancy that reside at the
network layer rather than using traditional isolation mechanisms
that rely on the underlying layer 2 technology (e.g., VLANs).
The NVO3 WG will determine which types of connectivity services
are needed by typical DC deployments (for example, IP and/or
Ethernet).

NVO3 will document the problem statement, the applicability,
and an architectural framework for DCVPNs within a data center
environment. Within this framework, functional blocks will be
defined to allow the dynamic attachment / detachment of VMs to
their DCVPN, and the interconnection of elements of the DCVPNs
over the underlying physical network. This will support the
delivery of packets to the destination VM within the scaling
and migration limits described above.

The NVO3 WG will write the following informational RFCs, which
must have completed Working Group Last Call before rechartering can be
considered:

     Problem Statement
     Framework document

or the writing of an applicability statement for non-IETF
protocols.

Milestones:

Dec 2012 Problem Statement submitted for IESG review
Dec 2012 Framework document submitted for IESG review
Dec 2012 Data plane requirements submitted for IESG review
Dec 2012 Operational Requirements submitted for IESG review
Mar 2013 Control plane requirements submitted for IESG review
Mar 2013 Gap Analysis submitted for IESG review
Apr 2013 Recharter or close Working Group

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 26 Apr 2012 00:58:30 +0100

Does deleting "IETF" in the following
sentence:

"Any documented solutions
will use existing IETF protocols if suitable."

satisfy your concerns?

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 26 Apr 2012 01:00:39 +0100

Those were my thoughts when the text was written.

Stewart

On 26/04/2012 00:57, [email-masked] wrote:
> Joe and Pat,
>
> I'm less concerned about this - I think the words "if suitable" regarding
> use of existing IETF protocols are sufficient to support choosing the best
> solution whether it comes from IETF or elsewhere.  As Pat notes:
>
>> when the time comes, we will debate what is suitable anyway.
> I agree that such a debate is inevitable.
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Joe
>> Pelissier (jopeliss)
>> Sent: Wednesday, April 25, 2012 7:35 PM
>> To: [email-masked]; [email-masked]
>> Cc: IETF Discussion
>> Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-
>> Apr-2012 update
>>
>> I too am uncomfortable with the wording regarding the IETF protocols.
>> It seems that we should be striving to choose the best technical
>> solution regardless of whether its an IETF protocol or that from another
>> SDO. This can, and should, be covered as part of the gap analysis.
>> Also, we should give preference to using existing suitable protocols
>> (IETF or from other SDOs) over development of new protocols.
>>
>> Regards,
>> Joe Pelissier
>>
>>
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Pat Thaler
>> Sent: Wednesday, April 25, 2012 5:55 PM
>> To: Stewart Bryant (stbryant); [email-masked]; [email-masked]
>> Cc: IETF Discussion
>> 25-Apr-2012 update
>> The charter is looking pretty good. I'd like to get on to the next
>> phase, but not with this text:
>> Driven by the requirements and consistent with the gap analysis, the
>> NVO3 WG may request being rechartered to document solutions consisting
>> of one or more data plane encapsulations and control plane protocols as
>> applicable.  Any documented solutions will use existing IETF protocols
>> if suitable. Otherwise, the NVO3 WG may propose the development of new
>> IETF protocols, or the writing of an applicability statement for a
>> non-IETF protocol.
>>
>> There are two issues with this:
>> Is now the right time to be defining the boundaries on what we might
>> request being chartered next? Framework, requirements and gap analysis
>> drafts are still to be written. If we get to the end and find we need
>> something other than or in addition to a data plan encapsulation or
>> control plane protocol, would we not request it to be chartered? Surely
>> once the work is done.
>>
>> Secondly, as this text got rewritten, it gives a preference for IETF
>> protocols over other protocols even if they are standards. There is a
>> part of the work where an IEEE 802.1 protocol, VDP, may turn out to be
>> suitable. Obviously any IETF protocols that are also suitable should be
>> considered but not to the exclusion of consideration for an IEEE
>> protocol.
>>
>> Presumably there is always a preference for using existing protocol if
>> suitable rather than inventing new. It seems unnecessary to state that -
>> when the time comes, we will debate what is suitable anyway.
>>
>> Therefore, at least " Any documented solutions will use existing IETF
>> protocols if suitable. Otherwise, the NVO3 WG may propose the
>> development of new IETF protocols, or the writing of an applicability
>> statement for a non-IETF protocol."  should be deleted.
>>
>> Regards,
>> Pat
>>
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Stewart Bryant
>> Sent: Wednesday, April 25, 2012 2:39 PM
>> To: [email-masked]; [email-masked]
>> Cc: IETF Discussion
>> Subject: [nvo3] WG Review: Network Virtualization Overlays (nvo3) -
>> 25-Apr-2012 update
>>
>> This version of the NVO3 charter reflects the discussions on the list
>> and comments received as of this afternoon.
>>
>> I propose to take this to the IESG for their second review tomorrow.
>>
>> Stewart
>>
>> ======
>>
>> hosts known as virtual machines (VMs). Three  key requirements needed to
>> support multi-tenancy are:
>>
>> An NVO3 solution (known here as a Data Center Virtual Private Network
>> (DCVPN)) is a VPN that is viable across a scaling range of a few
>> thousand VMs to several million VMs running on greater than one hundred
>> thousand physical servers. It thus has good scaling properties from
>> relatively small networks to networks with several million DCVPN
>> endpoints and hundreds of thousands of DCVPNs within a single
>> administrative domain.
>>
>> A DCVPN also supports VM migration between physical servers in a
>> sub-second timeframe.
>>
>> network layer rather than using traditional isolation mechanisms that
>> rely on the underlying layer 2 technology (e.g., VLANs).
>> The NVO3 WG will determine which types of connectivity services are
>> needed by typical DC deployments (for example, IP and/or Ethernet).
>>
>> architectural framework for DCVPNs within a data center environment.
>> Within this framework, functional blocks will be defined to allow the
>> dynamic attachment / detachment of VMs to their DCVPN, and the
>> interconnection of elements of the DCVPNs over the underlying physical
>> network. This will support the delivery of packets to the destination VM
>> within the scaling and migration limits described above.
>>
>> perform a gap analysis of existing candidate mechanisms. In addition to
>> functional and architectural requirements, the NVO3 WG will develop
>> management, operational, maintenance, troubleshooting, security and OAM
>> protocol requirements.
>>
>> The NVO3 WG will investigate the interconnection of the DCVPNs and their
>> tenants with non-NVO3 IP network(s) to determine if any specific work is
>> needed.
>>
>> The NVO3 WG will write the following informational RFCs, which must have
>> completed Working Group Last Call before rechartering can be
>> considered:
>>
>>       Problem Statement
>>       Framework document
>> Driven by the requirements and consistent with the gap analysis, the
>> NVO3 WG may request being rechartered to document solutions consisting
>> of one or more data plane encapsulations and control plane protocols as
>> applicable.  Any documented solutions will use existing IETF protocols
>> if suitable. Otherwise, the NVO3 WG may propose the development of new
>> IETF protocols, or the writing of an applicability statement for
>> non-IETF protocols.
>>
>> If the WG anticipates the adoption  of the technologies of another SDO,
>> such as the IEEE, as part of the solution, it will liaise with that SDO
>> to ensure the compatibility of the approach.
>>
>> Milestones:
>>
>> Dec 2012 Problem Statement submitted for IESG review Dec 2012 Framework
>> document submitted for IESG review Dec 2012 Data plane requirements
>> submitted for IESG review Dec 2012 Operational Requirements submitted
>> for IESG review Mar 2013 Control plane requirements submitted for IESG
>> review Mar 2013 Gap Analysis submitted for IESG review Apr 2013
>> Recharter or close Working Group
>>
>>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Pat Thaler" <[email-masked]>
Date: Wed, 25 Apr 2012 22:54:34 +0000

Stewart,

The charter is looking pretty good. I'd like to get on to the next phase, but not with this text:

There are two issues with this: 
Is now the right time to be defining the boundaries on what we might request being chartered next? Framework, requirements and gap analysis drafts are still to be written. If we get to the end and find we need something other than or in addition to a data plan encapsulation or control plane protocol, would we not request it to be chartered? Surely once the work is done.

Secondly, as this text got rewritten, it gives a preference for IETF protocols over other protocols even if they are standards. There is a part of the work where an IEEE 802.1 protocol, VDP, may turn out to be suitable. Obviously any IETF protocols that are also suitable should be considered but not to the exclusion of consideration for an IEEE protocol.

Presumably there is always a preference for using existing protocol if suitable rather than inventing new. It seems unnecessary to state that - when the time comes, we will debate what is suitable anyway. 

Therefore, at least " Any documented solutions
will use existing IETF protocols if suitable. Otherwise,
the NVO3 WG may propose the development of new IETF protocols,
or the writing of an applicability statement for a non-IETF
protocol."  should be deleted. 

Regards,
Pat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, April 25, 2012 2:39 PM
To: [email-masked]; [email-masked]
Cc: IETF Discussion
Subject: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update

Stewart

======

Chairs - TBD
Area - Routing

     Problem Statement
     Framework document

Milestones:

---

From: "Joe Pelissier (jopeliss)" <[email-masked]>
Date: Wed, 25 Apr 2012 16:35:04 -0700

Regards,
Joe Pelissier

-----Original Message-----

Stewart,

Regards,
Pat

-----Original Message-----

Stewart

======

Chairs - TBD
Area - Routing

   o Address independence, so that one tenant's addressing scheme does
     not collide with other tenant's addressing schemes or with
addresses
     used within the data center itself.

     Problem Statement
     Framework document

Milestones:

---

From: <[email-masked]>
Date: Wed, 25 Apr 2012 19:57:32 -0400

Joe and Pat,

Thanks,
--David

---

From: "Pat Thaler" <[email-masked]>
Date: Thu, 26 Apr 2012 00:23:32 +0000

Yes

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Wednesday, April 25, 2012 4:59 PM
To: Pat Thaler; [email-masked]
Cc: [email-masked]; [email-masked]; IETF Discussion
Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update

satisfy your concerns?

- Stewart

---

From: "Joe Pelissier (jopeliss)" <[email-masked]>
Date: Wed, 25 Apr 2012 17:26:17 -0700

Works for me also...
Thanks!
Joe Pelissier

-----Original Message-----
From: Pat Thaler [mailto:[email-masked]] 
Sent: Wednesday, April 25, 2012 7:24 PM
To: Stewart Bryant (stbryant); Joe Pelissier (jopeliss)
Cc: [email-masked]; [email-masked]; IETF Discussion
Subject: RE: [nvo3] WG Review: Network Virtualization Overlays (nvo3) -
25-Apr-2012 update

Yes

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, April 25, 2012 4:59 PM
To: Pat Thaler; [email-masked]
Cc: [email-masked]; [email-masked]; IETF Discussion
Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) -
25-Apr-2012 update

satisfy your concerns?

- Stewart

---

From: Alan Kavanagh <[email-masked]>
Date: Thu, 26 Apr 2012 14:55:15 -0400

+1 Lets not re-invent the wheel if not needed.

Alan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joe Pelissier (jopeliss)
Sent: April-25-12 7:35 PM
To: [email-masked]; [email-masked]
Cc: IETF Discussion
Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update

I too am uncomfortable with the wording regarding the IETF protocols.
It seems that we should be striving to choose the best technical solution regardless of whether its an IETF protocol or that from another SDO. This can, and should, be covered as part of the gap analysis.
Also, we should give preference to using existing suitable protocols (IETF or from other SDOs) over development of new protocols.

Regards,
Joe Pelissier

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pat Thaler
Sent: Wednesday, April 25, 2012 5:55 PM
To: Stewart Bryant (stbryant); [email-masked]; [email-masked]
Cc: IETF Discussion
Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) -
25-Apr-2012 update

Stewart,

The charter is looking pretty good. I'd like to get on to the next phase, but not with this text:
Driven by the requirements and consistent with the gap analysis, the
NVO3 WG may request being rechartered to document solutions consisting of one or more data plane encapsulations and control plane protocols as applicable.  Any documented solutions will use existing IETF protocols if suitable. Otherwise, the NVO3 WG may propose the development of new IETF protocols, or the writing of an applicability statement for a non-IETF protocol.

Therefore, at least " Any documented solutions will use existing IETF protocols if suitable. Otherwise, the NVO3 WG may propose the development of new IETF protocols, or the writing of an applicability statement for a non-IETF protocol."  should be deleted. 

Regards,
Pat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, April 25, 2012 2:39 PM
To: [email-masked]; [email-masked]
Cc: IETF Discussion
Subject: [nvo3] WG Review: Network Virtualization Overlays (nvo3) -
25-Apr-2012 update

This version of the NVO3 charter reflects the discussions on the list and comments received as of this afternoon.

Stewart

======

Chairs - TBD
Area - Routing

Support for multi-tenancy has become a core requirement of data centers (DCs), especially in the context of data centers supporting virtualized hosts known as virtual machines (VMs). Three  key requirements needed to support multi-tenancy are:

An NVO3 solution (known here as a Data Center Virtual Private Network
(DCVPN)) is a VPN that is viable across a scaling range of a few thousand VMs to several million VMs running on greater than one hundred thousand physical servers. It thus has good scaling properties from relatively small networks to networks with several million DCVPN endpoints and hundreds of thousands of DCVPNs within a single administrative domain.

A DCVPN also supports VM migration between physical servers in a sub-second timeframe.

Note that although this charter uses the term VM throughout, NVO3 must also support connectivity to traditional hosts e.g. hosts that do not have hypervisors.

NVO3 will consider approaches to multi-tenancy that reside at the network layer rather than using traditional isolation mechanisms that rely on the underlying layer 2 technology (e.g., VLANs).
The NVO3 WG will determine which types of connectivity services are needed by typical DC deployments (for example, IP and/or Ethernet).

NVO3 will document the problem statement, the applicability, and an architectural framework for DCVPNs within a data center environment.
Within this framework, functional blocks will be defined to allow the dynamic attachment / detachment of VMs to their DCVPN, and the interconnection of elements of the DCVPNs over the underlying physical network. This will support the delivery of packets to the destination VM within the scaling and migration limits described above.

Based on this framework, the NVO3 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, the NVO3 WG will develop management, operational, maintenance, troubleshooting, security and OAM protocol requirements.

The NVO3 WG will investigate the interconnection of the DCVPNs and their tenants with non-NVO3 IP network(s) to determine if any specific work is needed.

The NVO3 WG will write the following informational RFCs, which must have completed Working Group Last Call before rechartering can be
considered:

     Problem Statement
     Framework document

Driven by the requirements and consistent with the gap analysis, the
NVO3 WG may request being rechartered to document solutions consisting of one or more data plane encapsulations and control plane protocols as applicable.  Any documented solutions will use existing IETF protocols if suitable. Otherwise, the NVO3 WG may propose the development of new IETF protocols, or the writing of an applicability statement for non-IETF protocols.

If the WG anticipates the adoption  of the technologies of another SDO, such as the IEEE, as part of the solution, it will liaise with that SDO to ensure the compatibility of the approach.

Milestones:

Dec 2012 Problem Statement submitted for IESG review Dec 2012 Framework document submitted for IESG review Dec 2012 Data plane requirements submitted for IESG review Dec 2012 Operational Requirements submitted for IESG review Mar 2013 Control plane requirements submitted for IESG review Mar 2013 Gap Analysis submitted for IESG review Apr 2013 Recharter or close Working Group

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 27 Apr 2012 18:29:05 +0000

+1. 

Linda

> Alan Kavanagh
> Sent: Thursday, April 26, 2012 1:55 PM
> To: Joe Pelissier (jopeliss); [email-masked]; [email-masked]
> Cc: IETF Discussion
> Joe Pelissier (jopeliss)
> solution regardless of whether its an IETF protocol or that from
> another SDO. This can, and should, be covered as part of the gap
> analysis.
> IETF protocols, or the writing of an applicability statement for a non-
> IETF protocol.
> 
> suitable rather than inventing new. It seems unnecessary to state that
> - when the time comes, we will debate what is suitable anyway.
> 
> network. This will support the delivery of packets to the destination
> VM within the scaling and migration limits described above.
> 
> The NVO3 WG will investigate the interconnection of the DCVPNs and
> their tenants with non-NVO3 IP network(s) to determine if any specific
> work is needed.
> 
> The NVO3 WG will write the following informational RFCs, which must
> have completed Working Group Last Call before rechartering can be
> considered:
> 
>      Problem Statement
>      Framework document
> IETF protocols, or the writing of an applicability statement for non-
> IETF protocols.
>