Subject: [nvo3] WG Review: Network Virtualization Overlays (nvo3)

From: The IESG <[email-masked]>
Date: Fri, 03 Oct 2014 13:35:12 -0700

The Network Virtualization Overlays (nvo3) working group in the Routing
Area of the IETF is undergoing rechartering. The IESG has not made any
determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to
the IESG mailing list (iesg at ietf.org) by 2014-10-13.

Network Virtualization Overlays (nvo3)
------------------------------------------------
Current Status: Active WG

Chairs:
  Matthew Bocci <[email-masked]>
  Benson Schliesser <[email-masked]>

Secretaries:
  Sam Aldrin <[email-masked]>

Technical advisors:
  Ron Bonica <[email-masked]>

Assigned Area Director:
  Alia Atlas <[email-masked]>

Mailing list
  Address: [email-masked]
  To Subscribe: https://www.ietf.org/mailman/listinfo/nvo3
  Archive: http://www.ietf.org/mail-archive/web/nvo3/

Charter:

The purpose of the NVO3 WG is to develop a set of protocols and/or
protocol
extensions that enable network virtualization within a data center (DC)
environment that assumes an IP-based underlay. An NVO3 solution provides
layer
2 and/or layer 3 services for virtual networks enabling multi-tenancy and
workload mobility, addressing the issues described in the problem
statement
(including management and security), and consistent with the framework
previously produced by the NVO3 WG.

The NVO3 WG will develop solutions for network virtualization based on
the following architectural tenets:
 - Support for an IP-based underlay data plane
 - A logically centralized authority for network virtualization
Network virtualization approaches that do not adhere to these tenets are
explicitly outside of the scope of the NVO3 WG.

In pursuit of the solutions described above, the NVO3 WG will document an
architecture for network virtualization within a data center environment.

The NVO3 WG may produce requirements for a network virtualization
control plane, and will select, extend, and/or develop one protocol
for each of the functional interfaces identified to support the
architecture. Such protocols are expected to fulfill the communication
requirements between an End Device and a Network Virtualization Edge
(NVE) in cases where the NVE is not co-resident with the End Device,
and between an NVE and the Network Virtualization Authority (NVA).
The internal mechanisms and protocols of a logically centralized NVA
are explicitly out of scope of the NVO3 WG.  Architectural issues
raised by coexistence of multiple logically centralized control planes
in the same data center may be considered by the WG. Inter-DC
mechanisms are not in scope of the NVO3 WG at this time.

The NVO3 WG may produce requirements for network virtualization data
planes based on encapsulation of virtual network traffic over an IP-based
underlay data plane. Such requirements should consider OAM and security. Based on
these requirements the WG will select, extend, and/or develop one or more data
plane encapsulation format(s).

Additionally, the WG may document common use-cases for NVO3 solutions.

The working group may choose to adopt a protocol or data encapsulation
that was previously worked on outside the IETF as the basis for the WG's work.  If
the NVO3 WG anticipates the adoption of the technologies of another SDO as
part of the selected protocols or data encapsulation, the NVO3 WG will first
liaise with that SDO to ensure the compatibility of the approach.

The NVO3 WG will not consider solutions to network virtualization
within a data center environment based on extensions to BGP or LISP
protocols.

Milestones:

---

From: Pankaj Garg <[email-masked]>
Date: Wed, 8 Oct 2014 01:36:01 +0000

What is the reason for restricting the charter to only adopt one protocol for control plane, while allowing one or more protocols for data plane encapsulation?

I feel it should be fine for the WG to adopt one or more protocols for both control plane and data plane as required to meet the requirements.

Thanks
Pankaj

> -----Original Message-----
> From: nvo3 [mailto:[email-masked]] On Behalf Of The IESG
> Sent: Saturday, October 4, 2014 2:05 AM
> To: IETF-Announce
> Cc: nvo3 WG
> Subject: [nvo3] WG Review: Network Virtualization Overlays (nvo3)
> 
> provided for informational purposes only. Please send your comments to the
> IESG mailing list (iesg at ietf.org) by 2014-10-13.
> 
> The purpose of the NVO3 WG is to develop a set of protocols and/or protocol
> workload mobility, addressing the issues described in the problem statement
> The NVO3 WG will develop solutions for network virtualization based on the
> following architectural tenets:
>  - A logically centralized authority for network virtualization Network
> virtualization approaches that do not adhere to these tenets are explicitly
> outside of the scope of the NVO3 WG.
> 
> control plane, and will select, extend, and/or develop one protocol for each
> of the functional interfaces identified to support the architecture. Such
> protocols are expected to fulfill the communication requirements between
> an End Device and a Network Virtualization Edge
> (NVE) in cases where the NVE is not co-resident with the End Device, and
> between an NVE and the Network Virtualization Authority (NVA).
> The internal mechanisms and protocols of a logically centralized NVA are
> explicitly out of scope of the NVO3 WG.  Architectural issues raised by
> coexistence of multiple logically centralized control planes in the same data
> center may be considered by the WG. Inter-DC mechanisms are not in scope
> of the NVO3 WG at this time.
> 
> underlay data plane. Such requirements should consider OAM and security.
> Based on these requirements the WG will select, extend, and/or develop
> one or more data plane encapsulation format(s).
> 
> that was previously worked on outside the IETF as the basis for the WG's
> work.  If the NVO3 WG anticipates the adoption of the technologies of
> another SDO as part of the selected protocols or data encapsulation, the
> NVO3 WG will first liaise with that SDO to ensure the compatibility of the
> approach.
> 
> The NVO3 WG will not consider solutions to network virtualization within a
> data center environment based on extensions to BGP or LISP protocols.
> 
> 
> Milestones:
> 
> 
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: Alia Atlas <[email-masked]>
Date: Tue, 7 Oct 2014 21:50:45 -0400

