Hi Pankaj, On Tue, Oct 7, 2014 at 9:36 PM, Pankaj Garg <[email protected]> wrote:
> What is the reason for restricting the charter to only adopt one protocol > for control plane, while allowing one or more protocols for data plane > encapsulation? > There are already other ways (BGP-based, even potentially LISP-based) for the control plane; the argument in NVO3 is that the logically centralized NVA is representing a different architecture. Different operators can choose the appropriate mechanism for their data-centers. At some point, however, having too many standards doesn't help. If anything, I would be more tempted to restrict the data plane encapsulation to only one; I would certainly expect to see very strong reasoning for why more than one data plane encapsulation would be necessary. > I feel it should be fine for the WG to adopt one or more protocols for > both control plane and data plane as required to meet the requirements. > If the working group really can't get agreement on a single protocol, then we'll be forced to discuss if there's an explicit experiment that could be done to clarify which way is better to go forward. Otherwise, maybe the industry isn't ready to standardize yet. Regards, Alia > Thanks > Pankaj > > > -----Original Message----- > > From: nvo3 [mailto:[email protected]] On Behalf Of The IESG > > Sent: Saturday, October 4, 2014 2:05 AM > > To: IETF-Announce > > Cc: nvo3 WG > > Subject: [nvo3] WG Review: Network Virtualization Overlays (nvo3) > > > > The Network Virtualization Overlays (nvo3) working group in the Routing > > Area of the IETF is undergoing rechartering. The IESG has not made any > > determination yet. The following draft charter was submitted, and is > > provided for informational purposes only. Please send your comments to > the > > IESG mailing list (iesg at ietf.org) by 2014-10-13. > > > > Network Virtualization Overlays (nvo3) > > ------------------------------------------------ > > Current Status: Active WG > > > > Chairs: > > Matthew Bocci <[email protected]> > > Benson Schliesser <[email protected]> > > > > Secretaries: > > Sam Aldrin <[email protected]> > > > > Technical advisors: > > Ron Bonica <[email protected]> > > > > Assigned Area Director: > > Alia Atlas <[email protected]> > > > > Mailing list > > Address: [email protected] > > To Subscribe: https://www.ietf.org/mailman/listinfo/nvo3 > > Archive: http://www.ietf.org/mail-archive/web/nvo3/ > > > > Charter: > > > > The purpose of the NVO3 WG is to develop a set of protocols and/or > protocol > > extensions that enable network virtualization within a data center (DC) > > environment that assumes an IP-based underlay. An NVO3 solution provides > > layer > > 2 and/or layer 3 services for virtual networks enabling multi-tenancy and > > workload mobility, addressing the issues described in the problem > statement > > (including management and security), and consistent with the framework > > previously produced by the NVO3 WG. > > > > The NVO3 WG will develop solutions for network virtualization based on > the > > following architectural tenets: > > - Support for an IP-based underlay data plane > > - A logically centralized authority for network virtualization Network > > virtualization approaches that do not adhere to these tenets are > explicitly > > outside of the scope of the NVO3 WG. > > > > In pursuit of the solutions described above, the NVO3 WG will document an > > architecture for network virtualization within a data center environment. > > > > The NVO3 WG may produce requirements for a network virtualization > > control plane, and will select, extend, and/or develop one protocol for > each > > of the functional interfaces identified to support the architecture. Such > > protocols are expected to fulfill the communication requirements between > > an End Device and a Network Virtualization Edge > > (NVE) in cases where the NVE is not co-resident with the End Device, and > > between an NVE and the Network Virtualization Authority (NVA). > > The internal mechanisms and protocols of a logically centralized NVA are > > explicitly out of scope of the NVO3 WG. Architectural issues raised by > > coexistence of multiple logically centralized control planes in the same > data > > center may be considered by the WG. Inter-DC mechanisms are not in scope > > of the NVO3 WG at this time. > > > > The NVO3 WG may produce requirements for network virtualization data > > planes based on encapsulation of virtual network traffic over an IP-based > > underlay data plane. Such requirements should consider OAM and security. > > Based on these requirements the WG will select, extend, and/or develop > > one or more data plane encapsulation format(s). > > > > Additionally, the WG may document common use-cases for NVO3 solutions. > > > > The working group may choose to adopt a protocol or data encapsulation > > that was previously worked on outside the IETF as the basis for the WG's > > work. If the NVO3 WG anticipates the adoption of the technologies of > > another SDO as part of the selected protocols or data encapsulation, the > > NVO3 WG will first liaise with that SDO to ensure the compatibility of > the > > approach. > > > > The NVO3 WG will not consider solutions to network virtualization within > a > > data center environment based on extensions to BGP or LISP protocols. > > > > > > Milestones: > > > > > > _______________________________________________ > > nvo3 mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/nvo3 > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
