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

Benson Schliesser <bensons@queuefull.net> Thu, 14 August 2014 17:45 UTC

Return-Path: <bensons@queuefull.net>
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 DC4711A6F9D for <nvo3@ietfa.amsl.com>; Thu, 14 Aug 2014 10:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 OLo-4eBnsfsK for <nvo3@ietfa.amsl.com>; Thu, 14 Aug 2014 10:45:34 -0700 (PDT)
Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A541A6F9C for <nvo3@ietf.org>; Thu, 14 Aug 2014 10:45:34 -0700 (PDT)
Received: by mail-qc0-f179.google.com with SMTP id m20so1381487qcx.24 for <nvo3@ietf.org>; Thu, 14 Aug 2014 10:45:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qF9IWzP9SmoXlpzDNTwip2bgtyDaw/900Oidweusvys=; b=c3mwlcrtkKQ57y5PeA9swMhqIOdv88lw4yclkq+fhKD/4JsWvXj6dMKYZM6yFq7raq czqwXXAUXYzKvMaplcXeMoLwIgINCanB7RMAmHGnjjW3TL0uSQxj6rRljjYmCgMpmtZ1 LpqGf98FfXypEb3VxBwsqapCYMH5fynJ8/d/c5Jcv4tRTV11vcGa1nTmnhNIolGqIH+W Svb5fquGPL8sGcDl5SzcMn4Hnb5OgIYCQ3yqdgBBfU9Gudn5/bvo8wfJPWLIDiNRR4N3 /vG+H5an3y/gl44fA5Jn9Ny/Z+h3/Rrq1NORvW3187H93AXeeniMyL69Gb6xt+2rCfJC oLdQ==
X-Gm-Message-State: ALoCoQk+Dl26VtlUEvtzT4sDVIEXfKzffAGzjf36Sw+aRSC75C3BS3ngnyzxjdZn7N9c5XtxPnjp
MIME-Version: 1.0
X-Received: by 10.229.184.9 with SMTP id ci9mr19620834qcb.11.1408038333237; Thu, 14 Aug 2014 10:45:33 -0700 (PDT)
Received: by 10.140.37.228 with HTTP; Thu, 14 Aug 2014 10:45:33 -0700 (PDT)
In-Reply-To: <D0124711.683E4%matthew.bocci@alcatel-lucent.com>
References: <186E2FAA-E5C5-4828-8199-4EE71B5A5C1A@queuefull.net> <CAP4=VcgV0RtgqAw3kwQPrU92Pqn2K=0hzg1+MCMH=XdKqNiU_w@mail.gmail.com> <CA+mtBx_npAMhdDCU2a63svo_UJ=NN+iyqqSTk+M5kXBd54BsdQ@mail.gmail.com> <D0124711.683E4%matthew.bocci@alcatel-lucent.com>
Date: Thu, 14 Aug 2014 10:45:33 -0700
Message-ID: <CAP4=VciqA_jasgyNmYz7T7bFrzLWrqwmGRSdNZ0nm+usKRW+Kg@mail.gmail.com>
From: Benson Schliesser <bensons@queuefull.net>
To: Tom Herbert <therbert@google.com>
Content-Type: multipart/alternative; boundary="001a11331fb6aedfe505009a78f5"
Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/5204z3_aR1ZmTtoxBgmvCqST6Dg
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: Thu, 14 Aug 2014 17:45:37 -0000

Hi, Tom. Thanks for the comments.

Just to reiterate / add to Matthew's response: The architecture meant to
describe how the control and data plane protocols relate, not apply to the
datacenter in some broader sense. Maybe it's reasonable to think of this in
terms similar to how IP addressing is coherent across both the IP header
and routing protocols... In the overlay DCVPN we have some kind of mapping
system that ties the planes together, and this would be described by the
architecture.

That being said, assuming this description makes sense to you, do you have
any specific suggestions for improving the charter text? If our intention
wasn't made clear by the charter that we proposed then, by all means, we're
open to improvements.

Thanks,
-Benson




On Thu, Aug 14, 2014 at 3:07 AM, Bocci, Matthew (Matthew) <
matthew.bocci@alcatel-lucent.com> wrote:

> Tom
>
> Thanks for your comments.
>
> The intention is not to try to impose an architecture on data centers. The
> architecture really provides a context in which the data and control plane
> protocols operate, and helps to define the scope of what we can define, or
> what new protocols we need to define in NVO3. If you look at other Wgs
> defining VPN-like technologies (L3VPN, L3VPN, PWE3, etc), they all have
> frameworks or architectures that do this. Ideally the architecture should
> actually help in describing modularity, in that different control/data
> plane protocols could be slotted in to provide different capabilities, as
> required.
>
> Regards
>
> Matthew
>
> On 13/08/2014 21:31, "Tom Herbert" <therbert@google.com> wrote:
>
> >On Wed, Aug 13, 2014 at 12:41 PM, Benson Schliesser
> ><bensons@queuefull.net> wrote:
> >> Just a reminder that Matthew and I are looking for feedback on the draft
> >> text of a new NVO3 charter. Can it be that we wrote a charter so perfect
> >> there are no comments..?
> >>
> >Maybe just a request for clarification...
> >
> >Unless I am misreading this, it seems to me that the intent is to
> >create a packaged solution for data centers that combines data plane,
> >control, and architecture. I think these are actually very separate
> >facets and should really be mostly separate tracks. I would liken this
> >to how IP, routing protocols, and our current data center architecture
> >has evolved. These were never defined together and so the dependencies
> >between them have always been quite minimal. This has allowed us to
> >completely change one part with redoing the rest of world (e.g.
> >IPv4->IPv6, decentralized routing to open flow,..).
> >
> >It might also be nice to clarify a little more what the ultimate
> >output is of the WG. I assume the tangible output here would be
> >standardized data plane protocol(s) and control plane protocol(s).
> >Architecture is nice to provide a context for the protocols, but not
> >really something that can be standardized in itself. Every existing DC
> >already has an existing architecture (even before virtualization), it
> >is much more likely that we'd want to adapt and leverage the existing
> >architecture as much as possible rather than change the whole world to
> >accommodate NV-- which I guess is another way of saying data plane,
> >control plane, architecture need to be considered independently.
> >
> >Hope this helps :-)
> >
> >Tom
> >
> >> The draft charter text is quoted in my email below. For reference it can
> >> also be found at
> >>
> >>
> http://svn.tools.ietf.org/svn/wg/nvo3/charter-ietf-nvo3-01-rev-20140808.t
> >>xt
> >>
> >> Cheers,
> >> -Benson & Matthew
> >>
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: Benson Schliesser <bensons@queuefull.net>
> >> Date: Fri, Aug 8, 2014 at 4:53 PM
> >> Subject: DRAFT Charter Update for Discussion
> >> To: 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.
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> nvo3 mailing list
> >> nvo3@ietf.org
> >> https://www.ietf.org/mailman/listinfo/nvo3
> >>
> >
> >_______________________________________________
> >nvo3 mailing list
> >nvo3@ietf.org
> >https://www.ietf.org/mailman/listinfo/nvo3
>
>