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
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.
Clarify the term CNF across the community and standardise it addressing the below
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
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
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
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.
Autoscaling, auto-healing - Consider ONAP Control Loop (DCAE, Policy) -
Feedback on the presentation: Add AAI, Modeling; Control Loops etc.
April 9th, 2020
Discussions about 5G PPP - XMEC (Extended Mobile Edge Compution) - open source software stack, facilitating automated analytics-based deployment of MTC-related and utility-centric VNFs.
#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
- 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':
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-Aligned CNF Support - Honolulu 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)
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.
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
Re-discuss on the open items and check their current status.
(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...??
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.
How standards written by SDOs are considered as part of the requirements gathering? If any discrepency then let's bring them to the CNTT.
Readout from CNF Modeling/Inventory
Healthcheck was presented during the last Friday call on 8/7
Friday's call will be organized on a bi-weekly basis i.e. 8/14, 8/28
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.
August 27th , 2020 at 1pm UTC
Agenda
Introduction highlighting ONAP value proposition (Srini, Alla)
Where are we today (Catherine, Timo)
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?)
New proposal
ONAP Value proposition (Alla, Srini) - 1 slide (5 mins) -9/3: In progress
The day before your recording, Intrado will send you a detailed calendar invite, which will include a phone number to dial in to establish your phone-bridge link and a URL to log-in to the platform itself. Please note, you will need to log-in to the system and dial into the phone bridge so we can ensure all connections work. Slides and any videos will already be uploaded before your session so no time is wasted at the beginning of your recording session.
Alternative: Any speakers wish to record their sessions themselves, Intrado accepts MP4 files, H.264 codec that are less than 4GB, and in 16:9 format and we will need to receive these by Friday, September 18. Please let us know immediately if you prefer this option.
ONES Presentation - review of the presentation
Sept 3rd , 2020 at 1pm UTC
ONES slides - See updates above.
XGVela update from Seshu -
Scope is being defined. Seshu is making sure ONAP is in the picture. No input required from our community right now.
Seshu will provide a readout in a few weeks
Friday XGVela calls move to bi-weekly.
XGVela reached out to Dish Networks and Rakuten Mobile.
ETSI-Aligned Orchestration & Onboarding (see above presentation) - Byung-Woo Jun and Seshu Kumar Mudiganti will fill the table entry based on use case analysis (REQ-334 extension)
Continuity of Guilin requirement - REQ-341 - Seshu Kumar Mudiganti will fill the table entry
Any new requirements? (deadline for new requirements is October 12th 2020)
Invite a rep from Aarna to share their experience from building the ONES 5G cloud-native demo - Seshu Kumar Mudiganti will reach out to Amar Kapadia.
Feature candidate - Auto discovery of K8S clusters - Kamel Idir will discuss with Seshu Kumar Mudiganti to better explain the expectations.
We should reach out to the requirements subcommittee (Alla Goldner) to see if we need to provide them with any input. (Catherine Lefevre reached out to Alla
SDC is short on developers - There is a need for support from community members - Looking for a developer with some SDC expertise.
Short term - urgent need for someone to support the current release - Catherine Lefevre will raise this with the TSC.
This is a long term task. New developers could be groomed for the coming releases. Lukasz Rajewski and Seshu Kumar Mudiganti will refine the ask to help "sell" this inside member companies.
Get confirmation from Byung-Woo Jun and Fernando Oliveira about Fall Event - Confirmed. Fred will present during the CNF requirements session on Wednesday Oct-14th 11:30AM EDT.
Presenting CNF work to ETSI - Scheduled for next week Wednesday 7:30AM CDT. The ETSI IFA workgroup is requesting to have the slides in advance.
Date: October 14, 2020 (IFA WG meeting #212)
Time: 14:30-17:00 CEST; at the beginning of IFA WG session.
Scope: Information sharing on ONAP-ETSI NFV alignment on FEAT017 (Cloud-Native VNFs and Container Infrastructure management). ONAP-ETSI alignment project will be sharing their upcoming Honolulu Release requirements and priority. IFA WG will be sharing their FEAT017 specifications update and timeline. Also, there will be some discussion on Stage 3 work and timeline of SOL WG.
Question: How can a software vendor decide which "path" to use for CNF orchestration - The ETSI path and the existing SO path? A: There will be a translation between the formats. There is an attempt to align the model between the two paths.
The following subcommittees will start to adress this questio:
Andy Mayer - Resource Call on Monday, 9am EST, 4pm CEST ; 1pm UTC
One area for potential re-use is CNF packaging - ETSI Stage 3 work not started yet. ONAP packaging is aligned with SOL004 so that could be a good start
Helm charts - Two types of Helm charts in ONAP - ETSI and SO. This is another area for collaboration, starting with identifying commonalities. Comment by Seshu Kumar Mudiganti - ONAP will not change Helm charts and will use native Helm charts.
Next steps - keep both groups informed. As new milestones are reached, meeting could be set up to share information.
Satoshi Fujii- Present proposed contributions from Fujitsu
No CNF Call on November 26th, 2020
Dec 3rd , 2020 at 15:30 UTC
Identify Blog highlights content to entertain our CNF activities
Team is working on the Guilin release announcement (Messaging)
Could reach out to Brandon to propose for a publication after the internal discussion and review point ??
Pending items for the Guilin and beyond w.r.t to the CNFO
Implementation is 80% completed and planning to complete it will be for the Guilin Maintenance Release (cnf-adapter-1.7.11)
Honolulu the plan is to stabilize the SDC open issues
The AAI changes will be taken up as-is needed (Stretchy Goal), alignment with the ETSI.
health check flow will be worked up on.
SO changes will be only after the backlog issues are fixed.
The key target is the Day 2
Working with the current c(v)FW for the time being, (5G core NSSMF for the test only)
also working o a new usecase with the help of other experts with the experts from ONAP community (Mavenir is expected to help on this).
Ranny Haiby to check internal team to bring a new usecase / functional requirement to support the helm chart support (this needs to be also taken up with the integration of the current moving parts)..
ETSI CNF implementation is takin the IM form the IFA and working on it as a release draft (Planned to be part of the Honolulu)
Mapping the data model with the internal data model
The changes are planned to e reviewed in the next week beginning.
The next step is to come up with the prototype on IFA 11 changes and test it for the basic LCM operations
Working on the SOL group to start he 4.1.1 (VNF spec), with the expectation to come with the draft with a period of 3 to 6 months
ETSI is vFW based usecase as an example csar intended to validate the cnf flows in the ETSI SDO.
CNCF launched the CNF work group -
Key is to discuss Best practices under the CNF (docs / programs / testing / conformance)
(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.orgfollowing 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-Aligned CNF Support - Honolulu 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
(Catherine/Sylvain) Consolidation our message about ONAP Role - should be linked to our ONAP Response to CNCF TUG Lead. Ranny agreed to be our CNCF ONAP liason
