Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This is summary of outcome of Use case Sub-Committee and effort from:

  1. HPA (main contact Alex Vul)
  2. Change Management (Main contact Ajay Mahimkar)
  3. Scaling  (main contact Scott Blandford)
  4. 5G/PNF support (main contact Vimal Begwani)
Tip
titleLegend

Yes: Committed by PTLs to Beijing Release

No: Not committed to Beijing Release

NA: Project not impacted by functional requirement, requirement not defined enough to make formal decision.



Project NameFunctional RequirementsComments

HPAChangeMngtScaling AutoScaling ManualPNFNetwork SlicingData CollectionPath Selection

M1 CommitmentM4 resultM1 CommitmentM4 resultM1 CommitmentM4 resultM1 Commitment

M4 result

M1 CommitmentM4 result



A&AI

Yes

YesYesYesYesYesYesYesYesYesNANANA

Change Mngt, Scaling: Functionality already exist in Amsterdam. New way to exercice the API. No schema change required.


Application Authorization FrameworkN/AN/AN/AYes, AAF is now ONAP OnlyN/AYesN/AYesN/AN/AN/AN/AN/AAAF was not managed in ONAP for Beijing. Instead, we used this time to take the major features desired from AT&T production, including Certman, OAuth2 and other elements. AAF project is now ONAP First. This means that starting with Casablanca, requirements and results now come from the community, will have M1 Commitments, etc.
APPCNANAYesYesNoNoYes

Yes


NANANANANA

Change Mngt: not impacted for Beijing because Use case being focuses on an L3 VNF. APPC is impacted for this change management functional requirement for L4 to L7 VNFs. APPC will support In Place software upgrade in Beijing.

Scaling Auto: Lack of detailed requirements and resources.

CLAMPNANANANANoNoNANANANANANANAScaling: Dependency on Policy who has no resource to deliver in Beijing
Common Controller SDKNANAYesYesYesYesYesYesNA
NANANAChange Mngt: Ansible server support
DCAENANANANANANANANA

Event for PNF discovery to be added (validate whether prov only or need dev). If dev needed and not committed then can deliver the solution without DCAE for Beijing

WIP as of 03/28

(the PNF Registration Handler, aka prh, work is in the process of being contributed.

Code coverage 63%, but currently encountering problems in CLM scan reporting "CLM server error", LF helpdesk ticket #54190)

NANANA

HPA: Not priority

DMaaPNANANANANANANA
YesYes
NANANANANANANA
DocumentationNA
NA
NA
NA






External API FrameworkNANANANANANANANANANANANANAInitial code release
HolmesNANANANANANANANANANANANANA

Integration

Yes
Yes
NA
NA
Yes




Logging Enhancements Project NA
NA
NA
NA


NANANA

Scaling is possible via standard k8s config - but not yet tested for elasticsearch and logstash containers

Network slicing has not been prototyped (independent of any k8s component - not specific to the elk stack)

Data collection is possible via PVs exposed on /dockerdata-nfs share - via standard k8s volumes - but not tested

Patch selection is not applicable - but needs to be verified

Microservices BusNA
NA
NA
NA
NA
NANANA

No modification is needed in MSB project specifically to support all these functionalities so far. If you think there are any new requirements needed, please let us know.

ModelingYes
NA
NA
NA
NA
NANANAmodeling project is responsible for a tool: Parser, modeling committee is responsible for modeling spec, HPA will be related parser.
Multi VIM/CloudYesYesNA
NA
NA
NA
NANANA
MUSICNANANANANANANANANANANANANA
ONAP CLINA
NA

YesNote1YesNote1NA

YES

Note2

NANANA

Mostly HPA will be captured as part of Templates (TOSCA/HEAT). so CLI won't get oppourtunity to operate on HPA. But if Services provides API to handle the HPA, those can be incorporated. So after M2/M3, things will be very clear. so CLI marked HPA as NA.

Note1: SO does not expose the REST API for scaling yet. so CLI is not in postiion to support this feature.

Note2: PNF support was not initially planned during M1, but as part of M3, it got identified to support and is enabled now.

ONAP Operations ManagerNA
NA
NA
NA






ONAP Optimization FrameworkYesYesYes

N/A

Note 1

Yes

No

Note 2

Yes

No

Note 2

NA
NANANA
  • Note1: OOF was not required in R2 flows. Use Case proposal: ONAP Change Management 
  • Note 2: OOF dependencies had this as stretch goal. Communicated the same with use case owners, and the plan is to support in R3.


ONAP Usecase UI Project ProposalNA
NA
N/A
Yes






Policy Framework Project ProposalYesYesNA
No
NA
NA
NANANAScaling: Resources found for vDNS, but APPC is unable to commit fully. Policy will do as much as possible in conjunction with APPC's ability.
Portal Platform Project ProposalNANANANANANANANANANANANANA
SDN-CNANAYesYesYesYesYesYesYesYesNANANAChange Mngt: In-place software upgrade execution using Ansible
Service Design & CreationYes (based on INTEL contribution)WIPNA
NA
YesYESYes (based on NOKIA contribution)YESNoNoNo


Scaling Manual: no resource

Service OrchestratorYes

Yes

Defects Fixing

Yes

Yes


Yes

NA

Dropped of the scope

YesWIPYes

Yes (VCPE), needs to be stabilised.

Volte - WIP

NANANA

Change Mngt: Change workflow design and execution for in-place software upgrade

Note: The current commitment is based on the discussions and promises of availablity of coding resources for the respective function implementation.

VFCYesWIPNANA

Yes

(but the auto scaling process is not very clear now)

YesYesYesNANANANANA

scaling Auto: VF-C will provide the scaling API, but the auto-scaling process is not very clear now.

For other requirements did not reach out to VF-C


VIDNA
YesYesNA
YesWIPYesYesNANANA

Change Mngt: User interface for invoking software upgrade workflow

Scaling Manual: no resource

VNF SDKYesNoNA
NA
NA
NA
NANANAM4: Model not published.
VNF RequirementsYes
Yes
Yes
Yes
Yes
Still investigatingStill investigatingNA

Auto scaling and Manual Scaling covered by scaling use case component planned for Beijing.

Scope of PNF work dependent on definition of PNF, VNFRQTS-160

VNF Validation (VVP)NA
NA
NA
NA