Wiki

• Proposed name for the project: NetReady (NetworkReadiness)
• Proposed name for the repository: netready

OPNFV provides an infrastructure with different SDN controller options to realize NFV functionality on the platform it builds. As OPNFV uses OpenStack as VIM, we need to analyze the capabilities this component offers us. The networking functionality is provided by a single component called Neutron, which hides the controller under it, let it be Neutron itself or any supported SDN controller. As NFV wasn't taken into consideration at the time when Neutron was designed we are already facing several bottlenecks and architectural shortcomings while implementing our use cases.

The NetReady project aims at evolving OpenStack networking step-by-step to find the most efficient way to fulfill the requirements of the identified NFV use cases, taking into account the NFV mindset and the capabilities of SDN controllers.

The goal of the NetReady 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 i) identify a relevant set of NFV use case and collect requirements from them, ii) perform a gap analysis based on the requirements and the current Openstack networking architecture, iii) propose architectural solutions iv) and evaluate them.

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:

• L3 VPN
• SFC
• Edge Computing

The collection and discussion of use cases has already started as part of initial project work and can be found here: https://etherpad.opnfv.org/p/netready_use_case_collection

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 data models as well:
  • Due to the restriction of the API the implementation of the above mentioned use cases often requires to violate or at least work around the current API terms
  • The current Neutron API defines the limitations for the SDN controllers below by serving as a de-facto standard API layer on top
• OpenStack itself defines strict rules to perform API changes, which makes it difficult to introduce new concepts
• Introducing complex new functionality in Neutron is time consuming
• Neutron and Nova (OpenStack Compute) are strongly coupled
  • New feature proposals and design have to address the impacts on two large and complex modules that often results in a long delay to introduce the feature
  • Limited choices in design and architecture

The NetReady 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.

The planned stages of the project are the following:

1. Phase: Collection of relevant NFV use cases including the ones listed above with the intention to focus on their requirements.
   • Planned duration: 3 months
2. Phase: Extend the requirements document (output of stage 1) to contain a gap analysis of the current OpenStack environment (focusing on Neutron and partially Nova).
   • Planned Duration: 4 months. Input to Openstack O release summit.
3. Phase: Solution design
   1. Extend the requirements document to list potential solutions based on the analysis in phase 1 and 2
      1. Currently existing prototype 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)
   2. Extend the requirements document to capture the evaluation criteria and testing strategy to evaluate alternatives
   • Planned duration: 4 months
4. Phase: Evaluation
   1. Start evaluating the proposed solutions as identified in 3.1 based on the strategy defined in 3.2
   2. Document the results of the evaluation process and decide about the preferred solution
   3. 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 prototyping activity as well. The scope of the implementation work within the project is limited to provide the support for and fulfill the requirements defined by the identified NFV use cases.

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.

• 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

The project aims to identify and evaluate the possible solutions that can fulfill the requirements with following statements and criteria:

• The proposed solutions in consideration have to fit into OpenStack conceptually
  • it has to support/provide the legacy networking functionality in OpenStack
  • it has to support the NFV use cases and concept within OpenStack
• The chosen solution has to be moved and get accepted by and integrated into OpenStack in order to consider it as a final successful solution
• Gluon is just one of the candidates in consideration

The project does not have a proposed architecture at this point. The provided outcome has to fulfill the requirements specified above. It is also important to state that the project does not have a necessary interest in creating a new component in OpenStack. The final architecture of the solution has to be chosen by the results of the evaluation process.

For evaluating the alternatives in consideration the project is intended to use the OPNFV labs and CI infrastructure.

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.

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.

The project can consider an integration point with the OPNFV SFC project to run existing functional tests to evaluate the prototypes/validate the solution. As the project focuses on finding an efficient way to integrate SDN controllers into OpenStack the created functional tests shall validate this aim.

The project will produce a document that captures the use cases, requirements and work to fulfill our needs. The final solution should be integrated into OpenStack, which means that the related documentations should be added to OpenStack and referenced from OPNFV documentations.

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 NetReady 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 OpenStack 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 NetReady to address 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 constraint only after the project is included in Big Tent.

The networking APIs should follow the existing standardization guidelines if any.

• Names and affiliations of the committers
  • 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 (Cisco), jlinkes@cisco.com
  • Viliam Luc -X (Cisco), vluc@cisco.com
  • Ahmed Elbornou (Cisco), amaged@cisco.com

• Names and affiliations of any other contributors
  • Prakash Ramchandran (Huawei), prakash.ramchandran@huawei.com

The project will produce documentation to identify requirements and architecture during the C-release. The earliest OpenStack release to add our solution to is Newton, which means the D-release of OPNFV.

The project will follow the OPNFV and OpenStack release schedules.

Project Name: NetReady (NetworkReadiness)
Repo name: netready
Lifecycle State: proposal
Primary Contact: georg.kunz@ericsson.com
Project Lead: TBD
Jira Project Name: netready
Jira Project Prefix: [netready]
mailing list tag [netready]
Committers:
georg.kunz@ericsson.com
ildiko.vancsa@ericsson.com
nikolas.hermanns@ericsson.com
bh526r@att.com
ashlee@wildernessvoice.com
jlinkes@cisco.com
vluc@cisco.com

Link to TSC approval:
Link to approval of additional submitters: