Skip to end of metadata
Go to start of metadata

Meeting Minutes:

Session Access

The zoom links are in Team Up calendar link that is located at 2022 LFN DTF Workshop link.

Topics

Day 1TimeTopicFacilitatorComments

05:00-5:15 AM PST

12:00 - 12:15 UTC

Welcome & Logistics 


Zoom bridge info is in the Team Up Schedule

Day 1 Top Level: 

  • CNF to specific platform 1:1 as a deployment requirement does not and cannot scale.
  • What is the highest priority activity that will reduce the cost due to re-work for end users, platform vendors, workload (CNF) vendors?
  • DTF Welcome.pdf
  • Recording GMT20220314-120713_Recording_2256x1504.mp4

5:15-6:30 AM PST

12:15 - 13:30 UTC

CNF Vendor Input Focus: 
  • As a follow up to the January Workshop, several consecutive focused sessions with CNF vendors to gain an understanding of what the CNF Vendor's requirements are needed from LFN projects and community to support the Vendors' workloads and applications. Need to look at the expectations from both the Vendor needs from the platform and the the expectations that the Vendors workloads need to include for the onboarding/orchestration, on-going supportability and infra platform perspectives.
    • What are the vendors' priorities, objectives and expected outcomes? Improved time to market?  Ability to use a reference architecture to cut development time? Something else?
    • What are the expectations from the projects on what needs to be included in the workloads to be able to use these standard tools and reference implementation infrastructure architectures? 
    • What architectures, requirements, guidelines, and test frameworks or information is needed to achieve these objectives? Are we talking how to provide guidelines and test for them against the platform requirements, or are there specific testing regimes for applications?

6:30-6:45 AM PST

13:30 - 13:45 UTC

Break 1

6:45-8:00 AM PST

13:45 - 15:00 UTC

Moving Forward: Program framework, targeted projects and next stepOlivier Smith
  • Map out CNF Compliance and Testing Framework
    • Interoperability with infra platform
    • Interoperability with orchestration platform
    • Are the testing tools ready?  Are there feature gaps that the test suites do not cover?
    • What are the gaps. and how can the features be added to the test tools?
  • How to map Anuket RA and RC activities to support CNF workloads
    • Is it sufficient to come up with a basic framework to demonstrate functionality on an example RI?
    • Do a discrete set the CNF compliance/platform interop requirements need to be fed directly into Anuket project workstreams?
  • How to map ONAP CNF taskforce activities and any EMCO activities to support CNF workloads

8:00-8:15 AM PST

15:00 - 15:15 UTC

Break 2

8:15-9:30 AM PST

15:15 - 16:30 UTC

Moving Forward: Deep Dive on Interop ChallengesScot Steele

Deep Dive: Interoperability Challenges

  • Part 4: CNF Interoperability Challenges  between workload/platform and orchestrator/workload
    • Networking challenges
      • CNI – is this the only answer?
      • Networking abstraction – how do we push this past the goal line, publish, and test?
      • Layer 4-7 networking (eg., Istio, Envoy)?
    • Data Plane
      • If performance tuning is a source of interop issues, how do we address these?
      • Are data plane issues as opaque to workloads as claimed (should we do a survey, or testing experiment to have non-anecdotal data)?

9:30 AM PST

16:30 UTC

Day 1 Ends

Day 2TimeTopicFacilitatorComments

05:00-5:15 AM PST

12:00 - 12:15 UTC

Welcome &  Logistics

5:15-6:30 AM PST

12:15 - 13:30 UTC

Orchestration: EMCO and ONAP On-boarding and use case alignment
  • EMCO/ONAP Architecture alignment Deep Dive
    • Part 1: On-boarding: Alignment across ONAP and EMCO, taking into account the role played by k8s.
      • Infrastructure→Applications>Onboarding>MANO>Infrastructure (end-to-end)
    • Appropriate use cases for EMCO and ONAP, when to use them separately and or together
    • The teams have identified two fundamental configurations, each ideally suited for different high level use cases
      • ONAP is the centralized Service Orchestrator, Service Assurance and Automation Framework, with EMCO fulfilling specific roles as a component (multi cluster support, etc)
      • EMCO is the distributed edge focused Service Orchestrator, with select ONAP Service Assurance components configured as needed.
    • We can draw from the following examples and other supporting material during this session to describe the rationale
    • Review of the EMCO_ONAP Alignment Proposal PPT.
    • Lessons learned from:
    • EMCO team overviews the rationale for, deploying an app/service such as Magma as the primary SO
    • Given the different configurations , how can the 5G SBP program demonstrate and delineate the rationale for the two configurations?

