You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 204 Next »

Meetings: 

Mailing List:  (Groups.io)

Calendar:  (Groups.io)

Recordings

Thursdays, 13:00 to 14:00 UTC 
https://zoom.us/j/219945081 

Meeting ID: 219 945 081
Find your local number: https://zoom.us/u/aPnoqYQZN

onap-cnf-taskforce@lists.onap.org

List URL: https://lists.onap.org/g/onap-cnf-taskforce 
Moderators: https://lists.onap.org/g/onap-cnf-taskforce/message/11
Hashtag: #cnf

https://lists.onap.org/g/onap-tsc/calendar

Note: Uses the TSC calendar 

CNF-Taskforce Recordings

ONAP Cloud Native Journey

Plan and Next Steps

  • Align ONAP Community on its role and relationship to the Cloud Native ecosystem
    • TSC Task force initiated to define on ONAP’s CNF strategy including

  #1 What benefits ONAP itself gained by going cloud native

  #2 How we want ONAP to enable CNFs (hybrid, ONAP Lite)

  #3 What ONAP's value proposition is in the overall LFN family (ONAP/CNTT/OPNFV etc.

  • Include “ONAP-CNCF” to the CNCF Cloud Native Interactive Landscape.
    • Discussion being kick-off with LF (Arpit Joshipura)
  • Promote ONAP’s CNF strategy through LF Events (ONES, DDF etc.) and press release(s)
    • CFP submitted for ONES NA
  • First implementation of ONAP CNCF as part of the Guilin Release (Nov 2020?)

OVP / Cloud Native Journey

2/12 (presented by Arpit): VNF-CNF OVP - 2 key slides.pptx

2/27 (updated deck with Ciaran, Ranny, Seshu, Timo, Alla): VNF-CNF OVP - 2 key slides_V3.pptx

2/28: (updated deck - orange box is now generic - was previously missing SDC (smile)): VNF-CNF OVP - 2 key slides_V4

3/3: (updated with CNF Task Force): VNF-CNF OVP - 2 key slides_V5

Role of ONAP

Role of ONAP (which is a central automation platform) across multiple Clouds & Edges.


  1. Distributed Applications: Telco world is known to have requirement to support ‘network services’ whose components (VNFs today) spread across multiple computing regions (Openstack based regions).  Hence, the need for central orchestrator that orchestrates various VNFs of the network service in multiple openstack based computing regions.  With edge-computing,  even normal applications are becoming distributed, where a few microservices of the application are deployed across multiple edges & a few in network edges and public clouds. Essentially, applications are becoming more like network services.
  2. Convergence of applications and network functions due to Edges : Edge world can’t afford to have two computing environments – One for normal applications and another one for network functions. This is due to resource constraints. Since many edge-computing efforts in Industry adopted K8s, it is natural to think about supporting network functions and use same K8s cluster for both. It appears that a few MEC applications even require some network functions to be deployed along with them (Example include MEC applications with network security functions).
  3. Network function deployments and life cycle management are more complex than the applications due to need for supporting multiple interfaces, provider networks,  service function chaining. ONAP is solving many of these challenges.
  4. Support for Multiple Cloud technologies :  Supporting legacy Openstack deployments with greenfield  K8s deployments are needed.  ONAP solves these multi-cloud challenges.
  5. Support for Telco infrastructure such as OSS/BSS – ONAP is already in the path to support various MEF standards on its north side to support standardization between OSS/BSS and Orchestrators.
  6. Support for monitoring of distributed applications and closed loops :  Monitoring distributed applications that are deployed across multiple edges/clouds is complex.  There is need for showing the comprehensive status at the application level instead of at each resource level.  ONAP monitors the services/distributed-apps and not only provides simpler view of the status, but also can run through various analytics engines and even act on the actionable insights.

Note:  ONAP4K8s is a profile of ONAP for Enterprise/IOT (Including Private-5G/LTE)  market that have requirement of deploying CNFs/VNFs along with normal applications in multiple K8s based clusters.

In addition, we believe that ONAP can provide additional values as follows:

#1 NF Control Loop

#2 NF Common Inventory

#3 NF Data collection and analytics

#4 Support of PNFs

#5 Cover the design of services as well as the orchestration of services, design of control loops

#6 Play a role in terms of standardizations (TMForum, ETSI ZSM, MEC etc.) through our ONAP Technical Coordinators

To recap, we can provide significant automation values to handle applications on top of the K8S environment.

Areas of Focus

#1 ONAP 'Light" Weight - Review our current ONAP projects (see Lifecycle review led by Jason/Chaker)

#2 ONAP4K8S, Containerization 

#3 Identify ONAP Requirements +  to support CNFs for Guilin

