Based on timeplan of modeling subcommittee, high level requirements need to be finished by M0,
There are 4 categories of high level requirement,
The first category is that those requirement will be implemented and commited by the impacted projects in this release
the second category will document the current implementation in those projects.
Other two categories like lower priority and experimental will not be included in the release 3, the contributor will work with best effort to influence future release.
Owners of each requirement needs to coordinate the modeling spec commitment and code commitment with PTLs of impacted project.
1) Will be implemented and included in the release 3
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 | VNFD | ONAP Resource Data Model for Design Time? -Agreement that the VNF Descriptor model for On-Boarding and the Internal ONAP models are distinct. (note: an internal model may be used as one of the on-boarding options) | SDC A&AI OOF SO VFC Policy | VoLTE VCPE CCVPN | AT&T Intel | AT&T Intel | AT&T: High | SDC (Y) A&AI (Y) SO (Y) OOF(Y) Policy (Y) VFC (Y) | |
| PNF for 5G | software version | SDC SO | 5G | Nokia | SDC (Y) SO (Y) |
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 | Service Order | It includes the definition of the managed objects that allows a BSS system to create/delete/update/get an order of a service to a ONAP instance. The Service Order Modeling provided by Ext API R2 team must be reviewed to become part of the ONAP common service IM | Ext API(y) | VoLTE CCVPN Change Mgt | CMCC Huawei ZTE Vodafone AT&T Verizon Orange | CMCC Huawei ZTE Vodafone Orange | CMCC: High Vodafone: High AT&T: High Verizon-High | ExtAPI (Y) | Andy Mayer (AT&T) |
| Service Catalog | A Service Catalog is a group of ServiceDescriptors that an organization provides to the consumers via ONAP. | Ext API | VoLTE CCVPN | CMCC Huawei ZTE Vodafone AT&T Verizon Orange | CMCC Huawei ZTE Orange | CMCC: High Vodafone: High AT&T: High Verizon-High | ExtAPI (Y) | Kevin Scaggs (AT&T) | |
| Service Descriptor | Design time model: service descriptor model, document the existing service model in SDC | Ext API SO SDC | (All) VoLTE CCVPN 5G vCPE | CMCC Huawei ZTE Vodafone AT&T Verizon Orange | CMCC Huawei ZTE Orange | CMCC: High Vodafone: High AT&T: High Verizon-High | SDC (Y) EXTAPI(Y) SO(Y) | LIN MENG (CMCC) | |
| Resource | License | Presently modeled and used in SDC, (ONAP license model) | SDC (No impact, information providing only) | AT&T Verizon | AT&T: Medium Verizon-Medium | SDC (Y) | Kevin Scaggs(AT&T) | ||
| Alloted resource | 1 document the existing SDCs current implementation 2 continue to work on the feature. (maybe some implementation will follow these features) | SDC | All | AT&T Intel | AT&T Intel | AT&T: High | SDC (Y) | Andy Mayer (AT&T) | |
| Scaling (HEAT template) | Scaling Use Case Extension . Casablanca focus: Document the Policy Model that is being implemented by the ONAP Policy Framework. | SDC (no impact) A&AI (no impact) SO (no impact) Policy Clamp (no impact) | vDNS (Scaling) | AT&T | CMCC: Medium Vodafone: Medium AT&T: High | SDC (no impact) A&AI (no impact) SO (no impact) Policy (Y) Clamp (no impact) | Andy Mayer (AT&T) Gil Bullard ((AT&T) | ||
| ResourceComposite |
| SDC VNFSDK(y) | VoLTE CCVPN | CMCC Huawei ZTE Vodafone AT&T Verizon Intel | CMCC Huawei ZTE Intel | CMCC: High Vodafone: High AT&T: High Verizon-High | SDC (Y) VNFSDK (Y) | ||
| Network Service | 1 create a data model for network service | SDC VFC | VoLTE CCVPN 5G | CMCC Huawei ZTE AT&T | CMCC Huawei ZTE | CMCC: High Vodafone: High AT&T: Medium | SDC (Y) VFC (Y) | Chuyi Guo | |
Telemetry | Events & VES | VES Event Descriptor Model according to VES spec v6.0 | DCAE SDC | AT&T Verizon | AT&T: High Verizon-High | DCAE(Y) SDC (Y) |
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 | servicecomposite | Design/run time model : Service IM review according to the agreed Service Composite pattern. (Composite Pattern UML diagram) | SDC (L) Ext API (=SDC) SO | VoLTE CCVPN | CMCC Huawei ZTE Vodafone AT&T Verizon | CMCC Huawei ZTE | CMCC: High Vodafone: High AT&T: High Verizon-High | |
| Service Scaling | A run time service instance could be updated by scaling in/out its capacity via deleting/adding new resources instances, e.g. sites in CCVPN usecase. | SDC SO AAI | VoLTE CCVPN | CMCC Huawei ZTE Vodafone AT&T Verizon | CMCC: High Vodafone: High AT&T: Medium Verizon-Medium | |||
Service Instance | Run time model: service instance model in relation to the design time model and Service Composite pattern. (Composite Pattern UML diagram) | A&AI Ext API SO SDC | (All) VoLTE CCVPN vCPE | CMCC Huawei ZTE Vodafone AT&T Verizon Orange | CMCC: High Vodafone: High AT&T: High Verizon-High | Kevin Scaggs(AT&T) | ||
Resource | ResourceComposite | Design time model: Resource composite model introduction according to the agreed Service Composite pattern. It includes the NS model review from Service component to Resource Composite and change of Modeling Domain (Composite Pattern UML diagram) The ResourceComposite includes below sub-requirements:
| SDC(->) VNFSDK | VoLTE CCVPN | CMCC Huawei ZTE Vodafone AT&T Verizon Intel | CMCC Huawei ZTE | CMCC: High Vodafone: High AT&T: High Verizon-High | |
| Network Service (modeling subcommitee DM approve firstly) | Context:
Network service is agreed in resource IM group. Networkservice IM Network service Descriptor has been discussed in DM group. Networkservice DM 4. SDC progress org.openecomp.resource.vfc.NSD has been imported in ONAP catalog in R2 https://gerrit.onap.org/r/gitweb?p=sdc.git;a=tree;f=catalog-be/src/main/resources/import/tosca/nfv-types/NSD;h=bf5cabb52dc41025f4708c7c095e304196e7e6a6;hb=refs/heads/master SDC functionality does not support NSD yet in R2 SDC requiremnets in R3: 1. SDC design UI, catalog(FE,BE,Database, API) shall support NS and related package based on R2 link 2. In resource design, NS descriptor shall be composed of VNFD, and VLD at least to support VoLTE based on R2 resources 3. In service design, service descriptor could be composed of the NSD. 4. NS descriptor shall refinement to support R3 NS DM Proposal( Stretch goal) | SDC | VoLTE CCVPN 5G | CMCC Huawei ZTE AT&T | CMCC Huawei ZTE | CMCC: High Vodafone: High AT&T: Medium | Chuyi Guo | |
| VNF instance (run time) | Run time model of a VNF instance (low) | A&AI | VoLTE CCVPN 5G vCPE | CMCC Huawei ZTE AT&T Verizon | CMCC Huawei ZTE | CMCC: High Vodafone: High AT&T: High Verizon-High | Kevin Scaggs (AT&T) | |
| PNF instance (run time) | Run time model of a PNF Instance. | SDNC A&AI SO | VoLTE CCVPN 5G | CMCC Huawei ZTE Vodafone | CMCC Huawei ZTE | CMCC: Medium Vodafone: Medium | Weitao Gao | |
| WAN Connection | Wan Connection Information Model | SDC(->) SO A&AI SDNC | VoLTE CCVPN | CMCC Huawei ZTE AT&T Verizon | CMCC Huawei ZTE | CMCC: High Vodafone: High AT&T: Medium Verizon-Medium | Zhuoyao Huang | |
| SD-WAN | CCVPN SD-WAN Information Model | CMCC Huawei AT&T Verizon | CMCC: High Vodafone: High AT&T: Medium Verizon-High | Chuanyu Chen | ||||
| ElementGroup enhancement (lower) | Tied to modeling of Scaling, Homing, Placement, etc. | SDC SO | AT&T | AT&T: Medium | Andy Mayer (AT&T) Kevin Scaggs (AT&T) | |||
Infrastructure | Multi-cloud | The cloud abstractions needed for homing in the edge cloud across public cloud and service-provider-owned-cloud | Multicloud | AT&T | AT&T: Medium | |||
Telemetry |
4) Experimental:
Modeling Domain | Modeling Requirement | Modeling Requirement Description | Impacted Projects | Use Case Relevance | Modeling Spec Commitment | Code Commitment | Provider Priority | Owner |
|---|---|---|---|---|---|---|---|---|
Resource | Container | Resource modeling changes in the IM, design time DM and runtime DM | Multi-Cloud | Intel | Intel | |||
| Acceleration Management (BoF) | Discussing the requirement for acceleration management in ONAP, including research motivation,problem statement, as well as proposals. Welcome to join this thread. | Lei Huang |
20 Comments
Thinh Nguyenphu
Hello, it is not clear to me what are detail requirements per each of the item in the "Modeling Requirement" column.
Michela Bevilacqua
HI
Can you clarify:
Telemetry
Events & VES
What is the ambition in terms of modeling?
Add in the common model the VES event model as defined in R60 ? All domains?
Jessie S Jewitt
Thank you for putting together this table. It is very helpful.
I have three comments:
Stephen Fratini
Hi Jessie
FYI ... on your point #2, the TM Forum has made a similar decision, i.e., we use an object class know as Resource Function to cover atomic (VNF and similar) and composite (NS and similar) entities. This is in the SID Logical Resource model and also explained in TM Forum TR255 series.
Steve Fratini
Jessie S Jewitt
Steve-
There are a number of TR255 documents. Could you tell me which one exactly? I couldn't find it in the SID either, but I have version 16.5. In which version does this appear?
Thanks,
Jessie
Stephen Fratini
Jessie
See Section 2 of TR255 (main document).
Further detail about Resource Functions is in Section 2 of GB922 Logical and Compound Resource Computing and Software R17.5.1.
Steve
Jessie S Jewitt
Steve-
Please provide the title of the "main" document, as 4 documents are in the TR255 zip file.
Jessie
Stephen Fratini
Jessie
It is "TR255 Resource Function – Activation and Configuration R17.5.1"
Link is https://www.tmforum.org/resources/technical-report/tr255-resource-function-activation-and-configuration-r17-5-0/
Steve
Chesla Wechsler
I see VNF Instance as being part of the runtime model.
I see PNF referenced as both design time model and runtime model.
Why wouldn't we have a PNF instance for the runtime model?
Jessie S Jewitt
Our understanding was that "Acceleration Management" was not accepted as a use case, and that this requirement should thus be removed.
Ludovic Robert
Ext API is mentioned for service order but it's worth to be noted that Ext API also provided a modeling for service (service inventory assets retrieved from AAI) and serviceSpecification (that a serviceCatalog resource). These could be also reviewed by Modeling team.
Nigel Davis
On Jessie's point "The composite/atomic pattern was discussed and only agreed upon by the service IM team...", I thought I would take another shot. Through a number of separate modeling activities it has become apparent that:
To be clear, I made these points (via several slides) in the service IM discussion, so I am only reiterating my ongoing concerns in this broader context.
Stephen Fratini
Nigel and all,
This is not to contradict the points from Nigel but rather to point out another facet of complexity.
We had some similar discussions in the TM Forum ZOOM work. The distinction between composite and aggregate is not always black and white. For example, in the design phase, a VNF is atomic from the perspective of the service provider who purchases the VNF and perhaps wants to compose with other VNFs to form a Network Service. However, from a real-time management perspective, the service provider does know about the VNFCs within the VNF and can, for example, scale the VNF to have more or less VNFCs. So, a VNF is not an atom during the working phase. Same point concerning the deployment phase where the VDUs (supporting a VNF) can be deployed in separate "locations." The point is that the pattern in question here depends on the given phase of the entity.
Steve
Michela Bevilacqua
I believe we have already spent enough time speaking of composite vs recursive model (at least from dec 2017).
Nigel Davis
I spent time providing arguments and examples that explained why I think the pattern is not appropriate for the Service model, especially not where and how it is proposed to be applied. At the time, I used some Resource examples. I am simply reemphasizing that the pattern, as proposed, is not helpful in the resource model. As Jessie pointed out, it was only with respect to Service that the decision was made.
I do not recall anyone actually explaining what was wrong with my argument (or even analyzing my argument in detail). Either this means there was a blindingly obvious flaw, in which case it would be helpful if someone could point it out (as it is not obvious to me), or the arguments have not really been assessed. I am assuming the latter at this point and hence am re-raising the key points in this broader context.
Incidentally, I am not proposing a simple recursion in the general case, although I do think that a simple recursion is quite suitable in some degenerate cases, I am proposing that we develop a component - system model similar to the TOSCA "metamodel" and that we use properties to indicate the current point of opaqueness.
But if you would all prefer that I simply wait until we get to the necessary level of sophistication of use case, I am OK with that.
John Strassner
I agree with Michela.
We discussed BOTH the Resource and Service models at length in December. We gave examples and there were no disagreements. In contrast, both Joel and I objected to examples made using the recursive pattern.
Your position seems to be "we made a decision, and what if it is wrong". The essence of modeling is making decisions. If it is wrong, then we fix the model. Otherwise, like this discussion, we get nowhere.
We made a decision. We have then redecided on the decision at least 5 times. It is tiresome.
Nigel Davis
OK. I only came across a decision in a narrow context (of service modeling) and was led to believe by some comments in this thread that there was another opportunity to assess the decision in a broader context. If the decision has already been made by this broader group, I apologies for not realizing. As was the case with the Service model, and as I noted in my comment here, I am OK to live with the decision and use the model as is. I will wait till we get to the sophistication of use case that requires us to change. At that point I will make some proposals.
Michela Bevilacqua
Hi,
To be clarified the following modeling requirement/modeling description
What feature is intended to be added in the Resource Information model?
Why the description refers to the Data model ?
Michela Bevilacqua
Can you enrich the modeling description in terms of what are the information model impacts ?
SD-WAN
maopeng zhang
1.In the resource level, there is lack of VL resource, which is already used in the R2 usecases(vCPE or VoLTE) and needs to be enhanced in R3. suggest to add it.
2. In the service level, there is service catalog. Should we add the resource catalog as an requirement?
In my mind, at least network service, VNF, etc as resources need a catalog.
Additions:
Could the PNF and PNF instances be merged into one requirement? Similarly, VNF and VNF instances.