ONAP R10 Modeling High Level Requirements
According to ONAP R10 Release requirement input LINK
Reporting on the R10 release to the TSC will begin on DATE, so the deadline for the input of high level requirement will be M0: DATE 2021.
Prioritize & Finalize:
before M1: DATE 2021, the requirement will be finalized.
There are other 5 categories of high level requirement,
1) Will be implemented in R10 by code commitment to different impacted projects/components.
2) Will document only for the R10 release.
3) Documentation after implemented in prior release
4) Lower Priority
5) Experimental
Category 1 includes those modeling requirements that will be implemented during the current release
Category 2 includes modeling requirements that produce models that will be documented, but not implemented in the current release
Category 3 is for modeling activities that are documenting models that are already implemented in ONAP
Category 4 and Category 4 are lower priority and experimental and will not be mature in the release, the contributor will work with best effort to help influence future release.
Owners of each requirement need to coordinate the modeling spec commitment and code commitment with PTLs of impacted project.
Below High Level Requirements have been agreed by modeling subcommitee with code commitment promise to Istanbul release, modeling subcommittee request related to projects to approve those related submission.
Category 1) will be implemented in the R10 release
Modeling Domain | Modeling Requirement | Modeling Requirement Description | Impacted Projects | Use Case Relevance | Modeling Spec Commitment | Code Commitment | Provider Priority | Mapping to M1 requirement | Owner | Use Case Owner |
|---|---|---|---|---|---|---|---|---|---|---|
resource IM | Create CNF Object in AAI associated with vf-module/generic-vnf/cloud-region that holds basic information about ANY CNF's k8s resource | AAI, SO, Multicloud (Implementation already present) | @Konrad Bańka , @Lukasz Rajewski | @Konrad Bańka , @Lukasz Rajewski | TBD | TBD | @Konrad Bańka , @Lukasz Rajewski | @Seshu Kumar Mudiganti , @Lukasz Rajewski | ||
resource IM | Create ASD onboarding information model | SDC | @Marian Darula @Zu Qiang | @Byung-Woo Jun |
|
| @Marian Darula @Zu Qiang | @Marian Darula @Zu Qiang @Byung-Woo Jun
| ||
resource IM | Create ASD onboarding data model | SDC | @Marian Darula @Zu Qiang | @Byung-Woo Jun |
|
| @Marian Darula @Zu Qiang | @Marian Darula @Zu Qiang @Byung-Woo Jun | ||
resource IM | Create ASD onboarding package model | SDC | @Marian Darula @Zu Qiang | @Byung-Woo Jun |
|
| @Marian Darula @Zu Qiang | @Marian Darula @Zu Qiang @Byung-Woo Jun | ||
resource IM | NSD requirements for ASD deployment | SDC | @Marian Darula @Zu Qiang | @Byung-Woo Jun |
|
| @Marian Darula @Zu Qiang | @Marian Darula @Zu Qiang @Byung-Woo Jun | ||
|
|
|
|
|
|
|
|
|
|
|
Category 2) Will document only for the R10 release
Modeling Domain | Modeling Requirement | Modeling Requirement Description | Impacted Projects | Use Case Relevance | Modeling Spec Commitment | Code Commitment | Provider Priority | Mapping to M1 requirement | Owner | Use Case Contact |
|---|---|---|---|---|---|---|---|---|---|---|
resource/service IM/DM | ETSI CNF model | update CNF IM to align with latest ETSI IFA011 and IFA014 v4.2.1 specs, and document the DM aligned with SOL001 v4.2.1 | SDC, SO | ETSI alignment | @Fernando Oliveira | NA |
|
| @Fernando Oliveira | @Fernando Oliveira |
resource IM | Abstract Topology Model | Create a Topology Information Model jointly with O-RAN and harmonize interworking among ONAP components |
|
| @Tony Finnerty @Andy Mayer @Jacqueline Beaulac [Ericsson]@Martin Skorupski | N/A |
|
| @Tony Finnerty |
|
resource IM | Design and implement high level AAI model for CNF resources. | AAI, SO, Multicloud (Implementation already present) | @Konrad Bańka , @Lukasz Rajewski | N/A (in this release) | TBD | TBD | @Konrad Bańka , @Lukasz Rajewski | @Seshu Kumar Mudiganti , @Lukasz Rajewski | ||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Category 3) Documentation Only after implemented in prior release
Modeling Domain | Modeling Requirement | Modeling Requirement Description | Impacted Projects | Use Case Relevance | Modeling Spec Commitment | Code Commitment | Provider Priority | Mapping to M1 requirement | Owner |
|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
Below tables are not downgrade, but won't produce modeling activity for the current release
Category 4) Lower Priority:
Modeling Domain | Modeling Requirement | Modeling Requirement Description | Impacted Projects | Use Case Relevance | Modeling Spec Commitment | Code Commitment | Provider Priority | JIRA Link | Owner |
|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
Category 5) Experimental:
Modeling Domain | Modeling Requirement | Modeling Requirement Description | Impacted Projects | Use Case Relevance | Modeling Spec Commitment | Code Commitment | Provider Priority | JIRA Link | Owner |
|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Requirements can be based on:
Release / project specific needs
Recognized 'future' needs
Documenting existing models
Some concepts may be complex enough, if we wait for the release / project requirement, we will be too late to properly develop the concept.