IP/MPLS Backbone Transition to SDN: OpenDaylight Advisory Board Orange IP/MPLS Backbone Transition to SDN: An ODL-based Automation with a Model-Driven built-in Orchestration OpenDaylight Advisory Board 04/20/2017 Speaker: Olivier AUGIZEAU Orange France – IP Network Operations – Head of Security & Automation b<>com Institute of Research and Technology – Network Architect

Preamble This presentation highlights a Proof of Concept designed and developed to answer some Orange specific requirements. This document is provided for information and is not a recommendation for a target architecture or implementation. Some of the technical choices regarding the protocols to control and manage the network elements have been done only to illustrate some heterogeneity concerns. They are neither recommendations nor implementation choices for an operational deployment.

Can SDN Improve the Automation of the Current Networks? Research SDN promises more Automation more Agility more Flexibility Field – Network operations Automation obstacles Legacy WAN devices Vendor lock-in OPEX pressure OSS-BSS/network ossification The question is not «how to automate?» but «how to automate better?».

Orange France IP/MPLS Backbone A shared infrastructure retail triple play (Internet, VoIP, TV/VoD) mobile traffic wholesale (access, transport, …) A complex infrastructure … Several thousands of IP backbone network devices from many vendors and generations interconnected with many transmission links Access network: several tens of thousands of DSLAM/OLT Peering (telco & transit, hosting & contents,… ) … in a perpetual evolution + 50% traffic / year many network changes and reorganization

Use Case for a Proof of Concept Automatic reconfiguration of an Orange France wholesale offer after an access network reorganization. The offer is a “layer 2” point to point connectivity bringing together: VLAN cross connect MPLS L2VPN point-to-point tunnel (pseudowire or “pw”) Network reorganization: an access device (dslam, olt, …) is physically moved from an aggregation switch to another one. VLAN switch VLAN PE Pseudo Wire (MPLS) PE VLAN Access Delivery sw1 Open vSwitch PE1 Nokia PE3 Cisco MPLS sw2 Open vSwitch Delivery PE2 Nokia PE4 Juniper Access PE: Provider Edge (Router providing the MPLS Services)

Automated Provisioning Based on Network Events SDN Controller sw1 PE1 PE3 ? sw2 PE2 Delivery Access

Logical Architecture and Interfaces Network Application xml OSS BSS xml files received from legacy OSS/BSS: network inventory and topology customers and services access migration operations Restconf (JSON) Network Controller & Orchestration xml Netconf (Juniper, Nokia). ssh/CLI (Cisco). OpenFlow sw1 PE1 Nokia PE3 Cisco IP/MPLS routers are managed with netconf or ssh/CLI. The Network Controller provides an abstraction layer hiding this heterogeneity. MPLS sw2 PE2 Nokia PE4 Juniper Switches are controlled with the Openflow protocol. The 1st packet is detected by the switch and sent using Openflow to the Network Controller. Any information in the packet header can be used to process the request. (VLAN field is used here)

Functional Architecture Based on OpenDaylight (Be-SR2) Network Notification Handler Network Application Service Authorization and Request Builder Data Base Service NBI Service Composition and Orchestration Engine Network Notification Listener Network Operations Library Network Controller & Orchestration OpenDaylight Be-SR2 Data Store MD-SAL (Model-driven Service Abstraction Layer) Drivers SBI Simple Path Computation Topology Network Elements

Automation with a Yang-Centric Network Operations Orchestration Engine Data are stored in the ODL Config DS

Service Creation Composition: a “Matryoshka” Design Access switch PE PE Delivery VLAN x-connect pw Logical resources egress flow operation Physical interface mpls operation ingress flow operation pw logical interface operation Real resources Switch Access PE Delivery PE

Yang Data Models Structuration is the Key Stone to get Agility and Flexibility Network Service New service VLAN x-connect PW New network function Generic Atomic Operation Flow Topology extensions Physical interface Logical interface New operation OpenFlow Plugin IETF Topology Generic device driver Generic ssh/CLI driver Generic Netconf driver New protocol driver Cisco driver Nokia driver Juniper driver New vendor driver

Feedback OpenDaylight model-driven architecture is very powerful. A Yang-centric composition & orchestration engine has easily been integrated into OpenDaylight. The Netconf driver might be improved to target an operational deployment in an IP/MPLS backbone: Schemafull mode is not compatible with vendors providing huge Yang Data Models (proprietary Yang extensions, Yang compilation issues, many useless Data Models). Schemaless mode (in Boron and Carbon) is very complex to set up and requires some fixes.

Thanks