Project Name:
- Proposed name for the project:
projectnameReference VNFs - Proposed name for the repository:
reponamedemo
Project description:
- Provide high level description of intended project and intended use case(s) and benefit, if needed.
Scope:
- Describe the functionality to be provided by the project. Please provide the full intended scope of the project; not just what is intended for the project's first release.
- Specify any interface/API specification proposed,
- Identity a list of features and functionality will be developed.
- Identify what is in or out of scope. During the development phase, it helps reduce discussion.The goal of the project is to build reference VNFs that can be used to show how the ONAP platform manages VNFs installation and lifetime management. Reference VNFs can also be used as a means to test the platform itself, e.g. verify whether VNFs on-boarding, deployment, and ONAP closed-loop operations work. Two basic VNFs, namely a virtual firewall and a virtual load balancer (with virtual DNSs), have been provided. The objectives of the project are to improve, extend and maintain the vFirewall and vLoadBalancer VNFs.
Scope:
- List of features and functionalities that will be developed:
- Allow ONAP to change vFirewall rules during execution
- Platform independence (Rackspace, vanilla Openstack, Azure, ...)
- Visualization tools that allow users to monitor the behavior of the reference VNFs as well as the effect of ONAP closed-loop operations against the VNFs
- Tools that allow users to interact with the reference VNFs (e.g. alter the behavior of a VNF so as to violate predefined policies, in order to trigger ONAP closed-loop operations)
- Out of scope:
- Password management
- API securing
- Disaster recovery
- High availability
Architecture Alignment:
- How does this project fit into the rest of the ONAP Architecture?
- Please Include architecture diagram if possibleVNFs are managed by ONAP but they are not part of the ONAP architecture. VNFs expose APIs that are used for management (by ONAP) and measurements/faults reports (to ONAP)
- Please Include architecture diagram if possibleVNFs are managed by ONAP but they are not part of the ONAP architecture. VNFs expose APIs that are used for management (by ONAP) and measurements/faults reports (to ONAP)
- What other ONAP projects does this project depend on?
- Reference VNFs depend on ONAP use cases
- How does this align with external standards/specifications?
- APIs/Interfaces: Reference VNFs export NETCONF and RestCONF APIs that allow ONAP to manage them
- Information/data models: JSON objects are used for bi-directional communication with ONAP. VES is used to report metrics
- Are there dependencies with other open source projects?
- APIs/Interfaces
- Integration Testing
- etc.: vFirewall and vLoadBalancer are based on VPP (FD.io). The NETCONF and RestCONF interfaces depend on the Honeycomb project (FD.io), metrics reporting is based on VES
Resources:
- Primary Contact Person: Marco Platania
- Names, gerrit IDs, and company affiliations of the committers: Marco Platania, platania, AT&T
- Names and affiliations of any other contributors:
- Michael Borokhovich, AT&T
- Bilal Anwer, AT&T
- Chengwei Wang, AT&T
- Project Roles (include RACI chart, if applicable)
Other Information:
- link to seed code (if applicable): http://gerrit.onap.org/r/dcae/demo
- Vendor Neutral
- if the proposal is coming from an existing proprietary codebase, have you ensured that all proprietary trademarks, logos, product names, etc., have been removed?Yes
- Meets Board policy (including IPR)
Use the above information to create a key project facts section on your project page
Key Project Facts
Project Name:
- JIRA project name: demo
- JIRA project prefix: -
Repo name: demo
Lifecycle State:
Primary Contact: Marco Platania
Project Lead: Marco Platania
mailing list tag [Should match Jira Project Prefix] : demo
Committers:
foo@barplatania@research.com
baz@quxatt.com
*Link to TSC approval:
Link to approval of additional submitters: