We need move forward on the framework and live with this statement. Lucy -----Original Message----- From: Thomas Narten [mailto:[email protected]] Sent: Monday, September 08, 2014 5:10 PM To: Lucy yong Cc: Benson Schliesser; [email protected] Subject: Re: [nvo3] Last Call for Comments on Proposed Charter
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-201 > > > 40 > > > 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
