0

A: ms RM cleanup (ch content complete 80%, issue closure)

1

• B: 1.x Various: May need to be rationalized w/ new Tech Steering document

• A: 1.9 Roadmap: This section needs perpetual maintenance (strongly consider moving the roadmap out of the RM, altogether)

• A: RA Compliance/traceability methodology 

• A: Still needs a crisp executive summary identifying the problem statement, and the two key methodologies employed to address them (VNF Abstraction and a common NFVI)

RM-Ch01 - Intro

• A: RA Compliance/traceability methodology 

  • Needs to be Chapter 8 content (move to)

2

• B: Needs a community aligned list of workloads the platform is intended to support and their priority, which can then be used as a basis for resource allocation and for weighting “suggestions” (notably “The public cloud does it this way, so we should too.”; understood, but we need an objective basis. Right now, it becomes a subjective debate)

• A: Align and execute on Prague proposal to park the Compute Intensive flavor, and supplement it by removing "over-subscription?" from the Basic flavour

• C: Flesh out quantitative details about supported workloads. (nice to have)

RM-Ch02 - VNF Requirements & Analysis

3

• A: Needs tighter coupling w/ Container paradigm (i.e. decoupling from VM-based VNF)

  • flavours for example might not be applicable to containers(CPU and memory, disc we want to find a way for containers) - possibly Ch04

  • harmonisation of template in Model.

• C: Needs a general review. Given the experience we’ve gained, can be made more succinct and more usable by a VNF developer

• C: Need to clearly explain slicing (and contrast to Tenant) from CNTT perspective

• B: Template attributes should be vetted w/ underlying capabilities, rationalized for duplication (i.e. CNTT value add, vs. what’s already in HEAT) and expanded to integrate Container paradigms

• B: Data Model - Create actual schema(s) and data model(s) for CNTT-specific information (potentially in an appendix)

• A: ms Shared w/ RM-Ch4: Need to define virtual networking strategy and related attributes/parameters (workload level)

RM-Ch03 - Modelling

@Pankaj.Goyal Flavours/Flavors are not mentioned in RM Ch03. The term "virtual resource" is used and that includes resources that result from both hardware (server) and Operating System virtualisation. Typically, VNFs and CNFs are  mentioned together; there is an exception that should be corrected.

4

• A: Integrate more Container paradigms/support

• C: ms Flesh out Generic Fabric Model (Fabric, Underlay and Overlay level (i.e. Infra, not workload)

• C: Research and enhance storage performance extensions using performance per unit of storage model (i.e. IOPs/GB)

• A) Hardware Profiles and Performance.

  • Objectives/

  • Guidelines

  • What level of granularity.

  • Validation/Auditing.

  • Proposals or white paper on how we plan to achieve deterministic performance from the reference model w/o having to specify hardware to down to a very granular level (e.g. w/o SKUs, clock speeds, etc.)

• A: Clarify diagrams and language around T-Shirts, Flavors and IT relationships

• A: ms Policies for Non-Conforming Technologies // assumes supporting frameworks are ratified

  • SRIOV policy

  • SmartNIC policy*

  • Live Migration policy

  • *includes Tomas’ concept of driving SmartNIC industry to standard, cloud-friendly ABI

• A: Shared w/ RM-Ch3: Need to define virtual networking strategy and related attributes/parameters (workload level).

  • 4.2.2: need to consider aggregate network bandwidth instead of per Interface bandwidth.

• TBD: VNF Evolution / VNF Profile Generations

• TBD: Simplify VNF Profile Naming

RM-Ch04 - Infrastructure Capabilities, Measurements and Catalogue

@Pankaj.Goyal suggest that the White Paper be not priority A.

Generic Fabric Model → Focus on terminology for Baldy.

5

• A: Integrate cloud native concepts w/ sw profile (i.e. how abstraction and workload portability is maintained)

• A: Update s/w profile, pending parking of Compute Intensive IT

  • Rationalize s/w profile to IT mapping after removal of third IT

  • Audit chapter alignment w/ RM-Ch4

• A: Incorporate VNF Profile Generations/Evolution (once ratified), designing and describing linkage/relationship to h/w profiles

RM-Ch05 - Feature set and Requirements from Infrastructure

6

• B: Flesh out initial Enabler Services

RM-Ch06 - External Interfaces (APIs and Interfaces)

7

• A: ms Worthy of review by SMEs for suggestions of areas to incorporate and/or refine

19 Feb 2020

RM-Ch07 - Security

Added Security Requirements PR#1118

8

• Cleanup to Ch08

  • A: Generic  qualification model (i.e. NFVI and VNF)

    • Badging types (requirements in RC)

    • Methodology to support N-3 VNF Rls Profiles

  • A: Overview of badging methodology

    • Base-lining testbed before VNF qualification

    • VNF testing without prior knowledge

    • Plumbing testbed for supplier testing of VNF functionality, after VNF badging.

  • A: ms Overview of novel VNF-related concepts

    • Reference VNF (aka Golden VNF)

    • NFVI characterization, and correction coefficients for normalizing performance

  • A: What is out of scope for CNTT (e.g., VNF functional testing, performance, scalability, HA, etc.)

RM-Ch08 - Compliance, Verification, and Certification

Should the RM content be VNF/CNF agnostic?

9

• C: Create Generic Installer Model

RM-Ch09 - Infrastructure Operations and Lifecycle Management

A

• C: Needs a strategy/purpose review and new commitment from original or new contributors to continue on it.

RM-Appendix-A - VNF Guidelines

1

A: RA-1 cleanup (ch content complete 80%, issue closure)

