Building Agile, Open-Source–Based Cloud Solutions With OpenDaylight Colin Dixon Distinguished Software Engineer, Brocade Technical Steering Committee Chair, OpenDaylight

Abstract OpenDaylight has become a nexus for open source project integration, creating the new open networking stack and enabling a new generation of open source, agile IT infrastructure. The fifth “Boron” release provides new tooling and documentation to support application developers, as well as greater integration with larger industry frameworks from OPNFV and OpenStack to CORD and Atrium Enterprise. Boron also brings a strong practical focus on two leading types of deployments: (1) direct control of virtual switches to provide network virtualization and NFV and (2) management and orchestration of existing networks to provide new features and automation. This talk will cover trends in open SDN and cloud networking, with a focus on Boron milestones. In particular, it will focus on the architecture that is being developed across the OpenStack and OpenDaylight project to enable OpenStack service function chaining support in OpenDaylight controller.

Outline OpenDaylight What did we really want? Common use patterns Agility At all levels of the stack Common use patterns OpenFlow + OVSDB NETCONF + BGP

We’ve been building SDN for years Commercially since at least 2012 Why? Decouple elements of the network stack: lower 成本 (cost) faster innovation How are we doing? 敏捷 (Agility): quickly get new features with minimum dependence on others

How are we doing with SDN? Title Goes Here 11/30/2015 How are we doing with SDN? 避免厂商锁定 在市场上赢得一席之地 更快速的创新 可互操作性和集成 您会注意到我还没说成本 成本 简便易用性 灵活性 敏捷 开源 构建 购买 Define interfaces well In human-readable documents Define behavior with some ambiguity Usually move slowly Leave interoperability testing to others, e.g., users, integrators Sometimes provide open source implementations Define interfaces well In code Define behavior in code so it can be tested and understood Move and adapt quickly Can do interoperability testing as part of development Often implement open standards © 2015 博科通讯系统公司版权所有。保密信息-仅供内部使用

Why Open Source? Avoid vendor lock-in Have a seat at the table Title Goes Here 4/13/2018 Why Open Source? Avoid vendor lock-in Have a seat at the table Faster Innovation Interop & Integration You’ll note I didn’t say cost ease of use cost flexibility open source build it buy it Define interfaces well In human-readable documents Define behavior with some ambiguity Usually move slowly Leave interoperability testing to others, e.g., users, integrators Sometimes provide open source implementations Define interfaces well In code Define behavior in code so it can be tested and understood Move and adapt quickly Can do interoperability testing as part of development Often implement open standards © 2015 Brocade Communications Systems, Inc. CONFIDENTIAL—For Internal Use Only

Let’s focus on 成本 (agility) We need to be able to add features Anywhere in the stack Without help from others And deal with the consequences of the chagnes

The new open networking stack Custom HW VMs / Cont. Legacy Optical BGP OVSDB Netconf OpenFlow ORCHESTRATION (NFVO, ...) Networking Apps Mgmt / Analytics App Rest API Open NOS SDN Platform YANG ECOMP OpenDaylight has always been about connecting devices (physical or virtual) Increasingly, OpenDaylight is also about connecting projects acting as open source glue ECOMP, OPNFV, OpenStack, OVS, FD.io, … As a result, it’s the center of building open source clouds Generic OpenStack Networking CORD/vCO with OpenDaylight (this is the above + reality + service chaining) Agile & programmable Modular and interoperable Greenfield AND brownfield Heavily leverages virtualization & cloud Incorporates flexible orchestration Facilitates increasing levels automation

OpenDaylight Now “OpenDaylight fundamentally changed the Linux Foundation’s world. It’s been wildly successful. It’s the de facto standard open source SDN controller for the industry today.” - Dave Ward, Cisco CTO Mature, Open Governance 800+ Contributors Over 100 deployments Leading use cases identified Dozens of ODL-based solutions Mature code base Focus on performance, scale and extensibility *SDxCentral, 9/7/16

