...
Below High Level Requirements have been agreed by modeling subcommitee with code commitment promise to Dublin releaseto El Alto release, modeling subcommittee request related to projects to approve those related submission.
Modeling Domain | Modeling Requirement | Modeling Requirement Description | Impacted Projects | Use Case Relevance | Modeling Spec Commitment | Code Commitment | Provider Priority | Mapping to M1 requirement | Owner |
---|
Resource DM
ETSI NFV SOL001 v2.5.1
VNFD - the ONAP internal data model should be able to reflect ETSI SOL001 VNFDs provided for onboarding
SDC, VFC
CCVPN, vCPE
ETSI NFV SOL001 v2.5.1
PNFD - the ONAP internal data model (AID)should be able to reflect ETSI SOL001 PNFDs provided for onboarding.
(committed goal)
''''''''''''''''
Could an Onboarded PNFD also be internally mapped to the second ONAP internal model (nfv tosca types) ?
Could two internal descriptors coexist in the same internal SDC package ?
(stretch goal)
SDC
Ericsson.
Part of 5G UC Onboarding UC in Dublin.
SDC-1976Michela BevilacquaThere are other 4 categories of high level requirement,
- 1) Will be documented only and included in the Dublin release, but no implementation promised.
- 2) Documentation after implemented, or implemented but not in the release
- 3) Lower Priority
- 4) Experimental
...
1) Will be documented only and included in the Dublin 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 |
---|
N/A
related to DM SOL001 progress
impact R4 DM?
NSD - the ONAP internal data model should be able to reflect ETSI SOL001 NSD provided for onboarding
SDC, SO, VFC
Common | Root | To establish a root or core model for ONAP. | Kevin Scaggs | ||||||
Common | Business Interaction | To establish a general business interaction model for ONAP, and provide a means to tie in concepts such as Service Order, VES Events, and Licenses into the model hierarchy. | Kevin Scaggs | Kevin Scaggs | |||||
2) Documentation after implemented, or implemented but not in the 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 |
---|
Service
To document the allotted resource IM as implemented by SDC
N/A
Common | VES | To document the |
Kevin ScaggsN/AHighChuyi Guo
To document the onboarding NS IM as supported by the usecase
shitao liN/AHighHigh
VES Event Streaming model as implemented. | N/A |
Kevin Scaggs | N/A |
Kevin Scaggs |
Below tables are not downgrade, but casablanca won't make it
3) Lower Priority:
Modeling Domain | Modeling Requirement | Modeling Requirement Description | Impacted Projects | Use Case Relevance | Modeling Spec Commitment | Code Commitment | Provider Priority | Owner |
---|
Service
Common
Policy
create policy IM, reflect current policy project implementation
Policy
N/A
N/A
Infrastructure
4) Experimental:
Modeling Domain | Modeling Requirement | Modeling Requirement Description | Impacted Projects | Use Case Relevance | Modeling Spec Commitment | Code Commitment | Provider Priority | Owner |
---|
Common
License
create super classes for current models
Per discussion in Paris, requirements can be based on:
...