SO,OOF,  SDNC,UUI, integration

Stretch goal:

SDC, DCAE, external API.

NOTE: No project should be code impacted by this use case.

All; Test

Code:

SO,OOF,  SDNC,UUI

Stretch goal:

SDC, DCAE, external API, CCSDK

SO:committed,

OOF:committed (Huawei resources as required).

UUI:committed

Integration: committed

SDNC: (Huawei resources as required).

Stretch goal:

DCAE :  Not committed(Huawei &CMCC plan to contribute)

SDC: Not committed

External API:(VDF & huawei plan to contribute)

CCSDK: (Huawei resources as required).

if projects not committed is just in strech goal, then we will dev based on exist features, may impact some usibiligy, but won't impact the final result.

DCAE : From discussion with Xin Miao (Huawei), this usecase requires new RESTCONF collector to be added into DCAE.This cannot be committed for R3 due to pending requirement clarification and architectural alignment besides resourcing constraint.

Contingent that Use Case owner are able to add resources on impacted projects and Integration agreement

SO, Portal, External API, APPC, DCAE

HPA

**NOTE: OSAM uses the PNF capability similar to 5G use case. No new development efforts were identified to support OSAM using PNF

VNFRQTS (include PNFs)

VNFSDK (minor)
SDC (minor)
Policy
OOF (minor)
SO (minor)
AAI,
Multi-Cloud
VNFRQTS

Orange: 2

ATT: 2

China Telecom: 2

China Mobile: 1

Verizon: 2

Vodafone: 2

VNFSDK: none

SDC: VNFSDK, VNFD model

Policy: SDC

OOF: SO, Policy, AAI

AAI: Multi-CLoud

VNFSDK (C)
SDC (TO/C)
Policy (C)
OOF (C)
SO (C/TO)
AAI (C)
Multi-Cloud (C)

Policy: Committed based on Intel providing resources

OOF: Committed

VNFSDK: Committed

SDC: committed based on Intel contribution.

SO: committed

AAI: committed based on Intel resources.

Multi-Cloud: committed

Intel
China Mobile
AT&T
VMware
ARM

SDC, SO, VID

Orange: 1

ATT: 1

China Telecom: 2

China Mobile: 2

Verizon: 1

Vodafone: 2

VID: on SO

SDC: on SO

SDC:XL

VID: M

VID: Not committed (Note: VID part is "nice to have" - no dependency on VID from other projects)

SDC: committed based on Amdocs contribution

SO : Committed (with support from ATT resources)

VID: requires additional resources

AT&T, Amdocs

Orange: 1

ATT: 1

China Telecom: 2

China Mobile: 2

Verizon: 1

SDN-C: committed

APPC: Not committed

Orange: Committed

Orange: 1

ATT: 1

China Telecom: 2

China Mobile: 2

Verizon: 1

OOF, VID

VID - Nice to have - the functionality can still be delivered with OOF only (scheduler would need to be invoked through CLI)

Orange: 1

ATT: 1

China Telecom: 2

China Mobile: 2

Verizon: 1

OOF: Committed

VID: Not committed

(this can still be delivered with OOF)

VID: requires additional resources

Scaling

Closed Loop Scaling

(High Priority)

Policy, CLAMP, SO, DCAE

Orange: 1

ATT: 1

China Telecom: 1

China Mobile: 1

Verizon: 3

Vodafone: 1

CLAMP: on Policy

Policy: on SO

CLAMP: M

Code: SO, CLAMP, Policy

Test: DCAE

CLAMP: Committed with risks (dependency on Policy)

Policy: Committed with risks (TBD)

SO: Committed

DCAE: Committed

Scaling

Beijing Improvements

(High Priority)

 VID: on SO

APPC: on SO

VID: XS

AAI: XS

AAI: Committed

APPC: Committed

SDNC: Committed

SO: Committed

VID: Committed

Scaling

Controller_Topic_ID

(Medium Priority)

SO: Committed

Scaling

Homing and Capacity Check

(Low Priority)

