1. Review of ONAP Carrier Grade Requirements
AT&T
December 4, 2017

2. Highest priority items
Executive Summary
ONAP Carrier Grade Requirements in line with what AT&T sees as important
Not a surprising result (requirements for any large carrier likely to be fairly common)
One additional category identified
While all requirements are important, some are more critical than others
Highest priority items
Resiliency, Security, Manageability
Essential that advances be made in these areas

3. Summary Table Area Priority Min. Level Desired Level Notes Performance
Low
Level 1
Exception: more important for service assurance
Stability
Medium
Level 2
Platform level testing is important
Resiliency
High
Level 3
Want active-active configuration
Security
Role-based access control and authorization required Need audit trail
Patching strategy
Scalability
Level 0
Level 1 nice to have; not critical
Manageability
Items should be shifted between levels (details on slide 9)
Config Management
New category identified to support managing across different environments by different teams
Usability
Moderate
Info needed to deploy; API documentation

4. Priority: Low (relative to other categories)
Performance
Levels
0 -- none
1 -- baseline performance criteria identified and measured
2 & 3 – performance improvement plans created & implemented
Priority: Low (relative to other categories)
Many ONAP actions likely won’t place high load on system
E.g., service instantiation
However, service assurance functions are more performance sensitive
Depend on timely delivery of performance and fault data
This data is higher volume
Hence, performance is more important for functions supporting service assurance (i.e., DCAE)

5. Levels Priority: medium Comments 0 -- none
Stability
Levels
0 -- none
1 – 72 hour component level soak w/random transactions
2 – 72 hour platform level soak w/random transactions
3 – 6 month track record of reduced defect rate
Priority: medium
Comments
Platform level testing is important
Coverage of all key flows important
Varied and concurrent activity to identify interactions that could lead to problems
Introduce random delays to test robustness to delay

6. Levels Priority: High Comments 0 -- none
Resiliency
Levels
0 -- none
1 – manual failure and recovery (< 30 minutes)
2 – automated detection and recovery (single site)
3 – automated detection and recovery (geo redundancy)
Priority: High
Comments
Important requirement
Minimum requirement Level 2; Level 3 is desired
Target state should be active-active configuration

7. Levels Priority: High Comments 0 -- none 1 – CII Passing badge
Security
Levels
0 -- none
1 – CII Passing badge
2 – CII Silver badge; internal communication encrypted; role-based access control and authorization for all calls
3 – CII Gold
Priority: High
Comments
Important requirement (Level 2 needed)
Role-based access control to all APIs is important
Audit trail is also an important requirement
Security requirements should include a patching strategy
Penetration testing would be desirable

8. Levels Priority: Low Comments 0 – no ability to scale
Scalability
Levels
0 – no ability to scale
1 – single site horizontal scaling
2 – geographic scaling
3 – scaling across multiple ONAP instances
Priority: Low
Comments
Not an immediate high priority item
Should explicitly note that scaling must be transparent to users (i.e., client/consumer of an API/microservice should not be impacted by scaling)

9. Levels Priority: High Comments
Manageability
Levels
1 – single logging system across components; instantiation in < 1 hour
2 – ability to upgrade a single component; tracing across components
Priority: High
Comments
Transaction tracing is more important than the ability to instantiate in less than an hour
Suggested revision of levels:
0 – All ONAP components use a single logging system
1 – Transaction tracing across components; Instantiation in less than 4 hours; Ability to independently upgrade a single component
2 – Instantiation in less than 1 hour
Deployment should be fully automated
Requirements should consider impact of component upgrade (i.e., hitless?)

10. Configuration Management
New category we propose
Levels
0 – ability to deploy the entire ONAP as a whole
1 – support for ability to define what ONAP components get deployed
2 – support for control over management of environmental properties in different environments and throughout the lifecycles; support for an audit trail on configuration data changes
Priority: High
Comments
ONAP will be deployed into many environments managed by different teams
E.g., Dev, Test and Operations teams all deploy into and manage different environments
Need to use same processes and mechanisms across environments while giving control to appropriate teams in each
Changes to how things get deployed in one environment need to flow through across all environments

11. ONAP Guideline is under-specified
Usability
ONAP Guideline is under-specified
“Documentation completion/consistency [need metric]”
Our Requirements (Level1)
User Guide
Concise description of the input information needed to deploy the system
Documentation for all ONAP APIs
Level 2
Consistency of UIs
Usability testing
Tutorial documentation
Priority: High