One last try to split this nose hair: NVA: Find "logically centralized" replace with "logically distinguished" a service defined by the NVE-NVA interface
(and not by implementation eg BGP, DHT, X500..) The NVO3 WG will develop solutions for network virtualization based on the following architectural tenets: - Support for an IP-based underlay data plane - A Network Virtualization Edge (NVE) that sits at the edge of an underlay network and provides L2 and/or L3 network virtualization functions to Tenant Systems - A logically distinguished Network Virtualization Authority (NVA), a service that NVEs interact with to obtain the information necessary to provide a virtualized service, and is defined by the NVE-NVA interface and API. --szb > On Sep 8, 2014, at 12:08 PM, "Thomas Narten" <[email protected]> wrote: > > Hi Benson. > > Thanks for the updated charter. Here are some possible wording > clarifications. I do not believe the change the charter in a material > way (and are not intended to). But they may make aspects of it a bit > clearer. > >> http://svn.tools.ietf.org/svn/wg/nvo3/charter-ietf-nvo3-01-rev-20140901.txt >> >> 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 using an IP-based overlay approach. An NVO3 solution provides >> layer >> 2 and/or layer 3 services for virtual networks enabling multi-tenancy, >> workload >> mobility, optimization, management, and security, addressing the issues >> described in the problem statement and consistent with the framework >> previously >> produced by the NVO3 WG. > > better: > > I suggest removing " optimization, management, and security" because > they are not things that are "enabled" by NVO3 per se. At least not > without more words explaining what is meant. If I were an IESG member, > I'd ask "what do those words mean?". I think all these things are > covered in the problem statement/framework anyway, and folk with > questions should be pointed there. > >> 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. > > The above (mentioning logically centralized) I think continues to be > confusing because it could use more context. How about: > > The NVO3 WG will develop solutions for network virtualization based on the > following architectural tenets: > - Support for an IP-based underlay data plane > - A Network Virtualization Edge (NVE) that sits at the edge of an > underlay network and provides L2 and/or L3 network virtualization > functions to Tenant Systems > - A logically centralized Network Virtualization Authority (NVA) > that NVEs interact with to obtain the information necessary to > provide a virtualized service. > 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 or more control plane >> protocols to support the architecture. Such protocols are expected to fulfill >> the communication requirements between an End Device and Network >> Virtualization >> Edge (NVE), 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. > > Above can be shortened or redone based on previous suggestion. Also, > actually think the use of "end device" above is not sufficient/precise > enough, because we are NOT talking about a generic "end device", but > the split-NVE case in particular. Better to just say that. (And note > that the WG document that covers this case is > draft-ietf-nvo3-hpvr2nve-cp-req, which is called "Hypervisor to NVE > Control Plane Requirements".) > > E.g., something like: > > The NVO3 WG may produce requirements for a network virtualization > control plane, and will select, extend, and/or develop one or more > control plane protocols to support the architecture. Such protocols > are expected to fulfill the following communication requirements: > - for a "split-NVE", where the NVE functions are split between an end > device and an adjacent switch, > - between an NVE and an 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. >> >> BGP-based solutions to network virtualization within a data center >> environment >> will be developed in the BGP-Enabled Services (BESS) WG. >> >> MILESTONES >> >> Done - Problem Statement submitted for IESG review >> Done - Framework document submitted for IESG review >> TBD - Architecture submitted for IESG review >> TBD - End Device to NVE Control Plane Protocol Adopted by WG > > Better: Control Plane for Split-NVE case Adopted > >> TBD - NVE to NVA Control Plane Protocol Adopted by WG >> TBD - NVE Data Plane Protocol Adopted by WG >> TBD - Data Plane Requirements submitted for IESG review >> TBD - Control Plane Requirements submitted for IESG review >> TBD - OAM Requirements submitted for IESG review >> TBD - Security Requirements submitted for IESG review >> TBD - Use Cases submitted for IESG review >> TBD - End Device to NVE Control Plane Protocol Submitted for IESG review >> TBD - NVA to NVA Control Plane Protocol Submitted for IESG review >> TBD - NVE Data Plane Protocol Submitted for IESG review >> TBD - Recharter or close WG > > Thanks! > > Thomas > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
