You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 110 Next »

  1.  – is the last day for Service Providers to include their requirements into this page
  2.   – is the last day for providing use case/functional requirements as a candidates for Dublin
  3.    - is the last day for getting all of the requirements (architecture, security, projects, S3P etc.) and getting a single consolidated list so all of the projects have full picture of what is required from them. By this date, all use cases/functional requirements need to be discussed with a different projects, and demanded scope of development should be clear to the projects
  4. Vf2f in December – making a decision of what is indeed included in Dublin, based on Service providers priorities and projects’ commitments


REQDublin Requirement, along with link for details or descriptionService Provider Requesting (incl. SP name and requirement priority e.g. p1, p2, p3)How to test (existing or new use case)Owner (person)Owner (project(s), S3P, functional requirement/use case)
1

K8S based Cloud-region support

  • vFW as use case (with firewall as container, sink and generators as VMs)
  • EdgeXFoundry use case

Verizon:  P1

Vodafone - P3

vFW use case (existing but with Helm charts)

EdgeXFoundry use case (new use case)


Victor Morales

Victor Morales

Impacted projects: Multi-Cloud, SDC, SO, VNFSDK(?)

2Continue SOL 003 Alignment work in VF-C - Aligned with VF-C PTL. Content will be finalized as part of Dublin planning

Verizon

Deutsche Telekom - P3

China Mobile - P2

Vodafone - P1




3Start SOL 005 Alignment work ( with basic interfaces ) between SO & VF-C - Had handshake with SO and VF-C PTLs. Content will be finalized as part of Dublin planning

Verizon

Deutsche Telekom - P3

China Mobile - P2

Vodafone - P2




4Implementation of “ONAP managing 5G as transport for CCVPN”  usecase

Verizon

Deutsche Telekom - P2

Vodafone - P1




5Change Management extension including 5G requirements

Orange - P1

AT&T - P1

Vodafone - P2



cf Change Management extension
6True orchestration. We still need too many manual tasks to deploy a service (preload, various requests to deploy a service...)

Orange - P1

Verizon - P1

Deutsche Telekom - P1

Swisscom - P1

Bell Canada - P0

Vodafone - P1



SO, SDNC, CDS

7

Service modeling extension.

Need to define service parameter and their link with VNF or network parameter.

Need to define parameters that can be modified by end-user

Orange - P2

Vodafone - P2



SDC, SO, AAI
8Tooling to operate ONAP: provide set of tools to configure ONAP via GUI (eg users, roles...), to restore the set of database...

Orange - P2

Verizon - P1

Deutsche Telekom - P3

Vodafone - P3



OOM ?
9Provide accurate documentation for operational teams, for newcomers

Orange - P0

Verizon - P0

Deutsche Telekom - P1

China Mobile - P1

Swisscom - P1

Vodafone - P0



Doc, all projects
10

External API extension to include service modification


Orange - P2

Verizon - P3

Deutsche Telekom - P3

China Mobile - P3

Swisscom - P1

Vodafone - P2

BBS use case (proposal)

External API, Matthieu Geerebaert

11

No more hard coded components for the use-cases. ONAP is a platform to run various use-cases

