0

(given CLAMP is design time there is no point to adhere to L2 requirement) 

• 0 -- none
• 1 – Level 0: no performance testing done
• Level 1: baseline performance criteria identified and measured
• 2 & 3 – performance improvement plans created & implemented
• measured  (such as response time, transaction/message rate, latency, footprint, etc. to be defined on per component)
• Level 2: performance improvement plan created 
• Level 3: performance improvement plan implemented for 1 release (improvement measured for equivalent functionality & equivalent hardware)

minimum level for Dublin is 0 except for Control Loop projects. 

see Performance levels

• Level 0: none beyond release requirements
• Level 1: 72 hour component-level soak test (random test transactions with 80% code coverage; steady load)
• Level 2: 72 hour platform-level soak test (random test transactions with 80% code coverage; steady load)
• Level 3: track record over 6 months of reduced defect rate

minimum level for Dublin:2 

see Stability levels

1

• Level 0 – none: no redundancy
• Level 1 – : support manual failure and recovery (< detection & rerouting or recovery within a single site; tested to complete in 30 minutes)
• Level 2 – : support automated detection and recovery (single site)
• 3 – automated detection and recovery (geo redundancy)

• 0 – none
• 1 – CII Passing badge + 50% Test Coverage, including no critical and high known vulnerabilities>60 days old
• 2 – CII Silver badge; internal/external communication encrypted; role-based access control and authorization for all calls based on CADI
• 3 – CII Gold

• 0 – no ability to scale
• 1 – single site horizontal scaling
• 2 – geographic scaling
• 3 – scaling across multiple ONAP instances

1

(2, if CLAMP can get more resource from the community)

• 1 – single logging system across components; instantiation in < 1 hour

• 2 – ability to upgrade a single component; tracing across components; externalized configuration management
  ; All application logging to adhere to
  ONAP Application Logging Specification v1.2

• 3 - Transaction tracing across componentsfailure detection & rerouting 
  • within a single geographic site
  • stateless components: establish baseline measure of failed requests for a component failure within a site 
  • stateful components: establish baseline of data loss for a component failure within a site

• Level 3: support automated failover detection & rerouting 

  • across multiple sites 

  • stateless components 

    • improve on # of failed requests for component failure within a site 

    • establish baseline for failed requests for site failure 

  • stateful components 

    • improve on data loss metrics for component failure within a site 

    • establish baseline for data loss for site failure

Minimum Levels (Dublin)

• Runtime Projects: Level 2 (stretch goal Level 3)
  • NOTE: For Dublin, the building blocks will be put in place for Level 3 geo-redundancy, and a few projects will pilot it
• All other Projects: Level 1 (stretch goal Level 2)

see Resiliency Levels 

same as in Casablanca, not enough resource to allocate to this effort.

see Security Levels

• Level 0: no ability to scale
• Level 1: supports single site horizontal scale out and scale in, independent of other components
• Level 2: supports geographic scaling, independent of other components
• Level 3: support scaling (interoperability) across multiple ONAP instances

Minimum Levels (Dublin)

• Runtime Projects: Level 1 
  • NOTE: For Dublin, the building blocks will be put in place for Level 2 geographic scaling, and a few projects will pilot it
• All other Projects: Level 0 

see Scalability levels 

1

(2, if CLAMP can get more resource from the community)

• Level 1:
  • All ONAP components will use a single logging system.
  • Instantiation of a simple ONAP system should be accomplished in <1 hour with a minimal footprint
• Level 2:
  • A component can be independently upgraded without impacting operation interacting components
  • Component configuration to be externalized in a common fashion across ONAP projects
  • All application logging to adhere to ONAP Application Logging Specification v1.2
  • Implement guidelines for a minimal container footprint
• Level 3
  • Transaction tracing across components

Minimum Levels (Dublin)

• All Projects: Level 2
  • New projects should adhere to v1.2
  • Existing projects have stretch goal for v1.2
• Stretch Goal: Level 3 
• Note: some work will be done in Dublin to test/prep for a release upgrade strategy

see Manageability Levels 

1

(2, if CLAMP can get more resource from the community)

• Level 1

  – user guide; deployment documentation;

  :

  • • User guide created
    • Deployment documentation
    • API documentation
  2 – API documentation; usability testing; tutorial documentation;
  • • Adherence to coding guidelines
• Level 2:
  
  • API Documentation
    • • All new API’s must adhere to the ONAP API Common Versioning Strategy and Documentation Guidelines
  ;
  • • • All existing APIs must be documented in Swagger 2.0
• 3 - UI consistency; usability testing; API Documentation

  (changed and external APIs follow policy)

• 4 - API Documentation (all follow policy)

   
• Level 3
  • • Consistent UI across ONAP projects
    • Usability testing conducted
    • API Documentation
      • All new API’s, all external APIs, and all existing API’s that are modified must adhere to the ONAP API Common Versioning Strategy and Documentation Guidelines
• Level 4
  
  • • API Documentation
      • All API’s for a given project must adhere to the ONAP API Common Versioning Strategy and Documentation Guidelines

  Minimum Levels (Dublin)

  • All Projects: Level 2
  • Stretch Goal: External APIs also follow the Versioning Strategy

  
  

• see Usability Levels