IETF Logo Mail Archive

[nvo3] Updated Charter

Benson Schliesser <bschlies@cisco.com> Tue, 27 March 2012 17:11 UTC

Return-Path: <bschlies@cisco.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6926D21F86F6 for <nvo3@ietfa.amsl.com>; Tue, 27 Mar 2012 10:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.352
X-Spam-Level:
X-Spam-Status: No, score=-9.352 tagged_above=-999 required=5 tests=[AWL=1.247, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpiZQR7ivIYo for <nvo3@ietfa.amsl.com>; Tue, 27 Mar 2012 10:11:40 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1D30821F86F3 for <nvo3@ietf.org>; Tue, 27 Mar 2012 10:11:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=3059; q=dns/txt; s=iport; t=1332868300; x=1334077900; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=cAUIgMmjkuP9CUoX2+iOrjtkm0YDl+yBh+mlm4qreiw=; b=CyTKBYAGCRmr8Ef0YCAJEOKniOHU00Uc+o+ox14arXvZsHedtWnkX5ue r54VARjKB6eleeLOSVyCswI4ztVbGnbfbsbb8M54BzQbZdAQ/FPBJz8h4 P8XVky5th3rRihxaYUAbSmTrBmX6DqlS8Evlv9yTSlzsLAjVqvI7PsLYh E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqkFAA30cU+Q/khN/2dsb2JhbABFtT+DB4EHgiIBJzQLLX1CB4domzufDopigwmCQWMElWGORYFogmmBUg
X-IronPort-AV: E=Sophos;i="4.73,658,1325462400"; d="scan'208";a="133516382"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 27 Mar 2012 17:11:35 +0000
Received: from dhcp-15f3.meeting.ietf.org (ams3-vpn-dhcp4722.cisco.com [10.61.82.113]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2RHBZr4013522; Tue, 27 Mar 2012 17:11:35 GMT
From: Benson Schliesser <bschlies@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 27 Mar 2012 19:11:35 +0200
Message-Id: <4FAEEF73-B9C3-4033-BE49-0E1784C6D154@cisco.com>
To: nvo3@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: Thomas Narten <narten@us.ibm.com>, "Matthew (Matthew) Bocci" <matthew.bocci@alcatel-lucent.com>
Subject: [nvo3] Updated Charter
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "L2 \"Network Virtualization Over l3\" overlay discussion list \(nvo3\)" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nvo3>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Mar 2012 17:11:41 -0000

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

v2.23.0 | Report a Bug | By Email