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

"Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com> Thu, 14 August 2014 10:09 UTC

Return-Path: <matthew.bocci@alcatel-lucent.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 EAE131A09B9 for <nvo3@ietfa.amsl.com>; Thu, 14 Aug 2014 03:09:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level:
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MyxH-zI1Z4e8 for <nvo3@ietfa.amsl.com>; Thu, 14 Aug 2014 03:09:14 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7B6B1A09D7 for <nvo3@ietf.org>; Thu, 14 Aug 2014 03:08:19 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id AD70D223C6CD9; Thu, 14 Aug 2014 10:08:16 +0000 (GMT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s7EA8DiQ017561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Aug 2014 12:08:17 +0200
Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.23]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 14 Aug 2014 12:07:55 +0200
From: "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>
To: Tom Herbert <therbert@google.com>, Benson Schliesser <bensons@queuefull.net>
Thread-Topic: [nvo3] Fwd: DRAFT Charter Update for Discussion
Thread-Index: AQHPty6mOThWjn5BEEOhKCmX8jb/cZvO2zaAgAD05oA=
Date: Thu, 14 Aug 2014 10:07:54 +0000
Message-ID: <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>
In-Reply-To: <CA+mtBx_npAMhdDCU2a63svo_UJ=NN+iyqqSTk+M5kXBd54BsdQ@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.3.140616
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="utf-8"
Content-ID: <25C75CB7E2049242A50197F6D32B4396@exchange.lucent.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/FtWzklDtwSgf3VzKmhbeLHCH1S4
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 10:09:18 -0000

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