Differences

This shows you the differences between two versions of the page.

--- project_proposals:nfvreadyness [2016/02/29 08:33]
Georg Kunz
+++ project_proposals:nfvreadyness [2016/03/15 16:59] (current)
Georg Kunz
@@ Line 1: / Line 1: @@
+====== Note ======
+**Outdated Wiki**
+This project proposal has been renamed to NetReady. Please find the updated wiki here: [[https://wiki.opnfv.org/project_proposals/netready]]
+**Outdated Wiki**
 ==== Project Name: ====
@@ Line 15: / Line 25: @@
 ==== Scope: ====
-The base set of use cases the project focuses on is the following:
+The goal of the NFVReadyNeSs requirements project is to investigate how the current Openstack networking architecture needs to be evolved in order to ensure that NFV-related use cases can be flexibly and efficiently supported. To this end, the proposed requirements project will collect requirements from relevant NFV cases, perform a gap analysis based on the requirements and the current Openstack networking architecture, propose architectural solutions and evaluate them.
-  * L3 VPN
-    * Use cases:
-      * Full mesh networks
-      * BGP/MPLS based Hub & Spoke architecture
-      * ECMP - Load sharing scenario
-      * Extending BGP/MPLS VPNs into the DC in order to enable efficient VNF hosting
-    * Specific requirements:
-      * VM ports that do not require true L2 service but e.g. only L3(-VPN) service (IP-only)
-      * Associate individual VM ports to L3 VPNs irrespective of their assigned IP subnets
-  * SFC
-More use cases may be included as they show up during the evolution of the project.
+=== Example NFV use cases ===
-**Examples for L3VPN use cases:**
+It is a goal of the proposed project to identify relevant NFV use cases and their requirements in the first phase of the project. The following list shows **examples** of potentially relevant use cases. This list is neither complete nor exclusive and will be reviewed and extended in the first phase of the project:
-{{:project_proposals:nfvreadyness-use_case_full_mesh.jpg?400|}}
+  * L3 VPN
-{{:project_proposals:nfvreadyness-use_case_ecmp.jpg?270|}}
+  * SFC
+  * Edge Computing
-The intention to implement these use cases with using OpenStack Neutron highlights a conceptual mismatch regarding the aimed architectural and functional design.
-As a highlight, the list of the limitations of the OpenStack architecture and Neutron includes the following items:
+=== Observations ===
+Initial observations reveal the following list of challenges when attempting to implement NFV-related use cases in the current Openstack networking architecture. A full list of challenges will be the result of a detailed gap analysis based on the requirements of the identified use cases and the current Openstack networking architecture.
   * The design has a base focus on L2 network domains, which is reflected in the API and the datamodels as well:
@@ Line 49: / Line 51: @@
 The NFVReadyNeSs project focuses on addressing the limitations within OpenStack in order to open up an easier and more efficient way of addressing telecom specific use cases and making the platform NFV ready by enabling a more flexible integration of SDN controllers.
+Edge Computing use case for Cloudlet Handoff:
+Cloudlet Handoff across two sites with network connections   either L2 and/or L3 similar to L3 VPN diagram above.
+This is not same as live migration of VM across two Data Centers with applications within those VMs who need to restart from one site to another without context.
+But having Cloudlet as pre-instantiated VM instances from pre-identified low footprint images like say a 4  or 8 GB VM  (base images) at two or more connected hosts/hypervisors/sites(clusters) with cloudlets  (network + application) context data being transmitted as part of Handoff from one instance of cloudlet VM to another with all context being transferred as an delta image or blob.  (the terminology used in Cloudlet is Overlay  for context saving as images and computing disk and memory deltas. The network context saved as part of delta changes when we resume the merged overlay and base images at the new VM and that is where we have options to do through Neutron L2 or L3 and to make this happen we need possibly changes to Nova-Neutron or Nova-Neutron-SDN interactions, very similar to VPN use cases for Network ReadyNeSs. [Refer for Cloudlet for OpenStack: https://en.wikipedia.org/wiki/Cloudlet ]
+=== Phasing ===
 The planned stages of the project are the following:
-  - Provide a document that describes the collection of relevant NFV use cases including the ones listed above with the intention to focus on their requirements
+  - Phase 1: Collection of relevant NFV use cases including the ones listed above with the intention to focus on their requirements.
-  - Further analysis
+    * Planned duration: 3 months
-    - Extend the requirements document (output of stage 1) to contain a gap analysis of the current OpenStack environment (focusing on Neutron and partially Nova)
+  - Phase 2: Extend the requirements document (output of stage 1) to contain a gap analysis of the current OpenStack environment (focusing on Neutron and partially Nova).
-    - Consider possible alternatives by evaluating the outcome of 1 and 2.1
+    * Planned Duration: 4 months. Input to Openstack O release summit.
-  - Alternative solutions
+  - Phase 3: Alternative solutions.
     - Extend the requirements document to list alternative solutions based on the analysis in phase 1 and 2
       - Currently existing protoype is called Gluon, which is a thin API endpoint that fits between Nova and Neutron (or any SDN controller) and serves as a port provider service - https://www.youtube.com/watch?v=mbnLWB5cUeM (Work on the prototype might start in parallel with phase 2)
     - Extend the requirements document to capture the evaluation criteria and testing strategy to evaluate alternatives
-  - Evaluation
+    * Planned duration: 4 months
+  - Phase 4: Evaluation
     - Start evaluating selected alternatives as identified in 3.1 based on the strategy defined in 3.2
     - Document the results of the evaluation process and decide about the preferred solution
+    - Recommend next steps in upstream development and drive upstream solution if needed
+    * Planned duration: 3 months. Input to Openstack P release summit
 The primary scope of the project is not focusing on implementation work, but it includes
@@ Line 71: / Line 86: @@
 The project is intended to focus on the API layer of both the networking service in OpenStack and the SDN controllers in OPNFV's scope evaluating their best way of integration into OpenStack in order to efficiently fulfill NFV needs and the given requirements. Gluon is considered one prototyping activity out of a potential set of alternatives and hence not decided to be the preferred solution/implementation before finishing the evaluation phase.
-Fulfilling the principles of OPNFV:
+===  Fulfilling the principles of OPNFV ===
   * the first stage of the project is intended to focus on discussing and capturing the use cases that we are aiming to find a solution for and clearly articulate and document the problem space
   * after collecting the use cases the project can identify the requirements against the SDN controllers and OpenStack followed by a proper gap analysis
+=== Requirements on potential solutions ===
 The project aims to identify and evaluate the possible solutions that can fulfill the requirements with following statements and criterias:
@@ Line 87: / Line 106: @@
 labs and CI infrastructure.
+=== Repository and Source Code Handling ===
+The outcome of the project, that is the requirements document and the complementary prototyping code, will be hosted in public repositories.
+  * The OPNFV project repository will host documents and supporting material relating to the requirements analysis, such as the description of the use cases under investigation, the gap analysis, the evaluation strategy, etc.
+  * The source code relating to prototyping activities will be hosted in repositories of the respective upstream communities, for instance in GitHub under the Openstack namespace, in accordance with the OPNFV principles of contributing directly to upstream communities.
 ==== Testability: ====
+The prototyping activities are meant to supplement the gap analysis within the project scope. Hence, they are initially not targeted for a release in OPNFV. Once a prototyped solution has technically matured and is accepted in the upstream Openstack community, it will be integrated in OPNFV. At this stage, corresponding integration in the testing projects such as Functest and Yardstick will be done.
 Testing should leverage the integration effort that has been done in OPNFV so far to support different choices of available SDN controllers. The project will need to investigate the possibilities to extend the tested platform with the prototypes under evaluation.
@@ Line 101: / Line 130: @@
 ==== Dependencies: ====
-There is no known OPNFV project or project proposal that covers the activities desccribed for this project.
+There is no known OPNFV project or project proposal that covers the activities described for this project. There are related projects in OPNFV which however do not share a common scope.
+SFC: While service chaining is one of the use cases in the scope of this project, there is no overlap with the existing SFC project in OPNFV. The SFC project aims at integrating the upstream OpenDaylight SFC project to make it available in the OPNFV platform. In contrast, the goal of the proposed NFVReadyNeSs project is to investigate how the Openstack networking API can be evolved in order to support use cases such as service chaining more flexibly.
+SDNVPN: While L3VPN is one of the use cases in the scope of this project, there is no overlap with the existing SDNVPN project in OPNFV. The goal of the SDNVPN project is to ensure the integration of the OpenStack BGPVPN API and the ODL backend driver to make it available in the OPNFV platform. It does not cover a gap analysis to identify how to evolve the Openstack networking API.
+OEC: While VM Handoff for Edge Computing is proposed in Cloudlet under OEC, it is limited due to OpneStack Nova-Neutron interactions and need the ability to enhance the same with flexibility with evolution of SDN and WAN technologies. The VM Handoff for Cloudlet is being considered as a use case for NFVReadyNeSs to addrees the same in OPNFV. You can refer to OEC at http://www.openedgecomputing.org/.
 The project has a dependency on OpenStack, which means it has to follow the release cycle and process with all activities that affect projects which are part of OpenStack Big Tent. In case of creating new OpenStack project(s) the release cycle will be a constarint only after the project is included in Big Tent.
@@ Line 113: / Line 149: @@
     * Georg Kunz (Ericsson), georg.kunz@ericsson.com
     * Ildikó Váncsa (Ericsson), ildiko.vancsa@ericsson.com
+    * Tim Irnich (Ericsson), tim.irnich@ericsson.com
     * Nikolas Hermans (Ericsson), nikolas.hermanns@ericsson.com
     * Bin Hu (AT&T), bh526r@att.com
+    * Ashlee Young (Huawei), ashlee@wildernessvoice.com
+    * Juraj Linkes (jlinkes@cisco.com)
+    * Viliam Luc -X (vluc@cisco.com)
   * Names and affiliations of any other contributors
+    * Prakash Ramchandran (Huawei), prakash.ramchandran@huawei.com
@@ Line 145: / Line 187: @@
 nikolas.hermanns@ericsson.com \\
 bh526r@att.com \\
+ashlee@wildernessvoice.com \\
 ** Link to TSC approval:  ** \\
 ** Link to approval of additional submitters: **  \\

Wiki

User Tools

Site Tools

Differences

Page Tools