#4 E2E Integration (OVP)

#5 VNFREQS => CNFSREQS - Certification CNF requirements - need to align with the ONAP Architcture + ONAP SECCOM regarding Cloud Native.

 

Features/Capabilities - How We complement each other to support CNF?

Features/CapabilitiesK8S EnvironmentCNTT/Arch Ref.2  ONAP (Today)

 ONAP CNCF

Comments 

CNF Scalability

From an Orchestration perspective: Cluster Autoscaler, HPA and VPA

Handling within its own cluster





From an Automation, Control Loop (CL) perspective


OOF, SO, Multi-Cloud



CL (DCAE, Policy, CLAMP + Triggered Action)

Adding value: Handling multiple K8S, Clusters

See "SO enhancements to support CNF" presentation (3/17)

Not ONAP Scalability itself otherwise MUSIC, OOM (Container Orchestration)

CNF Resiliency

From an Orchestration perspective: K8S Services




From an Automation, Control Loop (CL) perspective


OOF, MSO, Multi-Cloud



CL (DCAE, Policy, CLAMP + Triggered Action)

See "SO enhancements to support CNF" presentation (3/17)

Not ONAP Resiliency itself otherwise MUSIC, OOM (Container Orchestration)
 CNF AvailabilityPublic Cloud is currently offering <99.999

Opportunity for ONAPNot ONAP availability itself otherwise 99.9999+ built inside ONAP 

Onboarding/Provisioning 

Design Time



 SDC/VID/CDS


 SDC/CDSONAP Portal/UUI to be re-assessed

Secured service-to-service communication

Additional SW to be uploaded on top of K8S:

Linkerd, ISTIO, 


AAF

(VNFs only)

Integrate our ONAP Apps to Service Mesh (question) while keeping AAF as optional

Service Mesh between ONAP/CNFs

Do we provide any certificate or shall we rely on a Certification Manager?

Logging

Stackdriver Logging

Elasticsearch

Fluentd


Logging/Pomba

EELF/ELK



Centralization of Logging - ONAP feature or external system to ONAP?

Dashboard


OOM - Consul

Observability

Events, Alarms, Analytics

Prometheus - https://prometheus.io/

Open-source systems monitoring and alerting toolkit

Jaeger - https://www.jaegertracing.io/

As on-the-ground microservice practitioners are quickly realizing, the majority of operational problems that arise when moving to a distributed architecture are ultimately grounded in two areas: networking and observability. It is simply an orders of magnitude larger problem to network and debug a set of intertwined distributed services versus a single monolithic application.

based on grafana technologies (UI part) 


DCAE

Specific VES

Integration with Promotheus and Grafana technologies (UI) as POC by AT&T

-Check the CNF Conformance to understand what are the requirements

-Shall we integrate one of the open sources to DCAE (like we did with PNDA) or shall we create DCAE CNCF version?



Inventory

CNFs Storage

  •  Secured mechanism to store/inject CNF images (Extension to Artifactory - Separate virtual repos)

AAI

CNF Inventory

A&AI could also be used for Control Loop (future feature candidate?) 

Under investigation
 Security

 K8S Airbag, kubectl


SECCOM

CNF Security Requirements 

Ingress Controllers

How to address Networking back to provider network (question)

Expansion of Container Security for K8S (out of scope from SECCOM?)

 Tracing

OpenTelemetry provides a single set of APIs, libraries, agents, and collector services to capture distributed traces and metrics from your application. You can analyze them using Prometheus, Jaeger, and other observability tools. - https://opentelemetry.io/


DCAE DCAE - Telemetry under assessment

CNF Compliance:

The CNF supports OpenTelemetry-compatible tracing
– Does the CNF generate Open Telemetry compliant data?
– Is there traffic to Jaeger? 

 Performance




 Network Interfaces

Dual Stack Network:

  •  IPv4 K8s cluster with IPv4 pods and services 
  •  IPv6 (question)

SDNC/APPC/CCSDK (CDS)Re-use K8S & existing infra (question)

We need to understand what role does ONAP play for CNF networking. Is it exposed to CNI plugin choice? Multiple interface containers? etc.

  • DPDK (question)
  • SRIOV (question)


Adapt our CI/CD - Toolchain


E2E Testing - Working jointly under OVP PH2 (OPNFV, CNTT, VTP, ONAP/VVP/VNFSDK)


Where are we on the CNCF Trail Journey?

Features/CapabilitiesONAPComments 
Step #1 Containerization

 Step #2 CI/CD










CNF Deployment 

#1 Workload Considerations - POD and Host Strategies

  • Separate POD 
  • Shared POD
  • Shared Host (with VNFs)

