If Server has an interface to underlay network, I am not sure if we can call the server as the edge of underlay network.
NVE is the edge of a virtual network. Lucy -----Original Message----- From: Thomas Narten [mailto:[email protected]] Sent: Monday, September 08, 2014 4:15 PM To: Lucy yong Cc: Benson Schliesser; [email protected] Subject: Re: [nvo3] Last Call for Comments on Proposed Charter Hi Lucy. At Mon, 8 Sep 2014 20:55:44 +0000, Lucy yong wrote: > > Thomas, > > Some Comments: > > "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" > > Comment: If NVE resides on a Server that is a host in an underlay > network, IMO: this is not the case that NVE sits at the edge of > underlay network. Why do you say that? In the case of the server, it has an interface on the underlay network, and is thus at the edge of the network. Even then, I don't think we need to get too precise in what we mean by "edge", i.e., whether it is at the very edge, or one hop in (as the case might be for split-NVE). To me, by definition, the NVE is always at the edge, because it has one interface on the underlay, and one "interface" towards the End System it is providing the virtual network service to. > Should we state that an NVE that either resides at the edge of an > underlay network or co-locate with Tenant Systems on an end device, or > both and provides ... I think this wording is making things more complicated than is needed for the charter. BTW, the "edge" wording you are questioning comes directly from the framework document! Thomas > > Regards, Lucy -----Original Message----- From: nvo3 > [mailto:[email protected]] On Behalf Of Thomas Narten Sent: > Monday, September 08, 2014 2:07 PM To: Benson Schliesser Cc: > [email protected] Subject: Re: [nvo3] Last Call for Comments on Proposed > Charter > > 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-20140 > > 90 > > 1.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
