Page History

• General open discussion

Anuket

5 sessions today

• Many updates and new subsections will appear in the Reference Model Kali release (Chapter 7).
• Many new requirements on OS SW in RM Ch 7.9, need review and refinement. Security by Design and NIST Zero Trust Architecture introduced.

Security risks of Open Source SW listed, and there are new requirements in the RM, but not yet fully addressed in development or testing (use of trivy and linters now).

• Looking for feedback on Security test tools: OWASP, Clair (gitlab), Trivy, Falco(CNCF). Add kube-monkey.

• Discussing multi- and hybrid cloud requirements and choices as it is driven by edge and other use cases.
• Many Network customers are requiring use of public clouds - brings many issues.
  
  • Who owns and who controls what in the arch.
  • What Open-APIs would help? The current public suppliers/hyperscalers have limited interest.
  • 5G is a use case "we" own.
  • Work to reflect this probably first in an update of RM Ch06, RM Ch08, and the topic requires architecture requirements as well.

For Public clouds:

• Controller suites for Network Services distributed across private and public clouds
  • Challenges: Security, QoS, SLA formulation
• Multi-cloud considerations
  • Operational Model
  • Deployment Model (it can facilitate on how the workloads are distributed and configured)
  • Proposals for multi-cloud support (SDO related)

• Need to choose an OS Release for Lakelse (end of 2021) - Train
• Wallaby has many attractive features, and is a long-term support release.
• Decisions: Several votes for Wallaby in the Lakelse release. RC-1 can track this decision, and follow RA-1 as much as possible.

• Many issues with K8s e2e tests and public tools they use. CNCF has mostly workload tests a few perf tests. CNTT R*2 not much in this area.
• There are four major areas where OS traffic generator/tester capabilities need improvement (slides).
• Comment: testing on public cloud/hyperscaler infrastructure has many unique issues, starting with uncontrolled factors (where the test system is viewed as workload). Common Theme: many customers are asking for deployment in these environments - therefore importance this work is emphasized.

• Workloads expect certain capabilities and performance from the resources that they will execute on.  Workload specific configurations are unmanageable make the resources non-shareable.  A profile is a set of resource configurations that meet needs of a family of workloads (Basic/High-performance), and trying to avoid proliferation of profiles.
• Proposal for Extensions within Profiles allows labeling ( geo, low-latency, etc. ), but the needs seem to be unclear when combined with the author's use-case of "testing to be sure it works" <<< why not just use Basic profile for a limited case like this?
  

ONAP

9 Sessions Today

• Live demo of current POC allowing the user to add custom workflows to ONAP SO

• Latest updated about automation in 3GPP SA5
• Closed Control Loop Automation - ETSI ZSM (Zero-touch network and Service Management), IRTF (Internet Research Task Force), ONAP
• High Level IBN Principles
• TOSCA Control Loop

Parallel work going on in standards, research and open source bodies.

Opportunities to learn from each other.

• Presentation of CNF Model & Package proposals in alignment with ETSI SOL001, SOL004 including ASD (Aplication Service Descriptor) Rationale and objective
• Native CNF Orchestrator Roadmap
• CNF Modeling & Orchetration proposal
  • ASD Walk-through - introduction of the terms such as DeploymentItem and ClusterCapability
  • ETSI aligned modeling changes - updates to VNFD
• Plans for Istanbul and beyond:

•Merging the paths of the Native Helm and ETSI flows
•ASD evolution further, to be able to design services with CNFs
•Runtime model evolution based upon the standard
•...and more

Call to CNF vendor to work with the ONAP Community to onboard, instantiate and orchestrate their CNF.

Call for developers to implement in Jakarta new features:

• CNF Control Loop 
• Integration with XGVela
• Merging Native Helm/ETSI flows
• Entreprise use cases
• etc

• Highlight from Honolulu DCAE transformation

• Reviewed Istanbul scope and design updates on config management and helm templating
• Future roadmap includes MOD helm support and closer alignment with other ONAP projects (CLAMP/POLICY, OOM) and deprecating Cloudify components

• Integration with Prometheus (Istanbul) - 

  enabling certain mS to report metrics - This is being worked at OOM platform level; certain DCAE MS (ves) are being piloted for integration for Istanbul

Challenges: Istanbul scope is relatively big -  need active community support to close on the targetted items.

• Global Requirements and Best practices review for Istanbul
• Reviewed overall improvements in the Honolulu release for both Global Requirements (Python & Java upgrades) and Best Practices (vulnerable package upgrades, CII badging, logging to STDOUT).
• Security logging and access management requirements details

Projects have NEW Global Requirements in Istanbul (vulnerable package upgrades  & CII badging improvement)

Outlined SECCOM and PTL responsibilities for each of the Istanbul Global Requirements. Note that Python upgrade support is available.

Future releases will be affected by the Istanbul design and architecture work to migrate logging, access and identity management to service mesh and open standards.

• Intent-based networks - what has been developed in Honolulu and what is planned for Istanbul to support E2E Slicing and CCVPN usecases