#2 HW Requirements

  • Persistency
  • Performance Optimization (Compute, Storage) - Generic or Special HW?
  • Multi-Tenancy @Storage, Networking, Resource maangement
  • Security - check with SECCOM

#3 Testing Considerations

  • Canary Testing - Rolling upgrades
  • Chaos Monkey Testing
  • Performance

Pre-requisite(s)

Requirements 

We need to identify non functional reqs for ONAP Itself and for ONAP to orchestrate CNFS 
(Rework the below reqs into these two categories)

#1 Need to deploy ONAP/ONAP CNCF on component basis not as a whole
#2 Move to Service Mesh
#3 Optimization of DB - leverage some storage, DB capabilities offered by existing Cloud solution
#4 Scalability, Reliability based on K8S services (?). 
   Not replacing K8S but built on top of K8S.
#5 API between components

Later on, how our "ONAP CNCF" will look like to support CNFs

First Use Case(s) for Guilin (Initial proposals)

Links

https://github.com/kubernetes-sigs/kubefed -- K8S across multiple clusters

https://pivotal.io/cloud-native 
https://techbeacon.com/app-dev-testing/5-critical-elements-building-next-generation-cloud-native-apps
https://medium.com/faun/15-best-practices-to-design-cloud-native-modern-applications-a2aa9f19cda0
https://hackernoon.com/writing-sky-high-applications-a-guide-to-cloud-native-development-9f3c1c020471

https://codilime.com/vnfs-in-cnfs/

https://www.cisco.com/c/en/us/solutions/service-provider/industry/cable/cloud-native-network-functions.html#~introduction

https://wiki.lfnetworking.org/display/LN/OVP+2.0+Boot+Strap

Meeting Notes

Previous Meeting Notes

Srinivasa Addepalli
As part of ONAP4K8s, we have done some work in R4 and we are working ìDistributed Application Orchestrationî in R6.  
In R4, we showcased deploying CNFs & VNFs (firewall use case)  and normal applications on the same cluster from ONAP.  
Also,  Akraino ICN project is bundling ONAP4K8s. 
Glad to see wider interest in deploying CNFs from ONAP in remote K8s clusters.  

Linked to the edge computing, K8S deployment/containerization, 5G - discussion under architecture team is ongoing
Prototype under Multicloud project- develop some plug-ins to prove network functions/containerization

What type of orchestrator changes do we need?

Links:
https://wiki.onap.org/display/DW/Multi+Cluster+Application+Scheduler
https://wiki.onap.org/display/DW/ONAP4K8S+profile

Ranny Haiby
#1 Define benefits of ONAP for CNFs - what are we trying to solve with CNFs?
 i.e. Control Loops, Provisioning/Modeling, etc
#2 Scalability/Reliability - deep dive to be truly K8S oriented

Ciaran Johnston
Do we want to be truly Cloud Native? yes but it requires baby steps stating with Cloud native development principles 
How can we enable as part of our development practices
   i.e. DevOps approach - mS 
   The second approach is the preference

Strategy is to demonstrate how ONAP could be "complementary" to other open source initiatives.

Seshu Kumar Mudiganti
#1 Discussion of two steps 
1∞ Identify ONAP components (MVP) to support CNFs
2∞ Transform other components (still maintained) to support also K8S deployment
#2 Is there any other solution than K8S (i.e. Red Hat Openshift?)
https://blog.openshift.com/whats-the-difference-between-openshift-and-kubernetes/
https://hackernoon.com/kubernetes-vs-openshift-a-detailed-comparison-7r3z53zlv

Clarify the term CNF across the community and standardise it addressing the below ONAPARC-552 - Getting issue details... STATUS

Timo Perala
#1 Understand the K8S Roadmap to understand what are the incoming features in the future
   so we can identify where ONAP can play a role and then define 'ONAP Lite'
#2 Follow-up with Sylvain (CNCF TCC Lead)

Alla Goldner
Suggestion to create 3 blueprints
#1 ONAP lite (just CNFs)
#2 ONAP hybrid (supporting all - as a transition period or will remain later to support PNFs at least)
#3 ONAP All (VNFs, PNFs, CNFs)
=> Key word: we should be able to deploy the ONAP/ONAP lite components that carrier/vendor just need

March 3rd, 2020

       

March 10th, 2020

