VF-C requirements collection for Casablanca release

ID

catalog

How VF-C is concerned

NF1.1

S3P-security

CII Silver badge(Including no critical and high known vulnerabilities > 60 days old and other requirements),plus

"All communication shall be able to be encrypted and have common rolebased access control and authorization. "( not committed)

CII Badging Program

• CII Silver badge (Jio)
• Vulnerabilities: components owner
• communication encryption and RAC: need to decide
• Example VNFM communication
  • VNFM <---a-→ driver < ----b--→ NSLCM / catalog
  • API (a) is VNFM specific
  • API (b) is planed to be
    • encrypted (HTTPS)
    • authenticated (ex. usename, password)
  • How is this planed to be supported by all VNFM drivers?

 single site horizontal scaling

plan to split all DBs from VF-C existing components into one single DB components

this task can be separated into the following sub tasks:

1) Add CI jobs for DB component

2) Add Dockerfile and docker build scripts for DB component

3) Add oom scripts for DB component

4) Add heat scripts for DB component

5) Remove DB server from nfvo-lcm

6) Remove DB server from nfvo-catalog

7) Remove DB server from gvnfm-vnflcm

8) Remove DB server from gvnfm-vnfres

9) Remove DB server from gvnfm-vnfmgr

ZTE

 All application logging to adhere to ONAP Application Logging Specification v1.2 

ONAP Application Logging Specification v1.2 (Casablanca)

• VF-C/other related dependent modules
• SO

• raisecom
• VF-C components
• VNFM driver
  • Nokia v2 (Nokia) support Logging Specification 1.2 if VF-C NS-LCM will support logging specification 1.2
  • ZTE
  • HUAWEI

All existing APIs must be documented in Swagger 2.0

All new API’s must adhere to the ONAP API Common Versioning Strategy and Documentation Guidelines

https://wiki.onap.org/display/DW/ONAP+API+Common+Versioning+Strategy+%28CVS%29+Proposal

NF2

Architecture Alignment

API improvement

All APIs between internal components & external APIs should be generated by Swagger

F1

Centralized Representation and Consistent ID of Cloud Regions

ONAP need centralized representation and consistent ID of cloud regions to enable multiple cloud/VIM orchestration, and multicloud is the consumer of the ID

F2

HPA

Changes to VF-C will be required in order to incorporate use of HPA into instantiation and related operation.

Intel

ZTE

F3

Scaling

Auto scaling

UC1

vCPE

VF-C integrates with opensource CPE VNFs via GVNFM in C Release

UC2

vVoLTE

VF-C integrates with SVNFM in C Release

Intel

ZTE

SOL003: component owner

Verizon?

ZTE

Align R3 DM

O5

Jira-945 Support multiple VNFM instances

Problem statement: The SVNFM driver can not list all possible VNFM instances using the VF-C NSLCM API, because the API only allows to query VNFM information based on the UUID of the VNFM. The driver must know the UUID of the managed VNFMs to be able to query the VNFM information from VF-C LCM API. Even if the UUID of the VNFM is passed during a LCM operation (ex. scale) from VF-C to SVNFM driver. The possible VNFM instances must be know by the driver even if there is no API call executed from VF-C to driver, since the VNFM driver may want to subscribe to ETSI LCN as part of the driver startup.

Use case: Manage multiple VNFM instances from a single ONAP instance.

Proposed solution: Add a new API to VF-C LCM that allows to query the list of the VNFM instances.

O6

Jira-946  Separate configuration parameters of runtime from design time

Problem statement: The VNF package (CSAR file) currently holds a section that contains runtime information (concrete image names, availability zones, IPs, ...). This section should be  only specified at the point when the VNF / NS / E2E service is created via use-case UI / VID. The current VNF package hold environment specific values resulting in that it can only be deployed in one specific environment. Currently VF-C NSLCM API allows to specify additional data for a VNF and NS, but this section is never filled out by SO/usecase UI.

Use case: The single VNF package can be deployed into different cloud environment (ex. difference availability zone) without modification.

Proposed solution: Extend the use case UI to be able to specify key value pairs for each VNF and NS. The VNF / NS operator could specify the value for these as part of the NS creation. These values would be passed from use case UI to SO and then to VF-C NSLCM API.

Modeling subcommittee /SDC/SO/UUI/VF-C

Victor:

it would be more consistent that we start this topic(runtime model) from modeling part,

so that we could have the clear operation definition across the community

O7

Jira-947 Support custom operation

Problem statement: Operations that is not covered by the current ETSI specifications / VF-C LCM implementation can not be triggered from the use case UI / VF-C LCM API.

Use case: Trigger a VNF upgrade operation from the use case UI.

Proposed solution:

• Extend the VF-C API to support the execution of custom operation
• Extend SO workflows to be able to trigger custom operation
• Extend usecase UI / VID to trigger the execution of custom operations

UUI/SO/VF-C/Modeling Subcommittee

Victor:

It would be more consistent that we start this topic(Operation definition) from modeling part,

so that we could have the clear operation definition across the community

Jira-948  Multi tenancy support

Problem description: The cloud connection in A&AI is located under /cloud-infrastructure/cloud-regions/cloud-region/{cloud-owner}/{cloud-region-id}. This may hold multiple esr-system-info elements. Each esr-system-info collection of many attributes including URL, username, password and default-tenant. To establish a connection with OpenStack the URL, username, password and default-tenant fields are required. VF-C NSLCM identifies a cloud by a vimId field which is a composition of {cloud-owner}/_{cloud-region-id}. This two fields does not select the cloud credentials, since an cloud region may have multiple esr-system-info entries.

Use case: Deploy two VNF on different tenants on the same cloud.

Proposed solution: Change the vimId on VF-C API to be constructed from the {cloud-owner}/{cloud-region-id}{tenantId} tuple making the cloud credential selection unique.

Need to discuss with bin Yang:

Bin Yang:

Taking openstack as an example, because cloud-region-id is aligned with the cloud-region-id of OpenStack. The default value is RegionOne in openstack.

Supporting multiple tenants can be achieved by manually specifying different cloudowner in ESR GUI. 

Jira-949  Support VNFMs with multiple end points

Problem description: A VNFM in ETSI have different endpoints (IP address) for different purpose. A couple of examples for endpoints are: authentication, LCM or LCN. The VNFM in A&AI is located under /external-system/esr-vnfm-list/esr-vnfm/

{vnfm-id}

. The VNFM in A&AI may have multiple esr-system-info entries. Each entry may have many attributes (username, password, URL). VF-C only exposes the first element from the esr-system-info list.

Use case: Register a VNFM with multiple API end points.

Proposed solution: Change the ESR UI to be able to register multiple end points. Change the VNFM query API of VF-C LCM to return the full collection of end points instead of the first element.

• Interface modification will affect other vendors‘ driver implementation, wait for ZTE/Huawei feedback.
  • Victor: My concern is that how can we keep backward compatible if VNFM doesn't multiple endpoint.
    • If the VNFM has multiple end points it will receive a list consisting of a single entry
  • Victor: Can you point out where ETSI define VNFM need have different endpoints?
    • Nokia: Authentication endpoint, LCN, LCM
• Need to discuss further with the ESR team.