Re: [nvo3] Fwd: DRAFT Charter Update for Discussion

"Fedyk, Don" <don.fedyk@hp.com> Fri, 15 August 2014 11:32 UTC

Return-Path: <don.fedyk@hp.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0799E1A09F4 for <nvo3@ietfa.amsl.com>; Fri, 15 Aug 2014 04:32:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.867
X-Spam-Level:
X-Spam-Status: No, score=-4.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENwQtSWlkD61 for <nvo3@ietfa.amsl.com>; Fri, 15 Aug 2014 04:32:11 -0700 (PDT)
Received: from g6t1525.atlanta.hp.com (g6t1525.atlanta.hp.com [15.193.200.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 150A31A09EE for <nvo3@ietf.org>; Fri, 15 Aug 2014 04:32:10 -0700 (PDT)
Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t1525.atlanta.hp.com (Postfix) with ESMTPS id 24DFB157; Fri, 15 Aug 2014 11:32:10 +0000 (UTC)
Received: from G6W3997.americas.hpqcorp.net (16.205.80.212) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.169.1; Fri, 15 Aug 2014 11:29:58 +0000
Received: from G6W2492.americas.hpqcorp.net ([169.254.8.167]) by G6W3997.americas.hpqcorp.net ([16.205.80.212]) with mapi id 14.03.0169.001; Fri, 15 Aug 2014 11:29:59 +0000
From: "Fedyk, Don" <don.fedyk@hp.com>
To: "Larry Kreeger (kreeger)" <kreeger@cisco.com>, Benson Schliesser <bensons@queuefull.net>
Thread-Topic: [nvo3] Fwd: DRAFT Charter Update for Discussion
Thread-Index: AQHPty6jvzNqL+3Y5UKxbhGmyn3FaJvQRdOwgAAfPICAAEvfAIAA2ITA
Date: Fri, 15 Aug 2014 11:29:57 +0000
Message-ID: <A46D9C092EA46F489F135060986AD9FF0F84E847@G6W2492.americas.hpqcorp.net>
References: <186E2FAA-E5C5-4828-8199-4EE71B5A5C1A@queuefull.net> <CAP4=VcgV0RtgqAw3kwQPrU92Pqn2K=0hzg1+MCMH=XdKqNiU_w@mail.gmail.com> <A46D9C092EA46F489F135060986AD9FF0F84E5F2@G6W2492.americas.hpqcorp.net> <CAP4=VchLtcJBUnw44g5UKXTuF-0fpSh2HdfWGMLUJCUJhQ1mHg@mail.gmail.com> <D01285AD.11ADB0%kreeger@cisco.com>
In-Reply-To: <D01285AD.11ADB0%kreeger@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [15.193.49.19]
Content-Type: multipart/alternative; boundary="_000_A46D9C092EA46F489F135060986AD9FF0F84E847G6W2492americas_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/MruCnzLyVwp3PLYyDjTZoFYrOkQ
Cc: "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] Fwd: DRAFT Charter Update for Discussion
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <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: Fri, 15 Aug 2014 11:32:14 -0000

+1
I'm good with Larry's suggestions.  It might be time for another draft incorporating the changes to comment on.

Don

From: Larry Kreeger (kreeger) [mailto:kreeger@cisco.com]
Sent: Thursday, August 14, 2014 6:33 PM
To: Benson Schliesser; Fedyk, Don
Cc: nvo3@ietf.org
Subject: Re: [nvo3] Fwd: DRAFT Charter Update for Discussion

Hi Benson,

I do think Don's additional text is useful.  I am a little bit concerned with the word "mobility" since I often hear it used in relation to mobile devices (e.g. cell phones).  The problem statement mostly discusses "virtual machine mobility", so I would be more comfortable with that.

Also, "multi-site" seems to be a new expansion of scope and may run up against solutions coming from the L2VPN/L3VPN WG.  Rather than taking that on, perhaps it is better to cover how NVO3 solutions can interwork with L2VPN/L3VPN solutions.

Thanks, Larry

From: Benson Schliesser <bensons@queuefull.net<mailto:bensons@queuefull.net>>
Date: Thursday, August 14, 2014 11:01 AM
To: "Fedyk, Don" <don.fedyk@hp.com<mailto:don.fedyk@hp.com>>
Cc: "nvo3@ietf.org<mailto:nvo3@ietf.org>" <nvo3@ietf.org<mailto:nvo3@ietf.org>>
Subject: Re: [nvo3] Fwd: DRAFT Charter Update for Discussion

Hi, Don. Thanks for the specific, constructive feedback.

The sparseness was an intentional choice aimed at making the charter more concise. But I'm perfectly comfortable admitting that I may have taken it too far... Your proposed text seems like a pretty good improvement to me.

I'd be interested in hearing feedback from other participants here.

Cheers,
-Benson




On Thu, Aug 14, 2014 at 9:19 AM, Fedyk, Don <don.fedyk@hp.com<mailto:don.fedyk@hp.com>> wrote:
The first paragraph seems a little sparse.  One would have to read the problem statement and framework to determine the scope.

My suggestion is expanding something like this:

An NVO3 solution, also known as a Data Center Virtual Private Network (DCVPN), is a set of protocols and/or protocol extensions that address providing both Layer 2 and Layer 3 Services within and between DCVPNs.The issues addressed include virtualization, multi-tenancy, multi-site, mobility, optimization, management and securityas described by draft-ietf-nvo3-overlay-problem-statement consistent with the approach described by draft-ietf-nvo3-framework.

I'd also suggest expanding NVA and NVE acronyms.

Cheers,
Don
---------- Forwarded message ----------
From: Benson Schliesser <bensons@queuefull.net<mailto:bensons@queuefull.net>>
Date: Fri, Aug 8, 2014 at 4:53 PM
Subject: DRAFT Charter Update for Discussion
To: nvo3@ietf.org<mailto:nvo3@ietf.org>


Dear NVO3 Contributors -

As discussed during the NVO3 meeting at IETF-90 in Toronto, the chairs have been drafting a new / revised charter for the WG. The latest draft charter text is below for your review.

Frankly, we suspect that some of the wording could be further improved to be more clear and/or precise. With that in mind we ask for your help - please let us know if something seems unclear or if you have suggestions for better wording.

If you have feedback please post it to the list for discussion within the next 2 weeks.

Thanks,
-Benson & Matthew

An NVO3 solution, also known as a Data Center Virtual Private Network (DCVPN),
is a set of protocols and/or protocol extensions that address the issues
described by draft-ietf-nvo3-overlay-problem-statement consistent with the
approach described by draft-ietf-nvo3-framework.

NVO3 will document DCVPN requirements for both control plane protocol(s) and
data plane encapsulation format(s), as well as management, operational,
maintenance, troubleshooting, security and OAM protocol requirements.
Additionally, NVO3 will document common use-cases for DCVPN solutions.

Consistent with the documents described above, the NVO3 WG will document an
architecture for DCVPNs within a data center environment based on the following
architectural design points:
-   A logically centralized NVA control plane
-   Support for an underlay IP data plane between NVEs

Based on this architecture the NVO3 WG will develop one or more NVO3 solutions.
This may include documenting applicability of existing protocols, contributing
to the development of protocol extensions by other WGs and/or SDOs, and/or
developing new protocols as appropriate.

Solutions and/or protocols that were developed outside of the IETF, but not
developed by another SDO, and that have multiple interoperable implementations
may be adopted by the NVO3 WG for further development, based on WG consensus,
if requested by the authors .

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