Boron Features and Capabilities Integration - industry frameworks OPNFV OpenStack enhancement CORD/vCO ECOMP ONF/Atrium Common SDN toolchains Net Virtualization + SFC: OF + OVSDB + OVS/FD.io Mgmt plane programmability: BGP + PCEP + MPLS + NETCONF Operational tooling Cardinal health monitoring Data analytics (TSDR & Centinel) OCP (Open radio I/F) Documentation App developer tooling YANG-IDE toolkit NetIDE for cross-OSS controller interoperability NeXt UI toolkit “Singleton app” HA App developer tooling YANG-IDE toolkit NetIDE for cross-OSS controller interoperability NeXt UI toolkit “Singleton app” HA

OpenStack/OpenDaylight Integration Multiple Neutron implementations Target different use cases, southbound drivers FD.io/VPP OVS Open Overlay Router (née LISPmob) Provide distributed implementations of scalable network virtualization for OpenStack FD.io, OVS, OpenOverlayRouter/LISPMob Get the features you want in the stack you want how you want it

OpenStack/OpenDaylight Integration L2: ML2 plugin L3: ODL L3 plugin services FWaaS L2Gateway QoS LBaaS BGPVPN networking-sfc trunk Neutron Server ML2 Plugin ODL L3 Plugin Service Plugins Type Manager Mechanism Manager FWaaS L2GW QoS ... GRE TypeDriver VLAN TypeDriver VXLAN TypeDriver ODL mech driver SR-IOV ODL driver ODL driver ODL driver ... ... ... ... ... networking-odl

OpenDaylight in vCO and ROBO

What does Central Office do? Subscriber management capabilities: Gateway, authentication and authorization, event and subscriber information logging Optical Line Termination (OLT) for PON/GPON (Passive Optical Net.) Service functions: self-service portals, NAT, FW, routing, IP addr mgmt, QoS, quotas, video caching, mail and file stores A Virtualized Central Office (vCO): Uses general-purpose compute, storage and network capabilities to deliver the above services Added agility (spin up VMs vs. rack and stack hardware) Cost savings (via increased automation and commodity servers)

vCO Data Center Architecture Physical elements are divided into Network: provides fabric/underlay Servers: provides computer/storage for VNFs North- South Fabric/Underlay (Network) VM Servers/VNFs (Compute, Storage) VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM WAN East West WAN

vCO Data Center Architecture Controllers and orchestrators use overlay networks to form service chains of VNFs North- South VNF VM VM VM VM VNF VM VM VM VM VNF VM VM VM VM VM VM VM VNF VM VM VM VNF VM VM VM VM VM VM WAN East West WAN

vCO Data Center Software Architecture OSS/BSS Policy (NIC, NEMO, GBP, Neutron) VNFO (ECOMP, Open-O, OSM, …) Service Chaining Overlay Network Fabric VNF Spec (TOSCA) VNF Catlog VNFM (Tacker, Cloudify, …) SDN Controller (OpenDaylight) VIM (OpenStack, Kubernetes, …) Fabric/Underlay (Network) VNF VM Servers/VNFs (Compute, Storage) VM VM VM VM VM VM VNF VM VNF VM VM VM VM VM VM VM VNF VM VM VM VNF VM VM VM VM VM VM

ROBO: Using vCO Blueprint in Enterprises vCO for Enterprises to provide for Remote/Branch offices Maybe offered by ISPs as a service Integrating with public cloud will likely involved some form of vCO (either aaS or Enterprise-deployed) Hybrid Cloud will almost certainly involve vCO Private Cloud Branch Office Public vCOaaS from ISP Remote Office Main Office vCO to connect backends Automating this requires integration with many other projects and legacy devices (NETCONF + BPG + MPLS + PCEP) ROBO = Remote office/Branch office

Think Beyond the Controller Product Enabling solution component

Thank you