Hi Larry, Trying to capture the point about separating the NVA, a pervasive service centralized, clustered, or federated, from the meshed-aggregation topology constrains of the NVEs.
Such separation is not mandatory in traditional routing, but is mandatory to scale NVOs. The NVE-NVO interface defined by this separation should be key target for standardization. However, like most folks on the WG also all for moving forward. Once we separate what's NVE-NVE (examp L2/3 encap, echos, measurements..) and what's NVE-NVA (RLOC/VTEP, Mcast, affinity..) the right language will hopefully emerge. --szb > On Sep 10, 2014, at 6:40 PM, "Larry Kreeger (kreeger)" <[email protected]> > wrote: > > 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
