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) < [email protected]> 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" <[email protected]> wrote: > > >On Wed, Aug 13, 2014 at 12:41 PM, Benson Schliesser > ><[email protected]> 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 <[email protected]> > >> Date: Fri, Aug 8, 2014 at 4:53 PM > >> Subject: DRAFT Charter Update for Discussion > >> To: [email protected] > >> > >> > >> 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/nvo3 > >> > > > >_______________________________________________ > >nvo3 mailing list > >[email protected] > >https://www.ietf.org/mailman/listinfo/nvo3 > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