March 12th, 2020

  •  Feedback from OVP PH2 meeting: https://wiki.lfnetworking.org/display/LN/2020-03-09+OVP+2.0+Meeting+notes
  •  Do we need to extend our ONAP VNFReqs to consider CNF Reqs or shall we suggest a "LFN CNF Reqs" Board or will it be driven by CNCF?
    •  Need to connect with CNCF to avoid duplicated effort, divergent effort
    •  Architecture, Modeling, Security reqs will feed VNFReqs+  to define what it is requested to onboard CNFs on ONAP — Shall we draft a Diagram flow?
    •  Need also to consider CNF Security reqs from SECCOM
    •  Need to consider the Architecture, Requirement Subcommittees' perspectives
    •  ETSI Activities to define packages - candidate for the Guilin Release ETSI CNF Support
      • ESTI reqs/packages availability - End of Q4
      • Need to define an intermediate (Helm v3.0, TOSCA, HEAT) then try to push back our findings to ESTI
    • Hydrid approach (supporting all together - CNFs, VNFs, PNFs) - need to address the network part ONAP SO ETSI-Aligned Hierarchical Orchestration
    • Migration Strategy from Openstack (VNFs) to K8S (CNFs)
      •  New artifacts for containers
      •  New packages while offering the same functionality than formerly VNFs
      •  Define the mapping  (Helm v3.0, TOSCA, HEAT)
  • Review "Features/Capabilities - How We complement each other?"

March 13th, 2020

  •  Review "Features/Capabilities - How We complement each other?"
    • Observability/Events/Alarms/Analytics
    • Tracing/Telemetry

March 17th, 2020

  •  Review "Features/Capabilities - How We complement each other?"
    • Security
    • Network Services
    • Adapt our CI/CD
  • "SO enhancements to support CNF" presentation (3/17) by Seshu Kumar Mudiganti
    • Discussion K8S orchestrator vs ONAP Orchestrator adding values to support CNF i.e. Inventory i.e. AAI, Operational cockpit (CDS), Optmization (OOF) and Control Loop (DCAE/CLAMP/Policy) 

   

March 19th, 2020

  •  Discussion about the K8S adapter used by different ONAP components - MultiCloud, OpenStack, SO, etc. => Need guidelines from the Architecture Subcommittee
    •  Shall we review the MultiCloud architecture in order to consider it as the layer to trigger K8S Adapter? Need to review MC as ONAP MVP?
    •  Short term: Bypassing MC for Guilin?  How shall we get back to MC later?
    •  Opportunity to review the different APIs (14?) used for Orchestration
    •  Suggestion from Damian Nowak to explore what it is offered by ETSI CNF Support, see feedback provided by Fernando Oliveira on 3/12
    •  OPNFV update -Deploy directly on K8S from MetaSwitch (CNF ClearWater IMS image),  not from a Helm package 
  • Discussions about First Use Cases for Guilin (see above section)

The different use cases are highlighting a similar architecture i.e. (VID)/SDC/SO/MC etc being involved in the call flows. Additional guidelines are required by the Architecture Subcommittee

#1 CNF ClearWater IMS

#2 cFW Bin Yang

#3 ETSI CNF Support

March 26th, 2020

  • OVP PH2 - Workstream activities - https://wiki.lfnetworking.org/display/LN/OVP+2.0+Boot+Strap
    •  Call for ONAP Volunteers to join the Workstream
    •  Discussion about what ONAP cares today if we onboard CNF or VNF
      • Packaging/artefacts are different
      • Heat & TOSCA are handled differently on ONAP
      • Role of MVP components in ONAP migh stay the same i.e. Onboarding/Orchestration flow (SDC, SO, AAI etc) but some adjustments will be required
      • Modeling area to be investigated to identify the changes though an existing use case i.e. cFW 
  • Initial Security CNF thoughts presented by Krzysztof Opasiak  
    • Communication: VNFs=HTTPS; CNF=K8S Airbag, kubectl
      • Need to get feedback from Ops reqs from Carriers (HTTPS still used for CNF or other alternatives)
    •  VNF Security reqs focussing on secured communications => Support of Service Mesh for CNF i.e. Service Mesh between ONAP/CNFs
      • CNF LCM (Life Cycle Management) APPC?
      • Extend the investogation to the other ONAP Components
      • Identify way to communicate between CNFs/VNFs
      • No breach on CNF data stored in AAI based on what it transfers through K8S
  • Any feedback regarding SO presentation (from Seshu Kumar Mudiganti ) &  cFW presentation (from Bin Yang )

April 2nd, 2020

  • Initial Modeling thoughts based on cFW presented by Andy Mayer
  • Does the Use Case model still apply?  Use Case Team has been replaced by 'Requirements' Team
  • Call Flows associated to the Initial Use cases are required to progress from a Modeling perspective
  • For the ETSI-Alignment CNF support, the onboarding of ETSI CNF package to SDC needs to follow the coming ETSI specifications such as IFA 029 and IFA 040. This would impact on the modeling changes
  • To SDC. Also we are defining CNF distribution and orchestration path based on the current ETSI specification assumption, which is not finalized yet.
  • AAI modeling impact to handle CNF instances 

 