Hi Pankaj,

On Tue, Oct 7, 2014 at 9:36 PM, Pankaj Garg <[email-masked]>
wrote:

> What is the reason for restricting the charter to only adopt one protocol
> for control plane, while allowing one or more protocols for data plane
> encapsulation?
>

There are already other ways (BGP-based, even potentially LISP-based) for
the control plane; the argument in NVO3 is that the logically centralized
NVA is representing a different architecture.  Different operators can
choose the appropriate mechanism for their data-centers.  At some point,
however, having too many standards doesn't help.  If anything, I would be
more tempted to restrict the data plane encapsulation to only one; I would
certainly expect to see very strong reasoning for why more than one data
plane encapsulation would be necessary.

> I feel it should be fine for the WG to adopt one or more protocols for
> both control plane and data plane as required to meet the requirements.
>

If the working group really can't get agreement on a single protocol, then
we'll be forced to discuss if there's an explicit experiment that could be
done to clarify which way is better to go forward.  Otherwise, maybe the
industry isn't ready to standardize yet.

Regards,
Alia

> the

---

From: Pankaj Garg <[email-masked]>
Date: Thu, 9 Oct 2014 09:52:14 +0000

Hi Alia,

My comments are inline marked with [PG].

Thanks
Pankaj

From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, October 8, 2014 7:21 AM
To: Pankaj Garg
Cc: [email-masked]; nvo3 WG
Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3)

Hi Pankaj,

On Tue, Oct 7, 2014 at 9:36 PM, Pankaj Garg <[email-masked]<mailto:[email-masked]>> wrote:
What is the reason for restricting the charter to only adopt one protocol for control plane, while allowing one or more protocols for data plane encapsulation?

There are already other ways (BGP-based, even potentially LISP-based) for the control plane; the argument in NVO3 is that the logically centralized
NVA is representing a different architecture.  Different operators can choose the appropriate mechanism for their data-centers.  At some point,
however, having too many standards doesn't help.  If anything, I would be more tempted to restrict the data plane encapsulation to only one; I would
certainly expect to see very strong reasoning for why more than one data plane encapsulation would be necessary.
[PG] I agree that having too many standards does not help. In fact, it is a pain to deal with many protocols all doing the same things but just a little bit differently.
My main point was around being consistent in the charter definition. There are already multiple control plane protocols being used (and I am not counting BGP/LISP
in them) for network virtualization and similarly there are multiple data plane encapsulation formats being used for network virtualization. I see no reason to allow
only one control plane protocol and multiple data plane protocols. I feel the charter text should be consistent and open to one or more protocols. When the time comes
for standardization, we should then scrutinize to make sure that multiple standards are not created just for trivial differences. I am not sure if charter text itself should
rule out the possibility of multiple control plane protocols (in future maybe there are valid reasons to have more than one, who knows?).

If the working group really can't get agreement on a single protocol, then we'll be forced to discuss if there's an explicit experiment that could be
done to clarify which way is better to go forward.  Otherwise, maybe the industry isn't ready to standardize yet.

Regards,
Alia

Thanks
Pankaj

> From: nvo3 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of The IESG
> IESG mailing list (iesg at ietf.org<http://ietf.org>) by 2014-10-13.
>
>   Matthew Bocci <[email-masked]<mailto:[email-masked]>>
>   Benson Schliesser <[email-masked]<mailto:[email-masked]>>
>
> Secretaries:
>   Sam Aldrin <[email-masked]<mailto:[email-masked]>>
>
> Technical advisors:
>   Ron Bonica <[email-masked]<mailto:[email-masked]>>
>
> Assigned Area Director:
>   Alia Atlas <[email-masked]<mailto:[email-masked]>>
>
> Mailing list
>   Address: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 9 Oct 2014 12:06:39 -0400

Pankaj,

I agree that there is the discrepancy in the charter text.  I will discuss
with the chairs
about whether it is a good idea to narrow the encapsulation down to one.

Alia

On Thu, Oct 9, 2014 at 5:52 AM, Pankaj Garg <[email-masked]>
wrote:

> *From:* Alia Atlas [mailto:[email-masked]]
> *Sent:* Wednesday, October 8, 2014 7:21 AM
> *To:* Pankaj Garg
> *Cc:* [email-masked]; nvo3 WG
> *Subject:* Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3)
>
>
>
> Hi Pankaj,
>
>
>
> [PG] I agree that having too many standards does not help. In fact, it is
> a pain to deal with many protocols all doing the same things but just a
> little bit differently.
>
> My main point was around being consistent in the charter definition. There
> are already multiple control plane protocols being used (and I am not
> counting BGP/LISP
>
> in them) for network virtualization and similarly there are multiple data
> plane encapsulation formats being used for network virtualization. I see no
> reason to allow
>
> only one control plane protocol and multiple data plane protocols. I feel
> the charter text should be consistent and open to one or more protocols.
> When the time comes
>
> for standardization, we should then scrutinize to make sure that multiple
> standards are not created just for trivial differences. I am not sure if
> charter text itself should
>
> rule out the possibility of multiple control plane protocols (in future
> maybe there are valid reasons to have more than one, who knows?).
>
>
>
>
>