6:30-6:45 AM PST

13:30 - 13:45 UTC

Break 1

6:45-8:00 AM PST

13:45 - 15:00 UTC

Orchestration: EMCO and ONAP ongoing operations alignmentRanny Haiby
  • Post-onboarding activities and requirements as products move into production – Day 2  operations handoff and ongoing mgmt– where and how are ongoing metrics collected and how to they feed into relevant parts of the stack....
    • What is considered in or out of the stack in various architectures
  • Time Permitting: Is there a connection to Anuket and Anuket Assured program? Infrastructure→Applications>Onboarding>MANO>Infrastructure (end-to-end)

8:00-8:15 AM PST

15:00 - 15:15 UTC

Break 2

8:15-9:30 AM PST

15:15 - 16:30 UTC

LFN Community Support Workshop: Common Documentation and Tooling
  • Common documentation standardized guidelines – Minimum requirements and expectations, tools, types of documentation required for different types of projects.
  • Common tooling – What is the current set of tools?  Is there a possibility for consolidation?  Is it needed?  Is this even possible?

9:30 AM PST

16:30 UTC

Day 2 Ends

CNF Topics 

  • Taking Anuket RA and RC activities into workloads
    • Is it sufficient to come up with a basic framework to demonstrate functionality on an example RI?
      • Necessary – is it sufficient?!
      • Tortured metaphor: we've got a good foundation, but need to address plumbing, HVAC, walls, and flooring
    • Where does performance come in?
    • How do we get into more challenging interop?
      • CNI
      • Other networking frameworks (eg., Istio, Envoy)?
      • Networking abstraction – how do we push this past the goal line, publish, and test?
      • Data Plane
        • If performance tuning is a source of interop issues, how do we address these?
        • Are data plane issues as opaque to workloads as claimed (should we do a survey, or testing experiment to have non-anecdotal data)?
      • If this is too much work, what is the highest priority activity that will reduce the cost due to re-work for end users, platform vendors, workload (CNF) vendors?
      • How do we avoid the mistakes of the past? Let's at least avoid those and create new ones.
  • Given the previous topic, what is the highest priority testing a badging program and enforce and provide?
  • CNF vendor input summit
    • How do we ask better questions to the CNF vendor community? 
    • Bring as many CNF providers as possible (perhaps with a bit of pre-prepared questions)
      • Vendors who have deployed within the 5GSPB context
      • Magma
      • O-RAN SC implementations and vendors
      • OAI
      • Workload BUs rather than platform BUs in our NEP members
      • Active CNF vendors (e.g. Matrixx, Affirmed, Metaswitch)
      • LF Edge application requirements
    • What guidelines, testing, information would be helpful for them such that they don't have to re-do for each platform/end user
    • Are we talking how to give guidelines and test for them against the platform requirements, or are there specific testing regimes for applications?
    • Assumption: CNF to specific platform 1:1 as a deployment requirement does not and cannot scale.


Architecture Topics

  • On-boarding: Alignment across ONAP and EMCO, taking into account the role played by k8s.
    • Assumption for ingress: Helm v3 
    • To the extent it needs to be extended/constrained, both groups should define together, and we can determine if and where it belongs upstream.
    • How does this discussion feed into Anuket and Anuket Assured program? Infrastructure→Applications>Onboarding>MANO>Infrastructure (end-to-end)
  • Post-onboarding – Day N – where and how are ongoing metrics collected and how to they feed into relevant parts of the stack....
    • What is considered in or out of the stack in various architectures....
  • Conceptual flow diagrams
    • Where do the focus areas of both EMCO and ONAP land? What is shared? What is not? What is gray? Beyond marketing......
    • Before we go into powerpoint comparison, I would suggest choosing a discrete set of  applications (including at least RAN and a webapp....mostly b/c those could overlap in a hybrid environment, and then also each group chooses one application that is specifically optimized for them – e.g., Core, and perhaps something that gets close to IOT). Map out for each application how the flow works in ONAP only, EMCO only, and a choice or two in hybrid scenarios. From there we can start to look at how we want to talk to the market, figure out what technical works needs to be done, and how. 


