Sorry, I'm not following what your concern is. Here is the definition of NVE from the framework document:
Network Virtualization Edge (NVE). An NVE is the network entity that sits at the edge of an underlay network and implements L2 and/or L3 network virtualization functions. The network-facing side of the NVE uses the underlying L3 network to tunnel tenant frames to and from other NVEs. The tenant-facing side of the NVE sends and receives Ethernet frames to and from individual Tenant Systems. An NVE could be implemented as part of a virtual switch within a hypervisor, a physical switch or router, a Network Service Appliance, or be split across multiple devices. Are you disagreeing with that? Thomas At Mon, 8 Sep 2014 21:41:22 +0000, Lucy yong wrote: > > 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