5G/PNF

Plug and Play

SDC, SO, SDN-C, A&AI, CDT, Modeling, VID, DCAE, DMaaP

Orange: 2

ATT: 1

China Telecom: 3

China Mobile: 1

Verizon: 1

Vodafone: 2

VID: on SO

VID: S

AAI: XS? need clarification on what's expected

OOF: No impact

Code: VID

Test Only: SDC

Code : DCAE

VID: Committed based on Nokia's contribution

SDNC: committed

SO: Committed (with resources from Nokia)

SDC: support based on current sdc capabilities from Beijing.

APPC: No impact

AAI: No code change, only modeling changes

OOF: No impact

DCAE: committed

DMaaP: committed

APPC: Per review of slides, does not appear to be anything specific for APPC in Casablanca. Items mentioned are more longer term, roadmap items

AAI: Expecting this to be modelling/schema updates only but unclear. Need additional information and analysis by AAI SMEs

OOF: Additional information required on policies required for PNF placement

DCAE: Committed based on Nokia's contribution on PRH

5G/PNF

Software Version Reporting

CCSDK: committed

SDN-C: committed

5G/PNF

Lifecycle Management Support

(Restart, Suspend of PNF)

OOF: Committed

SDN-C: Committed

5G/performance Analysis and Optimization

High Volume and RT Data Collection of PM

Orange: 2

ATT: 2

China Telecom: 1

China Mobile: 3

Verizon: 3

Vodafone: 3

OOF: M

DCAE: L

code change: OOF

Code : DCAE

CCSDK: committed

SDN-C: committed

OOF: No Impact

DCAE: Committed (based on Nokia contribution) with dependency risk

OOF: Limited resources

DCAE: Edge deployment support for R3, DDS-VES and new analytic platform (flink) not committed due to resource constraint

5G/performance Analysis and Optimization

Bulk PM

code change: DMaaP

Code change: DCAE

DCAE:  DataFileCollector- Committed (based on Ericsson Contribution) with dependency risk

PMMapper - Partial Commit (Based on Ericsson contribution) + dependency risk – Not a hard requirement

DCAE: Dependency on DMAAP-DR + PMMapper (Stretch goal)

5G/performance Analysis and Optimization

Optimization Framework Enhancements (Placement, Formulation, Solving)

 OOF

Orange: 3

ATT: 3

China Telecom: 1

China Mobile: 2

Verizon: 2

Vodafone: 3

Centralized Representation and Consistent ID of Cloud Regions,

Plan B, Phase 1: Centralized Representation of Cloud Regions

SO, Integration

Orange: 1

ATT: 2

China Telecom: 2

China Mobile: 3

Verizon: 1

Vodafone: 1

SO, Integration

  SO: committed based on Intel's contribution

  Integration: committed

To align MVP, propose alternative action plan B: break this requirement into 3 phases.

Phase 1 is to centralize the representation of cloud regions;

Phase 2 is to apply consistent ID across all related ONAP projects.

Phase 3 is to correlate and align dcaeLocation to AAI's cloud region. This phase requires further discussion, hence not listed here.

Note on "Intel's contribution": This is the synergy effort with HPA, no further special changes needed here. hence this can be deemed as a dependency on HPA's impact on SO.

SO: will be ready to test soon.

Integration: Not started yet.

Centralized Representation and Consistent ID of Cloud Regions,

Plan B, Phase 2: Consistent ID of Cloud Regions

Orange: 1

ATT: 2

China Telecom: 2

China Mobile: 3

Verizon: 1

Vodafone: 1

VID/SDNC: on SO

SO/OOF/VFC: MultiCloud

VID: XS

MultiCloud: S

VFC:S

SO,VID,SDNC,OOF,VFC,

UUI,MultiCloud

 SO: not committed

 VID: Not Committed

 SDNC: Not committed

  OOF: Committed

  MultiCloud:Committed 

  VF-C :Committed

  UUI: committed

SDNC: Limited resources

VID: requires additional resources

MultiCloud: Ready to test