Mar 15, 2020 

2

A: Update OpenStack version based on newer version. (let continue discussion TSC call)

TBD (Baraque release)

Overall: Needs a TSC/Governance decision on criteria and then selection. Should not be Baldy release

Criteria to be discussed in vF2F April 21st. New version of RA-1 for selected OpenStack release will be in scope for Baraque release.

3

A: Update RA-1 Ch01: Introduction content

Develop after most Chapters greater than 60% complete

Issue #1081

• A: Remove 1.6 as this will be moved into Overall Roadmap.

• A: Remove CI (as this has been decided to be parked for a bit and picked up later).

March 15, 2020

Ch01 Issue #1081: PR#1169

4

A: Update RA-1 Ch02: Requirements

Align RM and RA-1 Requirements.

Added to Backlog as RM completion TBD

Ch02:  A document provided to RM WSLs with a request for clean-up RM reqts (2020-01-27)

A: Create Traceability entries in RA-1 Ch02. If Gaps and variances assign for completion/remediation

7 Feb 2020

Ch02: (2020-02-07) Completed 2.3.1 - 2.3.5 (Scope of Baldy release)

5

A: Finalise RA-1 Ch03: NFVI + VIM Architecture

Ch03: 

Topology: Cover DC/Edge and SLA driven.

Ch03: Issue #638 (content developed to be added to Github)

Review Networking Section and suggest Improvements

Ch03: Move to RM?

Create Traceability entries in RA-1 Ch02. If Gaps and variances assign for completion/remediation

7 Feb 2020

Ch03: Done

Remove 3.6 as Traceability is in Ch02.

7 Feb 2020

Done

6

A: Finalise Ch04: NFVI + VIM Component Level Architecture

Ch04: 

Add Hardware acceleration

10 Feb 2020

Ch04: Cyborg Added

Create Traceability entries in RA-1 Ch02. If Gaps and variances assign for completion/remediation

(7 Feb 2020)

Ch04: PR #1046 Completed

Remove 4.7 as Traceability is in Ch02

(14 Feb 2020)

Ch04: completed as part of PR #1065

7

A: Finalise RA-1 Ch05: APIs and Interfaces

12 Feb 2020

Ch05: completed

Qualify APIs that are actually utilised.

12 Feb 2020

Ch05: Already mentioned APIs and Microversion capabilities that are required

Add explanation on micro-versions

10 Feb 2020

Ch05: PR#1006 completed

Create Traceability entries in RA-1 Ch02. If Gaps and variances assign for completion/remediation

(7 Feb 2020)

Ch05: PR #1046 Completed

8

B: Create content for RA-1 Ch06: Security: Create security requirements list

Ch06: Created RM Ch07 Consolidated Security Requirements++: currently under review

Content being added – based on RM Ch07 requirements

Create Traceability entries in RA-1 Ch02. If Gaps and variances assign for completion/remediation

Ch06:

9

B: Create updated ToC and Content for RA-1 Ch07: Operations and Life Cycle Management

March 31, 2020

Ch07: Content Created

Develop content including Logging and Monitoring

March 31, 2020

Ch07: LMA content added; under review

Create Traceability entries in RA-1 Ch02. If Gaps and variances assign for completion/remediation

10

B: Update RA-1 Ch08: Gaps, Innovation, and Development

Ch08: Done

Adopt Open Source (Tungsten Fabric) SDN APIs, map back to Requirements and push for adoption by OSTK as a Neutron extension

Ch08: now part of RM Networking FG

Discovery: review ONAP A&AI. Support for specific use cases: packet acceleration (DPDK, SR-IOV, …)

Ch08:

Capture Prague Etherpad Items

1

A: RI-1 cleanup (ch content complete 80%, issue closure)

2

C: Resolve Continuous Software Deployment Errors

(MikeF add) - Not clear what that is. → MikeF:  Automatic deployment of OpenStack via the CICD Pipeline using AirShip fails.  Manual intervention is needed to resolve issues with erroneous port 80 references, incorrect NOVA versions, and end-point URLs which do not work.  (to name a few).  

3

C: Document & Perform Repeatable CICD Deployment

(MikeF add) - some of it need to be documented in cookbook and some of it needs to be taken care of by OPNFV.

4

A: Document how to Perform Repeatable Compliance Validations (post deployment)

(MikeF add) - some of it need to be documented in cookbook and some of it needs to be taken care of in OPNFV.

5

C: Close Gaps in Cookbook

[RC1 Ch9 - Snezka F2F] RC Cookbook Enhancements #945 

[RI1 Ch07] User Manual initial content #408

User-Execution

• Common Failure codes, description, and resolutions

• Test Framework Clean-Up Utility, Process, and Support Expectations

Process / Version Mgmt

• Process for version control

• Process for bug fixes and patches

• Containers Tagged

• Playbooks grab the tagged version

(MikeF add)

6

C: Conduct Friendly Cookbook Trial

(MikeF add) - That is not for RI team to worry about.  → MikeF:  How/who will own this item as there needs to be a friendly trial of the cookbook with feedback/improvement?  This is about lab procurement, h/w and s/w validations, software installs, etc.  All pertaining to RI WS. 

Rabi: @Michael Fix i will send you an invite to the weekly adoption meeting where we are getting those vendors for the trials. I think it should be handled in there and I think you should get involved as per your role in RI & OPNFV

7

A: Select Vendor Candidates for RI installs

(MikeF add) - That is not for RI team to worry about.  → MikeF:  Can RI WS handle the handoff to the appropriate WS?  The ask is for parallel/multiple RI installs.  Who will identify & support these candidates?

8