Hi Sharon, I really have not idea what the term "logically distinguished" means. It seem to suggest that the NVA can be distinguished (recognized as different) from something else by using logic, but I assume that isn't what you meant. I'm not in favor of this term.
- Larry On 9/8/14 8:00 PM, "Sharon Barkai" <[email protected]> wrote: >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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
