- Created by Ray Paik, last modified by Cristina Badulescu on Feb 16, 2018
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 61 Next »
The goal of the plenary sessions is to cover topics that are of interest across all LFN communities before breaking into separate breakout sessions for fd.io, ODL, ONAP, and OPNFV. Please add your plenary session proposals in the table below by 5pm Pacific Time on February 23rd. Project specific breakout sessions will be planned on separate wiki pages (see OPNFV example)
Tentative Schedule
Monday (March 26, 2018)
Main room | Breakout Room | Breakout Room | Breakout Room | Hacking Room | |
08:00 - 09:00 | Developer Forum Kickoff |
|
|
|
|
09:00 - 09:30 | Plenary topic #1 | Plenary topic #2 | Plenary topic #3 | Plenary topic #4 | |
09:30 - 10:00 | Plenary topic #5 | Plenary topic #6 | Plenary topic #7 | Plenary topic #8 | |
10:00 - 10:30 | Plenary topic #9 | Plenary topic #10 | Plenary topic #11 | Plenary topic #12 | |
10:30 - 10:45 | AM Break | ||||
10:45 - 12:15 | ONAP Breakout | fd.io Breakout | ODL Breakout | OPNFV Breakout | |
12:15 - 13:30 | Lunch Break | ||||
13:30 - 18:00 | ONAP Breakout | fd.io Breakout | ODL Breakout | OPNFV Breakout | |
Tuesday (March 27, 2018)
Main room | Breakout Room | Breakout Room | Breakout Room | Hacking Room | |
08:00 - 09:00 | TAC Meeting |
|
|
|
|
09:00 - 10:00 | ONAP Breakout | fd.io Breakout | ODL Breakout | OPNFV Breakout | |
10:00 - 10:15 | AM Break | ||||
10:15 - 11:30 | ONAP Breakout | fd.io Breakout | ODL Breakout | OPNFV Breakout | |
11:30 - 12:00 | Wrap-up session |
|
|
|
|
Session Proposals
[Note: the current plan for each session is 30 minutes]
| Title | Speaker(s): name/email | Target audience | Abstract (3-5 sentences) | Notes | |
|---|---|---|---|---|---|
| 1 | ETSI NFV & LFN collaboration - VNF Package, VNF Descriptors - | TBD (ETSI NFV representatives) | OPNFV, ONAP developers | The latest status and details of ETSI NFV VNF package specifications including ability to include non-MANO artifacts in a VNF package will be introduced. | Contact: Tetsuya Nakamura (t.nakamura@calelabs.com) |
| 2 | ETSI NFV & LFN collaboration - Functionality, API - | TBD (ETSI NFV representatives) | OPNFV, ONAP developers | A high-level map of the functionalities and concept behind the ETSI NFV APIs will be introduced. Also, support of API client authentication/authorization based on TLS certificates as an alternative to OAuth, management interfaces between MANO and OSS/BSS, and OpenAPI work status will be addressed in order to discuss how ETSI NFV APIs can work with the LFN. | Contact: Tetsuya Nakamura (t.nakamura@calelabs.com) |
| 3 | ETSI NFV & LFN collaboration - Architecture - | Cristina Badulescu (cristina.badulescu@ericsson.com), Stephen Terrill (stephen.terrill@ericsson.com), Jamil Chawki /Orange | OPNFV, ONAP developers | ONAP - ETSI NFV architectural framework alignment proposals will be presented. | Contact: Tetsuya Nakamura (t.nakamura@calelabs.com) Jamil Chawki |
| 4 | ETSI NFV & LFN collaboration - Testing - | Pierre Lynch / pierre.lynch@keysight.com | OPNFV, ONAP developers, testers | ETSI NFV TST Working Group activities including NFVI compute & network metrics, NFVI benchmarks, and interoperability testing guidelines will be introduced. Direct testing collaboration activities will be discussed. Also,the current ETSI Plugtest operation will be explained, and the collaboration framework for the upcoming co-located Plugfest/Plugtest event in June will be proposed. | Contact: Tetsuya Nakamura (t.nakamura@cablelabs.com) |
| 5 | Cross Community Infra/CICD | TBD | LFN Developers who are interested in how things work across LFN and wider open source ecosystem | All of our communities strive to apply CI/CD and Infra best practices and use certain tools supporting these. There has been substantial amount of work going on in this area and this session will give update on these and how to involve. | Contact: Fatih Degirmenci (fatih.degirmenci@ericsson.com) |
| 6 | ONAP use cases and functional requirements: from Amsterdam to Beijing and brainstorming on Casablanca focus/requirements | Alla Goldner alla.goldner@amdocs.com | LFN developers | Description of the evolution we've went through from supporting use cases in Amsterdam to supporting generic functional requirements in Beijing. The process and the scope ofd the requirements will be covered. | Contact: Alla Goldner (alla.goldner@amdocs.com) |
| 7 | Long Duration Stability Test | Yang (Gabriel) Yu , Sridhar | LFN developers | Long duration tests are introduced in OPNFV by test working group and cooperate with Infra working group. Tests for long term stability could be manipulated elaborately to reflect and validate many aspects of the system for stable production usage purpose.The background, methodology, set-ups, specification, upstream and results of stability validation in OPNFV will be discussed. | Contact: Yang (Gabriel) Yu |
| 8 | Build Once Use Many : A Comprehensive Approach to API Validation and collaboration for all stakeholders | sreekalyan devaraj, Luis Gomez | LFN developers, QA professionals, API users, contributors | Automation and programmability are the key aspects of SDN/NFV and thus APIs are at the heart | Contact: sreekalyan devaraj, Luis Gomez |
| 9 | Telecom Service providers PoCs leanings from ONAP Policy Engine with AI/ML predictive inputs | Sana Tariq | Acumos community,OPNFV, ONAP developers, users, contributors | This session will share key learnings from ONAP PoCs using CLAMP project closed loop orchestration use-cases with real-time analytics and AI/ML predictive inputs to drive policy decisions. We will address telecom service providers use-cases for AI and machine learning and desired state of ONAP policy engine to optimize cloud/network resource management, enhance security and drive better customer experience for supporting future services landscape. | Sana Tariq |
| 10 | Panel: Lessons Learned: Integration, From the Cradle to the Stage | Robyn Bergeron, Daniel Farrell, Monty Taylor, Gildas Lanilis, Fatih Degirmenci | Anyone who is interested in learning about what we are doing to solve challenges we all face in open source E2E Integration | In this panel, developers from OPNFV, OpenDaylight, OpenStack and ONAP communities will discuss the challenges in E2E Integration and Testing faced by the open source networking projects and what each community is doing to address them in a collaborative manner. Participants will learn more about the initiatives driven collectively by these communities and get to know the latest developments in CI/CD and DevOps area in open source. | Fatih Degirmenci Daniel Farrell |
| 11 | Enabling Workloads Orchestration in Multiple Clouds | Bin Hu, bh526r@att.com | LFN Developers and anyone who is interested in enabling a platform and service on multiple cloud infrastructures | ONAP is missioned to deploy and run VNFs on multiple infrastructure environments, including virtualized infrastructure and cloud native. Workload deployment and orchestration in multiple clouds is expected to play an essential role in ONAP operational success.This presentation discusses an architectural vision for ONAP to orchestrate workloads in multiple clouds. The key aspects for a comprehensive ONAP workload orchestration are discussed, including deploying containerized workloads into k8s clusters on bare metal in edge cloud. ONAP MultiVIM component serves as a single platform for deployment and orchestration of containerized workloads as well as VM-based workloads in true multiple infrastructures. It simplifies workload management and improves ONAP’s operational performance and user experience. | Contact Bin Hu, bh526r@att.com |
| 12 | A guide to build a cloud native VNF | VNF or application developers | Cloud native webscale applications are already in use since years. The principles of cloud native transformed the industry and all applications are hyper scalable and infrastructure agnostic. How can we apply the same pattern to a high capacity and highly available VNF and how can this fit into the ETSI NFV architecture? In this talk I will describe how the different layers of a core network signaling VNF application built together into a new cloud native architecture, what challenges we had and how did we solve those. | ||
| 13 | Kubernetes networking in the telco space | Gergely Csatari | Anyone trying to run VNF-s on Kubernetes. | The main purpose of VNFs is to route different types of network traffic into the right direction. This means that VNFs are handling a high amount of network traffic and have special networking needs. The networking solution provided by Kubernetes does not fulfill these requirements, therefore we built a CNI plugin. This presentation lists the requirements and architecture of CNI plugin and alternatives, which were investigated. | |
| 14 | Building a product on Open Source: Challenges and Solutions, | Ekta Khurana, ekhurana@luminanetworks.com Vasu Srinivasan, vsriniv@luminanetworks.com | Anyone who wants to build a product and CI infrastructure on Open Source | Recent evolution of Open Source projects has made a significant impact on the approaches that organizations use to build software products. While Open Source projects offer measurable benefits, a wide range of features and use cases, maintaining production quality is an immense effort that demands organizations to adopt the “upstream first” methodology. Speakers will share their experiences on the technical challenges encountered while productizing the OpenDaylight project, nuances of supporting parallel major releases, re-enforcing quality metrics, community contribution, packaging process to build a production ready distribution, applying continuous integration and automated testing techniques on different platforms, keeping up with major upstream releases and insights into how to maintain a two-way road between a community project and a company product. | Contact: Ekta Khurana ekhurana@luminanetworks.com |
| 15 | Advanced automation in ONAP via closed loop | Marco Platania (platania@research.att.com) | ONAP, LNF developers, cloud providers, network operators | Cloud technologies and virtualization are revolutionizing the network. Operators can rapidly deploy network functions, scale out, replicate, and migrate them based on customer demand, resource availability, reliability requirements, etc. This highly dynamic environment makes it hard and inefficient to manage modern networks manually. ONAP addresses this issue by supporting policy-driven automation of management functions via closed loop. This allows to monitor and control the behavior of network functions in real time, dynamically scale resources, and quickly manage the failure of network elements, resulting in operational efficiency and cost reduction. In this talk, we will present the main building blocks for creating closed loops in ONAP and demonstrate closed loop in action for managing the lifecycle of FD.io VPP-based ONAP use cases. | Contact: Marco Platania, platania@research.att.com |
| 16 | LFN Compliance/Verification Governance | Chris Donley (christopher.donley@huawei.com) | LFN service providers and vendors interested in compliance/verification testing | This session will discuss existing and planned compliance/verification programs (such as OVP, Powered by OpenDaylight, and VVP). We will also talk about how to harmonize under the LFN umbrella, and discuss a proposal for a new governance structure for LFN compliance and verification that encourages collaboration and re-use, while preserving each community's oversight and engagement. | Contact: Chris Donley |
| 17 | Building container-based NFV solutions with VPP integration and ONAP orchestration | The presentation will be useful for audience who want to understand the progress of NFV on Arm and who have plan to deploy their NFV solutions on Arm architecture. | Containers are becoming popular choices for NFV solutions due to the benefits provided: easier to deploy, better scalability and lower overhead. Kubernetes has become another choice for Virtual Infrastructure Manager (VIM) in NFV deployment. Some key challenges still need to be addressed for container-based NFV solutions, e.g., requirements of high performance container networking solutions and ease of orchestration and management of VNFs, which are pain points for many server providers to deploy container-based NFV solutions. This presentation will show a reference design of container-based VNFs with integration of Vector Packet Processing (VPP) from FD.io and ONAP orchestration on Arm NFV infrastructure. We are building this Arm-based solution in OPNFV Container4NFV and Auto projects. Kubernetes is used as VIM to deploy Docker cluster for OPNFV platform. ONAP key components like APP-C, DCAE, SDN-C are deployed on this OPNFV platform for Edge Cloud, Resiliency, and Enterprise vCPE use cases. The VPP vhost-user interfaces are used to create L2 bridge and VxLAN overlay to connect between containers, which can be on the same host or different hosts. Two local cloud stacks (OpenStack, and cloud-native) are used in combination to represent one type of "hybrid cloud" environment.
| Contact: Tina Tsou | |
| 18 | Model Driven NBI of ONAP Multi-VIM/Cloud service | ONAP developers, VIM vendors, Cloud service providers and VNF vendors who care about how the model driven NBI of Multi-VIM/Cloud service could simplify the life cycle management of workload over VIM/Cloud of various types. | ONAP Multi-VIM/Cloud project aims to provide a mediation layer between ONAP and VIM/Cloud of various types in order to make ONAP being cloud agnostic. It would be very beneficial to achieve this goal by having Multi-VIM/Cloud exposing a set of common NBI to ONAP components and translating them into different sets of SBI for target VIM/Cloud of various types. Through this presentation, I will illustrate what the Model driven NBI exactly is and how it can be used as this common set of NBI. | Contact: Bin Yang bin.yang@windriver.com | |
| 19 | Hands On with the APEX Adaptive Policy System | Developers who would like to have a way of defining logic and the data it uses in their system in a flexible way at run time. Architects who wish to gain an understanding of how policy and specifically adaptive policy could be used to enhance the architecture of their systems. | Policies can be used to express logic in a flexible and adaptive way for any application domain. The Apex Adaptive Policy System and Environment allows you to change your domain logic on the fly as your application runs and to control the context of multiple policies as they run. APEX is being contributed to ONAP by Ericsson. This hands-on tutorial session will give an overview of Apex Adaptive Policy System and Environment and will briefly explain the principles and components of the system. Attendees will be shown how to install APEX and create a policy. How to deploy and execute the policy on an Apex policy engine will be shown. Modification of a policy at run time, adapting it, and redeploying the adapted policy in the engine will also be demonstrated. | Contact: Liam Fallon | |
| 20 | Cross LFN technical projects Collaboration | Jamil Chawki | LFN PTLs and TSCs | What cross project within LFN should focus on at ONS ? Identify topics for cross collaboration between ONAP, OPNFV, ODL, PNDA & SNAS (XCI, Reference VNF, NFV Infrastructure, VNF validation, Network Analytics ... Cross LFN projects collaboration | Contact: Jamil Chawki |
| 21 | Taming Policy Complexity: Model to Execution | Audience: developers and architects interested in closed control loop automation (with policies for decision making). Anyone else who wants to understand that we do distributed computing, not networking, these days. | Regardless of its domains of application, the policy system at the centre of a closed loop system such as ONAP will need to have some very stringent and dissonant quality attributes. As well as ensuring that the correct policy is in the correct place at the correct time, executing policies must preserve state and yet scale and must take account of their (possibly conflicting) context and yet be adaptable. In this talk we discuss the relative importance of these quality attributes when applied to a closed loop system such as ONAP. We draw on our work in Policy to discuss how policies that hold state at run time can be scaled, and how a policy system can be engineered to be adaptable even as its state and context changes. We will detail our policy engine, which Ericsson is contributing to the ONAP policy framework. | ||
| 22 | Re-using OPNFV framework tests for LFN projects | Eric Debeau eric.debeau@orange.com Cédric Ollivier | Porjects: OPNFV, ONAP, ODL, Audience: testers, developers | OPNFV defined a powerful framework for functional tests to check the various OPNFV scenarios. This framework is very flexible and enables with a lighweight Docker to run a set of rich functional tests and automatically reports results in DB. ONAP project started to use FuncTest framework to validate the end-to-end solutions using the various installers (Heat and Kubernetes). | Contact: Eric Debeau |
| 23 | Harmonizing documentation across LFN | Eric Debeau eric.debeau@orange.com | Project: All LFN projects Audience: architects, end users | Documentation is key to get fast adoption by a broad ecosystem. Various LFN projects are using the same chain documentation tooling based on RST+Sphinx. However, there is a lack of harmonization for Documentation presentation, API documentation, figures, call flows. Identify how to better harmonize Documentation and provide the best practices | Contact: Eric Debeau |
| 24 | Common Modeling Practice in ONAP | Lingli Deng Rittwik Jana Hui Deng David Shadmi Andy Mayer | Interested audience would be including: | ONAP is targeted as a model-driven platform for SDN/NFV network automation. The common modeling design and implementation by all the third-party management systems (OSS applications, Cloud infrastructure managers, SDN controllers, vendor specific element mangement systems, etc.) externally, service and network entities to be managed by ONAP among the different ONAP components (design and creation, deployment and monitory, etc.) internally is the key to achieve that goal. ONAP R1 is mostly about the mapping of ECOMP IM/DM with OPENO ETSI/TOSCA based IM/DM due to time limitation. Starting from Release 2, ONAP modeling subcommittee is working on the merge into the unified IM/DM and taking into input from different SDOs (TMF, MEF, ETSI NFV). The panelists will share the approach taken by and a summary of current progress of ONAP modeling. It is intended to arouse the interest in and encourage contribution to the practice from a broader ecosystem. | Contact: Lingli Deng |
| 25 | Collaboration between opensource(ONAP) and SDO for SDN/NFV Modeling/API | Developers, modeling community, SDOs, | The coordination between standard and opensource become more imperative when ONAP would like to support more commercial use case, different SDOs and forum have different model for key artifacts such as service, resources. The danger is that when API are built, different SDO, Forum, and ONAP will not be able to interoperable. for NFV, some vendors have already implemented the product reference on ETSI NFV/OASIS TOSCA standard, for inter operator interworking, MEF also proposed interlude interface. TMF API has been widely used , ONF TAPI has been integrated into MEF core and resource models. So this panel will discuss how opensource and standard would work better to get alignment to avoid the fragmentation of industry. | Contact: Hui Deng | |
| 26 | Management of cloud native network functions | ONAP Developer, VNF Vendors, Network Providers | Cloud native network functions leverage containers, hence driving the introduction of container orchestration in automation systems. The container orchestration systems provide rich capabilities in the area of application instantiation, scale, monitoring and upgrade. Most of the network functions are based on VM today and there would be a transition from pure VM to hybrid (VM + container) to pure containers based Network functions. This presentation looks at introduction of contain orchestration into ONAP as well as hybrid VM and container orchestration. | Contact: Munish Agarwal | |
| 27 | Managing State in Cloud Native VNFs | Dave Neary | OPNFV, VNF Vendors | The classic advice for cloud native application development is to avoid stateful components. However, most Telco applications include multiple types of stateful data - events, telemetry, call records, customer data, application session state, and more. This presentation will cover common cloud native data design patterns which allow developers and operators to scale applications and provide resiliency for important data. Attendees will learn about common data patterns including sharding and master/slave replication, the many ways to cache data to improve performance and scalability, and modern storage back-ends which are tolerant to failure. | Contact: Dave Neary <dneary@redhat.com> |
| 28 | Building Cloud Native, Web Scale, Deployable VNFs with Service Mesh Architecture | OPNFV, ONAP VNF developers DevOPS Communication service providers | In the Cloud Native communities, 2018 is turning out to be the Year of Service Mesh. In this talk, we will introduce to the audience of What's and Why's of the mirco-service architecture based on a Service Mesh, the competing open source options of Service Mesh (e.g. Istio / Envoy, Conduit, NginMesh ...), and the challenges we need to solve to implement a service mesh based micro-service architecture for CSPs, e.g. container networking choices, supporting stateful VNFs, service policy interfaces etc. We will weave in some of the ongoing work in the OPNFV Clover project addressing these challenges along the way, but the content is broadly applicable to anyone interested in learning about how to build web scale, deployable, cloud native network services with a service mesh architecture. This will be equally applicable to developers and operators. | ||
| 29 | Early Insights from ONAP/OPNFV Cross-Community Collaboration PoC | All LFN developers involved in validation and verification projects. Service providers interested in having validation baselines in their NFV related RFPs. | This session will provide a preview into how the ONAP VNF SDK project can deliver test content through the OPNFV Dovetail compliance verification framework. A hands-on demo will show how Dovetail driven onboarding/lifecycle VNF validations can be triggered upon uploads to the ONAP VNF Marketplace. The demo will further expound on how the OPNFV Verified Program (OVP) web portal can be leveraged to provide infrastructure in the context of a broader LFN ‘Verified’ program. This common infrastructure includes a centralized, LF-managed result repository online to foster collaboration and self-testing with community reviews. In turn, the additional VNF SDK validation content will make a unified ‘Verified’ program more compelling. | Contact: Eddie Arrage | |
- No labels