(similar to requirement #6 and #24)

Orange - P2

Verizon - P1

Deutsche Telekom - P1

Swisscom - P1

Vodafone - P1




12

Footprint optimization: reduce image size, avoid image duplications, reduce memory requirements.

Orange - P1

Verizon- P1

Deutsche Telekom - P2

Swisscom - P3

Vodafone - P3



OOM + All projects

13

Stability first. Code must be more robust, more secure.

Integration must focus on code stability and not on use-cases verification

Orange - P0

Verizon - P0

Deutsche Telekom - P0

Swisscom - P0

Vodafone - P0



Integration + All projects
14

5G requirements (cf ORAN)

PNF discovery

Support of parameters/algorithm/model configurations

Orange - P1

Deutsche Telekom - P2

AT&T - P2

Vodafone - P3



SDC, AAI, APPC
15

Core Service/VNF LCM state and transition model
- Description of the LCM model
- Monitoring of the state
- Requirements towards VNF providers

Deutsche Telekom - P1

Vodafone - P1



Controller (SDNC, APPC, VF-C), SO, Modelling, Log (Pomba?)
16

Focus on Platform Automation Usecases (e.g. Scale In-Out, Upgrade of VNFs) to show the E2E Management capabilities of ONAP (addition to lines 6, 11)

(similar to requirement #6 , #24 , #11)

Deutsche Telekom - P1

AT&T - P1 (Assuming it overlaps with Req# 5 & 30)

Vodafone - P1




17Classification of core dependencies between e.g. Service/VNF components to support root cause analysis and alignment of change procedures (LCM)

Deutsche Telekom - P2

Vodafone - P2



Modelling
18PNF Modelling and Lifecycle Management to support the well defined exposure of the service endpoints (e.g. support for Edge/OSAM usecases)

Deutsche Telekom - P2

Swisscom - P1

AT&T - P1

Turk Telekom - P1

Vodafone - P3



Modelling, SDC
19The logs of SO, SDC, SDNC, DCAE, and AAI need to be optimized. The log location of error is not particularly clear

China Telecom - P1

Deutsche Telekom - P3

Vodafone - P3



SO, SDC, SDNC, DCAE, and AAI
20Tomcat, mongodb, zookeeper, it is recommended that each docker use a unified version

China Telecom - P1

Deutsche Telekom - P2

China Mobile - P3

Vodafone - P3




21Some dockers use mysql in onap, some use mariadb, different dockers use the same database version is also inconsistent, resulting in very confusing, it is recommended to have a unified version and software.

China Telecom - P1

Deutsche Telekom - P2

China Mobile - P3

Vodafone - P3



SDNC,APP-C,PORTAL,VID,NBI,CLAMP,Policy,SO

OOM - OOM-1175 - Getting issue details... STATUS , Mike Elliott

22Onap's heat and oom mode deployments require openstack support, so how onap handles and breaks some of the limitations of openstack, such as the limit of 100 stacks.

China Telecom - P1

Deutsche Telekom - P3

Vodafone - P3



OOM ?S3P
23Ability to model running instance of VNF / NS and associate it as part of NS Design (description is under Release 4 (Dublin) Service Providers (EUAG) Requirements / Proposals)

Verizon

Deutsche Telekom - P3

China Mobile - P1

Vodafone - P1 




24

Enable Self-Service use of ONAP (description is under Release 4 (Dublin) Service Providers (EUAG) Requirements / Proposals)

(similar to requirement #6 and #11)

Bell Canada - P1

Deutsche Telekom - P2

Vodafone - P2




25Multi-site / Geo-redundancy (description is under Release 4 (Dublin) Service Providers (EUAG) Requirements / Proposals)

Bell Canada - P1

Deutsche Telekom - P2

Vodafone - P2




26PNDA integration (description is under Release 4 (Dublin) Service Providers (EUAG) Requirements / Proposals)

Bell Canada - P1

Deutsche Telekom - P1

China Mobile - P1

Vodafone - P2 



DCAE, CLAMP
27ONAP Databases as a service (description is under Release 4 (Dublin) Service Providers (EUAG) Requirements / Proposals)

Bell Canada - P1

Deutsche Telekom - P2

China Mobile - P3

Vodafone - P3 




OOM - building on Casablanca deliverables to provide MariaDB Cluster as first DBaaS implementation - OOM-1193 - Getting issue details... STATUS , Mike Elliott


28Enhanced ONAP CI (description is under Release 4 (Dublin) Service Providers (EUAG) Requirements / Proposals)

Bell Canada - P1

Deutsche Telekom - P1

Vodafone - P3 




29Use of secure credentials storage for native ONAP functionality (description is under Release 4 (Dublin) Service Providers (EUAG) Requirements / Proposals)

Bell Canada - P1

Deutsche Telekom - P2

 



AAI
30VNF scaling enhancements:  Manual and Automatic Scale In

AT&T - P1

 



Impact Details Here.

APPC, SDC, SDNC, DCAE, OOF, Policy, SO, CLAMP, VID

31OSAM

AT&T - P1

Swisscom - P2

Turk Telekom - P1

 




32

Edge Automation WG - "Analytics-as-a-service"

Edge Automation Functional Requirements for Dublin

China Mobile - P1

 

Edge Automation Functional Requirements for Dublin


Source: Edge Automation WG – ramki krishnan, Raghu Ranganathan

Projects: DCAE, CLAMP, A&AI (TBD), Multi-VIM/Cloud (TBD)

33

BroadBand Service requirements:
- support for nomadic PNF (discovery, re-registration),
- service change order using External API,
- E2E service reconfiguration,
- consider scalability of ONAP components to support provisioning and assurance of high number of customer facing service instances (AAI, SO...)

Use case proposal: BBS Broadband Service (Dublin)


Swisscom - P1

 



345G requirement: 5G middle/backhaul modeling and orchestration

China Telecom - P1

China Mobile - P2

 




35

Consistent ID of a Cloud Region (Dublin)

AT&T - P1



Owner: Bin Yang

SO,VID,SDNC,OOF, UUI,VFC

 36

Evolve OOM to support Multi-site deployments of ONAP and meet Operator requirements

(Likely aligns/overlaps with requirement #25 above)

AT&T - P2

 



 OOM and (likely) all components it deploys
 37

 Continue progress on S3P levels across components

  • Complete unfinished Casablanca S3P requirements by component
    • For example: CADI/AAF integration, support for HTTPS/encrypted communications, Adherence to ONAP Logging Spec
  • Measured progress on CII badging level and unit test coverage percentages
AT&T - P2

China Mobile - P3

 



 Most (all?) components depending on current S3P levels achieved
 38 The End-End use cases that define the functionality of ONAP releases, and are tested by Integration test should include validation of the example VNFs used by ONAP (e.g. vFW)   using the test scripts for HEAT templates (from VVP project) or TOSCA ( from VNFSDK project)

AT&T - P3

 

run validation tests on the VNFs used by ONAP during integration test - TOSCA packaged VNFS using VNFSDK validation scripts and HEAT VNFS using VVP

 VNFSDK @ Weitao Gao

VVP @ Steven Wright @ Trevor Lovett

INT @ Helen Chen

applies to ALL uses cases tested by ONAP

ALL ONAP VNFS should have their conformance to VNFRQTS documented in ReadTheDocs for the Release. This should include links to the VNF Packages used for onboarding. 





  • No labels