VFC: not started yet

UUI: not started yet

Edge Scoping MVP for Casablanca - ONAP Enhancements

1. Cloud-agnostic Placement/Networking & Homing Policies (Phase 1 - Casablanca MVP, Phase 2 - Stretch Goal)

Orange: 3

ATT: 3

China Telecom: 3

China Mobile: 3

Verizon: 2

Vodafone: 1

OOF: on MultiCloud & SO

Multi-Cloud: on A&AI

SO: XS

AAI: XS

OOF: M

Multi-Cloud: M-L

Code: OOF, Multi-Cloud, A&AI, SO

Test: Integration (vFW use case)

Casablanca MVP:

• OOF: Committed
• Multi-Cloud: Committed
• A&AI: Committed
• SO: Committed

M4 on target in relevant projects

Integration Test Plan in Progress: HPA & Cloud Agnostic Intent - R3 Test Plan (In Progress)

Edge Scoping MVP for Casablanca - ONAP Enhancements

2. Edge Scoping MVP for Casablanca - ONAP Enhancements#ONAPEnhancements-AggregatedInfrastructureTelemetryStreams(AlignswithHPArequirements,CombiningeffortswithHPA)

Orange: 3

ATT: 3

China Telecom: 3

China Mobile: 3

Verizon: 2

Vodafone: 1

Casablanca MVP:

• Multi-Cloud: Committed

M4 on target in relevant projects

Start Small MVP "Node metrics and HPA metrics from Grafana dash board"

No plan for integration testing.

• Performance
• Stability
• Resiliency
• Security (see below)
• Scalability
• Manageability
• Usability

Likely ALL depending upon TSC determination of new level requirements per category

Materials

Usability:  New API’s adhere to Versioning strategy

Versioning & API Documentation Recommendations

Manageability: Adherence to ONAP Logging Spec v1.2

Portal: on AAF, MUSIC, OOM

VID, Policy, SDC, AAI: on Portal

Portal: Not Committed

APPC: Partial

DCAE: Partial

SDC: committed

VID: Partial (depends on Portal)

AAI: Partial

Portal: See Risk #2

APPC: Please refer to M1 Planning template for details

DCAE: Refer to DCAE R3 M1 Release Planning#PlatformMaturity for details

AAI: Please refer to AAI R3 Platform Maturity

Portal:

1) Looking for resources who can help with adhering logging standards, API versioning and kubernetes deployment of Portal dockers.

2) Furthermore, Portal requires a security expert in addressing angular upgrade to address the Nexus-IQ reported vulnerability (the angular upgrade its self is XL t-shirt size task).

Note: This does not cover what is in S3P. However, based on that it is expected to have a certificate or use CADI to get certificates to enable secure communication

Pluggable authentication and Authorization (Use of CADI and ?):

• JAVA projects to use CADI client and enforcement point
• Non-JAVA projects:Wait until there is multi-language.
• All projects either need to have certificates (for secure communication) (based on a common trust store of AAF).  The certificate distribution can be part of deployment mechanism and will be further detailed.

Secure communication toxNFs(Security for 5G Use cases). DCAE, APPC, VFC? VNF requirements. (Secure Communication to Network Functions)
- TLS and/or SSH for netconf (APP-C, SDN-C, CCSDK)
- HTTPS security for VES (DCAE) (with certificates, slowly deprecating username/pasword)

• Description of how the xNFs will get their certificates (VNFreqs). 

Vnf package security following SOL 004: SDC, VNFreqs, VNF SDC

Materials

CADI/AAF Integration:

• AAF Documentation
• Client access to AAF

Portal: on AAF

Test coverage (js):

(1) js Sonar plug-ins activation

(2) min. 3 additional containers per application

=> Jenkins enhancements

(3) Maven build to be updated

Risk #1

DMaaP on AAF

DCAE on AAF, OOM,DMAAP

OOF on AAF

Portal (CADI): M

DCAE: XL

SDC: L

Test coverage (js):

All: M/L

Portal: Code

SDC: code