Autoscaling, auto-healing - Consider ONAP Control Loop (DCAE, Policy) - 

Feedback on the presentation: Add AAI, Modeling; Control Loops etc.

April 9th, 2020

April 16th, 2020

#1 for certificates, we use "cert-manager", used by everybody but us. It can deliver PEM in standard but also JKS and PKCS12 format in experimental (https://cert-manager.io/docs/release-notes/release-notes-0.14/#experimental-bundle-format-support-jks-and-pkcs-12)

#2 for "RBAC", let's put hard work on the two components "using" it -- DMaaP and Portal.  In order to move to keycloak, which is compatible with ISTIO but can live without it. Keycload is a OpenID implementation meaning it's using standard stuff

https://github.com/jetstack/cert-manager/

https://www.keycloak.org/


April 22nd, 2020 at 2pm UTC

April 30th, 2020 at 3.30pm UTC

May 14th, 2020 at 3.30pm UTC

New Schedule? 1h before TSC meeting except when we will change the clocks => 1pm UTC every Thursday

#1 Alignment on Cloud Native Definition

- Presentation for Cloud Native definition
Why don’t we just reference CNCF ?
• Feeling that it was not understood/completed the same way by carriers and 3rd parties
• Remove ‘aligned with CNCF/TUG…’ as duplication
Containers are ‘one way’ of doing cloud native – is it too specific ?
• CNCF made a decision to be not specific.
• Should ONAP be more specific and have a common understanding from all parties
As a vendor, I prefer having a single source for cloud native requirements ?
• We’re not defining new requirements – this is a set of definition over the very broad set of what CNCF has proposed
Target is to define what ONAP understand from these CNCF requirements
We do not agree on what CNF means ?
• CNF in ONAP means Container Network Function : one application of that is Cloud Native use case
Agree on the purpose of these principles
• Build a common understanding
• CNCF cloud native principles are very generic
o CNCF say things are immutable even if configuration changes
But CNF this is not true, Container configuration changes has impact
o Applications don’t have to be aware of networking
 -In Our case ONAP , CNF are dealing with Network so this principle does not apply
Bring added value
Maybe we should rebrand : CNF expectations from ONAP community
Or identify Gaps that ONAP should fill up ?

- Do we need to define CNF requirements ? like we do VNF reqs but where do we define them ?
o CNCF TUG is defining that to some extend
- Why is there multiple definition for CNF ?


Ranny Haiby - I have added a slide describing the two types of CNFs - 'containerized' and 'Cloud Native':

Cloud Native Definition_TF_With_Containerized.pptx


#2 CNF Guilin Requirements:

  • ETSI CNF (Fred/Byung)
  • CNF Orchestration (Seshu, Lukasz, Srini) including K8S plug-in - starting point
    • cFW (from Intel POC)
    • any CNF 5G Core - not yet any open source CNF available in this area except "free5GC" from Akraino
    • open for other proposal (Ranny?) (smile)
  • Productization of CNF Onboarding (Sylvain) 
    • extract from OOM/Integration/Security requirements
    • monitor the status of CNF instantiation

