Pankaj, I agree that there is the discrepancy in the charter text. I will discuss with the chairs about whether it is a good idea to narrow the encapsulation down to one.
Alia On Thu, Oct 9, 2014 at 5:52 AM, Pankaj Garg <[email protected]> wrote: > Hi Alia, > > > > My comments are inline marked with [PG]. > > > > Thanks > > Pankaj > > > > *From:* Alia Atlas [mailto:[email protected]] > *Sent:* Wednesday, October 8, 2014 7:21 AM > *To:* Pankaj Garg > *Cc:* [email protected]; nvo3 WG > *Subject:* Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) > > > > 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. > > [PG] I agree that having too many standards does not help. In fact, it is > a pain to deal with many protocols all doing the same things but just a > little bit differently. > > My main point was around being consistent in the charter definition. There > are already multiple control plane protocols being used (and I am not > counting BGP/LISP > > in them) for network virtualization and similarly there are multiple data > plane encapsulation formats being used for network virtualization. I see no > reason to allow > > only one control plane protocol and multiple data plane protocols. I feel > the charter text should be consistent and open to one or more protocols. > When the time comes > > for standardization, we should then scrutinize to make sure that multiple > standards are not created just for trivial differences. I am not sure if > charter text itself should > > rule out the possibility of multiple control plane protocols (in future > maybe there are valid reasons to have more than one, who knows?). > > > > > > 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