VID: Code

Portal: Not Committed

APPC: Partial

OOF: Partial

DCAE: Not Committed

SDC: Partial

VID: Partial (depends on Portal)

AAI: Partial

Portal: See Risk #3

APPC: Please refer to M1 Planning template for details

DCAE: Refer to DCAE R3 M1 Release Planning#PlatformMaturity table for open issues/question with current proposal

OOF: Please see OOF Casablanca M1 Release Planning Template

SDC: because of the size of the sdc source code we will be able to reach only 10% unit test coverage on the Javascript. VNF package security missing information.

AAI: Please refer to AAI R3 Platform Maturity

Portal: Looking for resources who understand the AAF based certificate management to upgrade using CADI client in Portal.

OOF: Need more clarity on AAF support for python projects in Casablanca

APPC: Not Committed

CLAMP: Not Committed

DCAE: Not Committed

SDC: not commited

VID: Not Committed

AAI: Not committed

APPC, CLAMP, Portal, SDC, DCAE, VID, AAI: Lack of resources require additional information (does it include rollback, retrofit, no impact on run-time, etc)?

Architecture Alignment

• API improvement
• Realtimestreaming
• K8S Support (for VNFs)

DCAE on DMAAP (for DR)

DCAE:Partial Commit (New service committed based on Ericsson/Nokia)

SDC: partial

MultiVIM: Committed

External API: Committed

SO: Partially committed

A&AI: partially committed

CCSDK: committed

DCAE:  DDS-VES and new analytic platform (FLINK) not committed due to resource. xNF-DCAE authentication not committed due to open issue listed under security.

SDC: policy designer not planned for Casablanca, ETSI compliance only sol004 is planed. PNF suport will be done ontop of the existing capabilities. RTC stretch goal. DCAE-DS committed. Flow designer committed.

ExtAPI: Interlude is a stretch goal

SO: "decomposition" committed; "service instantiation" stretch goal

A&AI: abstract topology sync-up committed

HEAT-based ONAP deployment support should be dropped once OOM-based ONAP deployment's issues are fully identified and resolved.

Recommendation from TSC: keep supporting HEAT in Casablanca for testing and integration purposes. However, HEAT won't be a gating item at Release Sign-Off.

Portal: S

SDC:S

Portal: Code

SDC: code

Portal: Not Committed

APPC: Will support Heat partially

OOF: Support HEAT for testing

SDC:committed

VID: Partially

• User Experience

Portal: Partial

APPC: Not Committed

CLAMP: Not Committed

SDC: Not committed

VID: Not committed

• Unit tests
• CSIT tests

Most UI projects with javascript.

Recommendation from TSC: This is related to Code Coverage: recommendation is to keep 50% Code Coverage for Casablanca including JavaScript. (In Beijing Release code coverage was only covering Java and Python code, not javascript)

Linux Foundation Unit test and CSIT coverage framework,

Policy, VID, SDC, AAI: on Portal, DCAE (for JavaScript coverage)

Portal: XL

SDC:S

VID:S

Code: portal, SDC, VID

Portal: Partial (no Javascript)

APPC: Partial, Java code will maintain 50%, no commitment for Javascript

CLAMP: Partial, Java code will maintain 50%, no commitment for Javascript

DCAE:Partial (except javascript)

SDC: maintain 50% coverage for java and python

add 10% coverage for UI(java script)

VID: maintain 50% coverage for java

add 10% coverage for UI (java script)

AAI: Partial, Java code will maintain 50%, add 10% coverage for sparky (javascript)

Portal, APPC, CLAMP, DCAE: See Risk #1

 SDC: needs to support composite pattern in R3

SDC/SO/A&AI needs to support Service Order, Service Catalogue, service scaling

Modeling runtime needs to be supported by A&AI in release 3

SDC:not committed

SO

A&AI - changes to the run-time schema require significant refactoring in all of AAI's client applications. That refactoring might be planned and addressed in R4; for R3, perhaps mapping existing runtime schema to new model definitions can suffice?