Community Topics

  • Follow-up on Documentation Workshop from Jan DTF
  • Tooling


Proposed Schedule

Day 1 –  CNF Vendor Input Summit – I think that this is a full day (4 hour) topic

  • 10 minute Intro and Logistics review
  • Part 1: As a follow up to the January Workshop, several consecutive focused sessions with CNF vendors to gain an understanding of what requirements they need from LFN projects and community to support their workloads and applications. Need to look at the expectations from the onboarding/orchestration, on-going supportability and infra platform perspectives
    • What are the vendors' priorities, objectives and expected outcomes? Improved time to market?  Ability to use a reference architecture to cut development time? Something else?
    • What architectures, requirements, guidelines, and test frameworks or information are needed to achieve these objectives? Are we talking how to give guidelines and test for them against the platform requirements, or are there specific testing regimes for applications?
    • Projects of most interest to the CNF/Operator communities? 
      • Magma
      • O-RAN SC implementations and vendors
      • OAI
      • Workload BUs rather than platform BUs in our NEP members
      • Active CNF vendors (e.g. Matrixx, Affirmed, Metaswitch)
      • LF Edge application requirements
  • Part 2: Once the objectives have been identified, develop guidance from CNF vendors on program framework, targeted projects and next steps
    • Map out an Infra Platform and Compliance Framework
    • Orchestration requirements and framework
    • How to map Anuket RA and RC activities to support CNF workloads
      • Is it sufficient to come up with a basic framework to demonstrate functionality on an example RI?
      • Do a discrete set the CNF compliance/platform interop requirements need to be fed directly into Anuket project workstreams

Day 2 First half 

  • EMCO/ONAP Architecture alignment Deep Dive – 3 hours
    • Part 1: On-boarding: Alignment across ONAP and EMCO, taking into account the role played by k8s.
      • Assumption for ingress: Helm v3 
      • Needs to be jointly defined first, then determine if and where it belongs upstream.
      • Is there a connection to Anuket and Anuket Assured program? Infrastructure→Applications>Onboarding>MANO>Infrastructure (end-to-end)
    • Part 2: Appropriate use cases for EMCO and ONAP, when to use them separately and or together
    • Part 3: Post-onboarding activities and requirements as products move into production – Day 2 – where and how are ongoing metrics collected and how to they feed into relevant parts of the stack....
      • What is considered in or out of the stack in various architectures....
    • Part 4: CNF Interoperability Challenges  between workload/platform and orchestrator/workload
      • CNI – is this the only answer?
      • Other networking frameworks (eg., Istio, Envoy)?
      • Networking abstraction – how do we push this past the goal line, publish, and test?
      • Data Plane
        • If performance tuning is a source of interop issues, how do we address these?
        • Are data plane issues as opaque to workloads as claimed (should we do a survey, or testing experiment to have non-anecdotal data)?

Day 2 – Second Half

  •  Topics of interest to the general community – 1 hour
    • Common documentation standardized guidelines – Minimum requirements and expectations, tools, types of documentation required for different types of projects.
    • Common tooling – What is the current set of tools?  Is there a possibility for consolidation?  Is it needed?  Is this even possible?

Logistics

  • 2 15 minute breaks (instead of 1 30 minute one.
  • No summary needed
  • Very short intro at the beginning of each day (10 minutes by Heather or someone who is more awake)


Facilitation Ground Rules

  • Each Session should have a clearly defined objective and scope statement.
  • When offering your thoughts, please be concise. We ask you avoid monopolizing the conversation.
  • When someone is speaking, please allow them to complete their thoughts.
  • While debate is an underpinning of growth, decorum is the foundation of progress.
  • The Facilitator/Presenter and Moderator will work to keep the discussion aligned with objectives and scope. Discussions that are not in alignment with objectives and scope will be deferred.
  • The Moderator will record the deferred topics in a topic “Parking Lot” to be addressed by assignment to community representatives at the conclusion of the session.
  • Each session should be served by a scribe


  • No labels