| Status | Choose One: DRAFT |
|---|---|
| Submitter | Steven Wright |
| Contributors | Names of additional contributors |
| Proposed Release | Casablanca |
| JIRA Ticket(s) | VNFRQTS-242 - Getting issue details... STATUS |
The objective is to extract / summarize VNF Requirements into a VNF Badge with a format similar to the CII Badging website see e.g. CII Badge for VVP.
The main difference is that the badge is for a VNF rather than an open source project.
As an initial target, it has been proposed to focus on the requirements associated with VNF Management (i.e. Chapter 7 of the ONAP VNF Requirements) . This Chapter 7 represents ~190 of the >750 requirements ie ~25% of the VNF requirements identified.
The specific badge would need to be aligned with the LFN guidance on logos, but something along the following lines may be a place to start.
The current CII badge has ~70 requirements, in 6 pulldown menus. The max requirements in a pulldown is 16.
For usability, we should constrain the number of pulldowns and the number of requirements per pulldown to a similar order of magnitude e.g. pulldowns < 10, reqts/pulldown <20
The VNF Requirements in Ch7 as of mid August (there are some changes pending for section 7.4 and 7.5 in VNFRQTS-278 - Getting issue details... STATUS and VNFRQTS-289 - Getting issue details... STATUS )
| Section | Number of Reqts | Topic |
|---|---|---|
| 7.1 | 0 | Service Design |
| 7.2 | 55 | VNF On-boarding and package management |
| 7.2.1 | 0 | Design Definition |
| 7.2.2 | 9 | Resource Description |
| 7.2.3 | 9 | Resource Configuration |
| 7.2.4 | 18 | Resource Control Loop |
| 7.2.5 | 7 | Compute, Network, and Storage Requirements |
| 7.2.6 | 3 | Testing |
| 7.2.7 | 9 | Licensing Requirements |
| 7.3 | 114 | Configuration Management |
| 7.3.1 | 20 | Controller Interactions With VNF |
| 7.3.2 | 63 | NETCONF Standards and Capabilities |
| 7.3.2.1 | 63 | VNF Configuration via NETCONF Requirements |
| 7.3.2.1.1 | 2 | Configuration Management |
| 7.3.2.1.2 | 61 | NETCONF Server Requirements |
| 7.3.2.1.2 | 44 | (other- no subheading) ** needs further breakdown/summarization |
| 7.3.2.1.2 | 11 | Yang Models |
| 7.3.2.1.2 | 6 | Netconf RFCs |
| 7.3.3 | 1 | VNF REST APIs |
| 7.3.4 | 14 | Chef Standards and Capabilities |
| 7.3.5 | 16 | Ansible Standards and Capabilities |
| 7.3.6 | 0 | Support of Controller Commands And Southbound Protocols |
| 7.4 | 27 | Monitoring & Management |
| 7.4.1 | 0 | Data Model for Event Records |
| 7.4.2 | 0 | Event Records - Data Structure Description |
| 7.4.3 | 0 | Data Structure Specification of the Event Record |
| 7.4.4 | 0 | Transports and Protocols Supporting Resource Interfaces |
| 7.4.5 | 27 | Monitoring & Management Requirements |
| 7.4.5.1 | 1 | VNF telemetry via standardized interface |
| 7.4.5.2 | 0 | Encoding and Serialization |
| 7.4.5.3 | 1 | JSON |
| 7.4.5.4 | 0 | KV-GPB/GPB |
| 7.4.5.5 | 1 | Reporting Frequency |
| 7.4.5.6 | 8 | Addressing and Delivery Protocol |
| 7.4.5.7 | 9 | Asynchronous and Synchronous Data Delivery |
| 7.4.5.8 | 4 | Security |
| 7.4.5.9 | 3 | Bulk Performance Measurement |
Naively mapping sections to pulldowns would still have (Red) sections with more than 20 reqts, and would need some further breakdown or summarization. pulldowns with 0 or 1 requirement do not make sense, and should be consolidated. This would suggest ~16 pulldowns with an addition pulldown to consolidate the 4 sections with a single reqt, and some further breakdown/ summarization of the 44 reqts in 7.3.2.1.2. Something like:
| Section # | Num. of reqts | Pulldown titlep |
|---|---|---|
| 7.2.2 | 9 | Resource Description |
| 7.2.3 | 9 | Resource Configuration |
| 7.2.4 | 18 | Resource Control Loop |
| 7.2.5 | 7 | Compute, Network, and Storage Requirements |
| 7.2.6 | 3 | Testing |
| 7.2.7 | 9 | Licensing Requirements |
| 7.3.1 | 20 | Controller Interactions With VNF |
| 7.3.2.1.2 | 11 | Yang Models |
| 7.3.2.1.2 | 6 | Netconf RFCs |
| 7.3.4 | 14 | Chef Standards and Capabilities |
| 7.3.5 | 16 | Ansible Standards and Capabilities |
| 7.4.5.6 | 8 | Addressing and Delivery Protocol |
| 7.4.5.7 | 9 | Asynchronous and Synchronous Data Delivery |
| 7.4.5.8 | 4 | Security |
| 7.4.5.9 | 3 | Bulk Performance Measurement |
| 7.3.3 / 7.4.5.1 / 7.4.5.3 / 7.4.5.5 | 4 | VNF REST APIs / VNF telemetry via standardized interface / JSON / Reporting Frequency |
| 7.3.2.1.2 | 44 | (other- no subheading) ** needs further breakdown/summarization |
Scoring with simple counts of Met/Unmet will not be sufficient:
R-89571 provides for alternatives (one or more of) : Netconf/ Chef/ Ansible
Section 7.4 has MAY or SHOULD requirements which should not have the same weight as a MUST requirement.
VNF Badging should avoid overlap/ duplication with VNF validation based on testing.
Of the ~192 requirements in section 7 about 25 are identified in the Test Description Annex as being inspectable in the VNF package delivered from the VNF provider to the ONAP operator.
Ch 7 includes a number of requirements on VNF Package or xNF Package that are not included in that Test Description Annex (yet) but are presumably inspectable in the Package at some point even if the inspection tests are not yet available in VVP or VNFSDK as part of the Casablanca release. VNFRQTS-241 - Getting issue details... STATUS provides for updates to this document as part of the Casablanca release.
Eliminating the requirements that are inspectable in the xNF Package would reduce the number of requirements in the table above - ~30 of the 190 requirements are on the xNF or VNF Package ie ~15%