May 21st, 2020 at 1pm UTC

  • Any feedback regarding the slide added by Ranny Haiby  
    •   (Fernando Oliveira ) :  What is the letter CN is intended in this task force (Cloud native vs Container Network functions) 
      • (  Ranny Haiby ) Task force could look at both the approaches and find it as a place to support both
      • ( Chaker Al-Hakim  We can start from Container N/w and then add the other aspect as we move forward, LF Edge is also trying to define the CNCF too.
      • Better to get the alignment at the LFN level to have the common terminology across board
      • (Seshu Kumar Mudiganti ) ONAP itself is currently deployed as a (semi) CNF over OOM platform using the K8s
  • Aarna Network is pitched in to provide a helping hand in the (R7) Guilin  Release to support the effort (Amar Kapadia)
  • Ranny Haiby : Victor would be coming up withe helm charts that could be refereed to by the June event. 
  • CNF Orchestration (Seshu) updates   Seshu Kumar Mudiganti

May 28th, 2020 at 1pm UTC

  •  Review of Guilin CNFs Requirements before TSC Prioritization kick-off
    • REQ-341 - Getting issue details... STATUS
    • REQ-339 - Getting issue details... STATUS

June 4th, 2020 at 1pm UTC

  •  Feedback from OVP PH2 - Ryan Hallahan, Ranny Haiby, Trevor Lovett
    • Latest discussions - any update from June 1st, 2020 that we should consider as part of this ONAP Task Force? Main discussions about CNCF conformance.
    • Any update about REQ-339 - Getting issue details... STATUS - Probably not high priority for the Guilin Release - waiting feedback from user-67d6f
    • Workstream 7 - expectation to provide a bi-weekly update
  • Any update from Ranny Haiby , Alla Goldner regarding how to shift from POC to Release Requirements? (Ongoing)
    •  Service Mesh POC including documentation and results while providing awareness through the different forums.
  • Creation of a new CNF sub taskforce focusing on Modeling/Inventory led by Seshu Kumar Mudiganti , Andy Mayer + AAI SMEs

June 11th, 2020 at 1pm UTC

June 18th, 2020 at 1pm UTC

  • No ONAP CNF meeting on June 25th, 2020 (LFN DDF Virtual Event)
  • Any feedback from OVP PH2?
    •  WS07 was presented (except CNF Security)
    •  OVP Validation (WS05) - ONAP (SO, VF-C teams) will initiate the testing (provisioning), the ONAP requirements will write the tests based on functional reqs/use cases.
    •  CNF requirements to be provided by ONAP community to be used for the E2E CNF Testing. Need to identify people from ONAP Community
    •  Need to consider from ETSI perspectives as well
    •  OVP PH2 is about E2E Testing/CNF Badging - suggestion is to remove WS07 and to maintain WS05 to highlight our ONAP contribution (how to use ONAP + ONAP testing tools)
    •  Inputs can be provided to WS01, WS02 in terms of requirements
  •  CNF Modeling/Inventory
    •  ETSI CNF Modeling effort will contribute to this Task force. Separation between ONAP (A&AI/Modeling incl. ETSI CNF) and CNCF from an Inventory perspective => main topic on June 19th at 12.30pm UTC - https://zoom.us/j/98408415989. Opportunity to procvide close loop feedback to ETSI
    •  Any Helm Chart information (under finalization) during the DDF event - Date/Time will be confirmed
    • Meeting will be canceled on June 26th
  •  Introduction of technical review/Assessment of K8S plug-in (after Guilin Architecture Review) performed by the ONAP Architecture Subcommittee, identifying any additional ONAP value on top of K8S; considering ETSI CNF Support and how to make workflows for internal and external VNFM as similar as possible.
  • Review on remaining action items

July 2nd, 2020 at 1pm UTC

  • CNF Inventory/Modeling will be canceled on July 3rd, 2020 (US Independence day)
  • Review ONAP contribution to OVP PH2 program
  • CNFO will use the 5G core part of the 5G slicing use case (REQ-341)
  • CNF Inventory/Modeling - presentation planned on July 10th "Reference CNF" by Victor Morales  (Samsung)
  • Control Loop representatives (Pamela Dragosh , Vijay Venkatesh Kumar ) have also joined the CNF Inventory/Modeling Task Force  
  • CNF ETSI Package (ongoing)
  • WS05 will be presented by user-67d6f on July 13th - OVP PH2 meeting
  • OVP PH2 - WS05/WS07 are now combined together including all the ONAP contributions 

July 9th , 2020 at 1pm UTC

  • Checkpoint on WS05 prior OVP PH2 meeting - Kanagaraj could not attend the meeting but Seshu reported he is ready for presenting in the OVP 2.0 on Monday
  • Catherine asked TechM (Milind Jalwadi) to present his PoC to the CNF modeling work group.
  • REQ-381 seems to be ahead of the OVP 2.0 plans. Should be discussed on the coming OVP meeting.
  • We should update the CNF roadmap table on this page.

July 16th , 2020 at 1pm UTC

          Links from June DTF: https://wiki.lfnetworking.org/pages/viewpage.action?pageId=34606297#id-2020JuneVirtualLFNDeveloper&TestingForumTopicProposals-Plenary-PaaSwithXGVela

          and the recording link: https://wiki.lfnetworking.org/download/attachments/40370243/PaaS%20with%20XGVela_%20June%2023%202020.mp4?api=v2

          Additional Material: PaaS with XGVela - v3.pdf, xgvela-20200612.pdf

         url: https://xgvela.org/

July 23rd , 2020 at 1pm UTC

  • Consolidate our inputs to build our ONAP proposition value to collaborate with XGVela Community
    • XGVela Telco PaaS Definition: https://github.com/XGVela/XGVela/blob/master/doc/Telco-PaaS-definition/TelcoPaaSDefChart.md
    • The XGVela meetings are bi-weekly. No meeting this week
    • ONAP as the defacto Open Network Automation platform for VNFs/PNFs supporting 70%+ of Global wireless subscribers and therefore ONAP will play a role as part of XGVela eco-system
      • Orchestration (SO+Controllers)
      • CNF/Control Loop (Inventory)
      • Control Loops mechanisms/Observability (DCAE VES Collectors/Policy + CLAMP)
      • Onboarding (CDS/SDC/VID)
      • Alignment with SDOs i.e. ETSI, MEF, TM Forum
      • Integration with VNFS/CNFS/PNFS → Link with OVP PH2
  • Any Feedback from OVP PH2 Meeting
    •  Presentation made by user-67d6f on 7/13. No preparation expected for the next meeting planned on 7/27
  • Pending results of CNF Inventory/Modeling discussion
    •  Usecases under discussion
    •  Discussions about "Resource status" from K8S - to be continued 
  • No ONAP CNCF TCC candidate - It will be discussed during ONAP TSC today to suggest that this task force is taking over

July 30th , 2020 at 1pm UTC

  1. Re-discuss on the open items and check their current status.
    1. (All) Try to identify where we are on the CNCF Trail Journey - Needs clarification to comment, need to dig into the details of the actual ask...??
  2. Modeling team has started discussing on the usecases w.r.t the healthcheck item, we will present the topic to this group once there is enough material collected.
  3. Zoom details of the XGVela meeting on Friday:   https://zoom.us/j/951 3778 5359 @ UTC 13:00
    1. There is some confusion around the actual meeting time and bridge? (https://lists.xgvela.org/calendar)

August 6th , 2020 at 1pm UTC

  • CNTT Survey: https://forms.gle/wwyyam8aPGNYRTv79  => Survey for carriers/vendors. Will be discussed during ONAP TSC (8/6)
  • Any update from CNF Modeling/Inventory task force
    •  Trying to get feedback on 2 use cases ) 'Healthcheck' path to be discussed on August 7th and presented on ONAP CNF call on August 13th, 2020
  • ONES NA panel discussion topic (prep on presentation) - https://ones2020.sched.com/event/bWQk/panel-discussion-onap-and-cloud-native-the-best-of-the-two-worlds-catherine-lefevre-att-alla-goldner-amdocs-srinivasa-addepalli-intel-ranny-haiby-samsung-timo-perala-nokia?iframe=no&w=100%&sidebar=yes&bg=no
  • Presentation sheduled on Tuesday, September 29 • 11:15am - 11:45am EST?
    • Agenda/Items to highlight during this talk (30 mins)
      • Introduction highlighting ONAP value proposition (Catherine, Timo)
      • Where are we today (Catherine?)
      • Link with CNTT/OVP PH2/CNCF - RA chapter 2 (Ranny)
      • Link with SDOs i.e. ESTI (Byung, Fred)
      • What have we implemented so far? (Seshu)
      • Deep Dive on ONAP CNF Orchestration (Seshu, Lukasz)
      • ONAP CNF Roadmap (Merge with the first bullet? Catherine?)
    • Check if any relevant LFN whitepaper, publication should be added at the end of the slides, demonstrating cross-colaborationship
    • Draft to be shared to this forum on August 20th, 2020
    • 1-2 slides per topic
  •  Action Item - Try to identify where we are on the CNCF Trail Journey
    • It is related to our Cloud Native Compliance regarding the picture above i.e. Step #1 Containerization; Step #2 CI/CD; etc.

August 13th , 2020 at 1pm UTC

August 20th , 2020 at 1pm UTC

  • Draft slides presentation for the ONS event - Presenters don't have the exact logistics for this. Who should we send the slides to? When is the pre-recording taking place?
  • Review any input to Google sheet requested by CNTT on 8/20 - Members of the Taskforce are encouraged to join the weekly calls on Tuesdays to get a better understanding on how to contribute (Tuesday 4:00pm UTC /  12:00pm EST, https://matrixx.zoom.us/j/3445145485)
  • XGVela - Seshu is participating in the TSC discussions there and will continue to provide updates. Current status is the XGVela Community is working on proposed integration with ONAP and will share it with us when it is ready.

Action Items (In Progress)

  • Follow-up with Jill to update the panelist since Alla Goldner , Srinivasa Addepalli are no more participating to ONAP CNF Task Force
  • (All): Build an ONAP proposition value to collaborate with XGVela Community
  • (Seshu): Questions for XGVela
    • It would be great to highlight more clearly the purpose of XGVela as a platform to build CNFs and get feedback from 3rd party vendors, who are today already creating CNFS for carriers, to assess the value proposition
    • After the CNF is created via XGVela – can we then deploy the CNF on any Cloud environment without using XGVela at run-time?
    • If we need XGVela then have we performed an analysis to demonstrate the value proposition vs K8S and its ecosystem?
    • Build a slide to highlight how XGVela (i.e. create  CNF) is complementary to ONAP (onboard CNF/orchestrate CNF, etc.) and how it will fit to the CNCF Landscape
  • (Brinda) to follow-up with the ONAP Architecture about his ONAP Cloud Native transformation proposal
  • (All) Try to identify where we are on the CNCF Trail Journey - Needs clarification to comment, need to dig into the details of the actual ask...

  • (Catherine/Sylvain) Consolidation our message about ONAP Role - should be linked to our ONAP Response to CNCF TUG Lead


Action Items (Closed)

  • Follow-up with Jill to update the panelist since Alla Goldner , Srinivasa Addepalli are no more participating to ONAP CNF Task Force
  • ONES CFP - Srinivasa Addepalli will work with Alla Goldner  on the abstract - Key item - "the value that ONAP can bring"
  • Kenny Paulset up doodle pole for meeting cadence and 2 or 3 per week  
  • Check with Kenny, David - how to record our upcomign discussions?
  • Attend the next VNFReQs meeting and to discuss the extension of the team's scope - Trevor Lovett - was discussed during 3/12 - CNF Part 2
  • Follow-up with SECCOM about CNF Security reqs
  • Define our First Use cases and identify CNFs
  • Check with the DCAE project regarding any study about Prometheus, Jaeger + specific VES to support CNFs
  • Seshu Kumar Mudiganti to upload the "SO enhancements to support CNF" presentation 
  • Kenny Paul , create a recording section and add the recordings (2x 3/12, 1x 3/29)
  • Kenny Paul to update the ONAP Calendar - 1 session per week after the TSC Call
  • Sylvain Desbureaux - Start to work on our ONAP response to Dan (CNCF)
  • Any additional volunteer to participate to the OVP PH2 Workstreams
  • Trevor to update the presentation on the WS02 workgreoup and integration insights
  • Andy Mayer Fernando Oliveira  to review ETSI CNF Support
  • ONAP4K8s presentation from Srinivasa Addepalli - made during LFN Event on 4/22
  • Prepare the next OVP PH2 meeting (WS07) for the joint session on April 23rd, 2020 at 1pm UTC Catherine Lefèvre , Seshu Kumar Mudiganti , etc
  • Identify SDC SME to support upcoming session to deep dive SDC

  • (Ranny) - enhance the Cloud Native Definition with "Containterized Network Function" on slide #1 (Done - See Cloud Native Definition_TF_With_Containerized.pptx attached under May 14,2020 meeting)

  • (Catherine) - Ask David to reschedule ONAP CNF Task Force every Thursday at 1pm UTC (until clock changes in the Winter)

  • Investigate how AAF can be optional? Guilin Requirement has been created -  REQ-363 - Getting issue details... STATUS

  • Identify AAI SMEs to support upcoming sessions to deep dive AAI 
  • (Catherine): Follow-up with Trevor Lovett , Ryan Hallahan about WS05
  • (Catherine): Check with Rabi to add WS07 to the main diagram
  • (Catherine): Follow-up with Alla & Requirements subcommittee to get participation to CNF Modeling/Inventory task force
  • (Andy):  Send an invite to onap-tsc, onap-release, onap-discuss, onap-modeling
  • (Fred; Byung; Seshu and Ranny) to update WS07 before OVP PH2 Call
  • (Seshu): Follow-up with user-67d6f concerning WS05 OVP PH2
  • (Seshu): Create a new REQ-394 dedicated to Modeling/Inventory, marked it as POC
  • (Ranny): Discuss with Alla Goldner about how to shift from POC To Release requirements (plan established for Service Mesh)
  • (Ranny) - exploring another CNF that we could use for Guilin. Follow up on free5gc.org following Srinivasa Addepalli's lead.
  • (Seshu) to investigate about "free5GC" open source - agreed to put on hold this action
  •  (Seshu) Connect with Milind Jalwadi regarding the TechM PoC on CNFs
  • (Seshu/Lukasz ): Create the user stories per component for REQ-341
  • (Seshu) Mitigated plan in case of ESR will move to Maintenance, to be documented - Aarna will not be able to work on ESR in Guilin. Workaround - If ESR is not present in Guilin, use Postman instead.
  • Fill in the table - how we complement each other
  • (Chaker): Technical review/Assessment of K8S plug-in (after Guilin Architecture Review) performed by the ONAP Architecture Subcommittee, identifying any additional ONAP value on top of K8S; considering ETSI CNF Support and how to make workflows for internal and external VNFM as similar as possible.
  • Add the actual zoom details of the XGVela in this wiki page (Kenny Paul )
  • (Catherine): Follow-up with Gergely (Nokia) about XGVela - technical discussions on 7/30? No response
  • Kenny - Check if there is any ONS template. The template is being finalized. We can share it as soon as it is complete
  • Check with Ranny Haiby about which topic he would like to participate
  • No labels