Subject: [nvo3] Reflecting the discussion into the charter

From: Stewart Bryant <[email-masked]>
Date: Wed, 11 Apr 2012 17:11:41 +0100

It is important that we take care to distinguish between
charter issues i.e. the WG scope and deliverables and
and the requirements/architecture/solutions.

We need to converge on the charter text before we can
work on solutions.

I had an IAB comment about the following text and
what a "non-virtualized end system" is in the Internet
Architecture.

"(Note: Although this charter uses the term VM throughout,
the scope of NVO3 is intended to  include non-virtualized
end systems.)"

I wonder if we should say something like:

"(Note: Although this
  charter uses the term VM throughout, NVO3 must also support
  connectivity to traditional hosts.)"

========

There was a lot of discussion regarding addressing
at various levels of the connection hierarchy. We need
to solve this, but from a charter point of view we
only need to determine a set of words that make us
do the right thing.

I wonder if it is sufficient to add the following note:

"The WG will consider the addressing and address
mapping needed to support the interconnection
of VMs within a DC. "

and then extent the following statement:

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

to say

"The WG will investigate interconnection and interoperation issues
(including the addressing issues) between overlays and VPNs to
determine if any specific work is needed."

There was also a note that we need to remember that the
VMs need to connect to the Internet, so a further refinement would
be

"The WG will investigate interconnection and interoperation issues
(including the addressing issues) between overlays and between
VPNs and to the Internet to determine if any specific work is needed."

==========

There is lots of really useful detailed discussion but this seems
related to content of the documents that need to be written
and not to the text of the charter itself.

I have reflected the above in the charter text below.

Is there a consensus that the text below sufficiently reflects
the views of the list such that we can put it to IESG review
and then IETF Last Call to get wider feedback?

Stewart

==========
==========

  NVO3: Network Virtualization Overlays

Chairs - TBD
Area - Routing
Area Director - Stewart Bryant
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
  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, NVO3 must also support
  connectivity to traditional hosts.)

  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.
The WG will consider the addressing and address mapping needed
to support the interconnection  of VMs within a DC.

  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
  (including the addressing issues) between overlays and between
  VPNs and to the Internet 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) - 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: Thomas Narten <[email-masked]>
Date: Wed, 11 Apr 2012 15:47:16 -0400

Hi Stewart.

> and the requirements/architecture/solutions.

Agreed. IMO, most of the discussion on the list has really been about
the work itself, rather than charter issues.

If there are specific concerns with the proposed charter text, it
would be helpful to be clear about which text is problematic (and
why).

> We need to converge on the charter text before we can

:-)

>   connectivity to traditional hosts.)"

I'm  fine with this. 

> mapping needed to support the interconnection

I'm not at all clear on what "consider the addressing ... needed to
support the interconnection" entails.

The tenant chooses whatever VM addresses it wants.

The DC operator chooses whatever addresses it wants for its
infrastructure.

NVO3 just uses those addresses. It maps addresses (VM addresses to
infrastructure addresses), but it doesn't place any requirements on
what those addresses can be.

Hence, I'm not sure what the reference to "addressing" would refer to.

What am I missing?

> determine if any specific work is needed."

Again, I don't understand the "addressing issues" component.

> VPNs and to the Internet to determine if any specific work is

Personally, I don't understand why that wording is necessary. I don't
believe NVO3 creates any new issues with regards to VMs communicating
with the public Internet. Whatever issues are there, already exist
today with hosts connected to traditional VPNs, DCs implemented in
VLANs, etc.

Remember, from a VM's perspective, it doesn't even know its connected
through an NVO3 overlay. It thinks its connected to a real network...

If there is a problem or issue here, I'd like to better understand
what it is before we add it to the charter.

Thomas

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Wed, 11 Apr 2012 13:03:42 -0700

Greetings,

> connectivity to traditional hosts.)"

I would make this a bit more specific 
(Note: Although this charter uses the term VM throughout, NVO3 must support connectivity to any network endpoint).  Or, we could SED the document and replace VM with endnode.

> mapping needed to support the interconnection

Sounds fine

> determine if any specific work is needed."

This will invite the overlay vs. VPN discussion.  

> VPNs and to the Internet to determine if any specific work is needed."

How about
"The WG will investigate the interconnection of the overlay fabric (and tenants) with non-NVO3 IP network(s), including classical intranets, the public Internet, VPN infrastructures, etc."

> 2) Control plane requirements document (Informational RFC) - November 2012
> 
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

--  
李柯睿
Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc
Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf
Check my calendar availability: https://tungle.me/cdl