Anees Shaikh

Technical Infrastructure

OpenDaylight mini-summit, August 2014

Extending SDN beyond the control plane

● Software defined networking -- where SDN is today● State of the management plane● SDN extended to management● Community-driven framework for moving forward

Agenda

SDN and the control plane -- lots of progress

global visibility programmatic decomposition ofcontrol and data

well-defined APIs

network models and abstractions

interoperability and open standards

controller

SDN interface

controllerNB API

● SDN focuses on control over network packets / traffic○ routing, forwarding, failover, access control, filtering, QoS, …○ dynamic, real-time, convergence

SDN today ≠ network management

● Traditional network management is device-centric○ configuration (SNMP / CLI), monitoring (RMON, Netflow)○ longer timescales than the control plane

● but … SDN requires interaction with the management plane○ device discovery, topology views, failure notifications, traffic stats, …○ e.g., OpenFlow includes some management functions for OF devices

(traffic stats, topology discovery, …)

Elements of network management

state-of-the world

● change management● new device qualification● network MOPs

● network policy (security, traffic exchange)● network-wide configuration● QoS, virtual-to-physical mapping● L3-to-L1 mapping

network management

plane

● topology● telemetry / monitoring● traffic statistics / analytics

device behavior

network behavior

process / workflow

● device-level configurationincl. software, hardware, protocols

● proprietary CLIs, expect scripts

● imperative, incremental configuration

● lack of abstractions

● configuration scraping from devices

● SNMP -- nobody’s favorite protocol / tool

Network configuration management still stuck

how can we apply SDN principles to network configuration management?

SDN principle Applied to configuration

separation of control and dataauthoritative configuration managed / maintained outside of devices -- scraped config is not authoritative !

centralized controlnetwork-wide, coordinated, validated configuration requires a logically central view

network abstractions and APIsmanage and manipulate high-level configuration data model -- avoid trying to reason about device-level configuration

standard protocols and interop adoption of standard configuration data models is crucial to enable vendor-neutral configuration

SDN applied to network configuration

Software defined network configuration

abstract configuration models

Config Model

Topology Model

some artwork sourced from: http://icons8.com/license/

configuration intentoperators

declarative APIconfiguration flow

configuration pusherNETCONF, RESTCONF, JSON-RPC, ...

...

authoritativeconfig store

config generation

device-level configuration

standard models

● vendor-neutral configuration models

● generated vendor-specific configuration instances

● multiple transports possible● configures devices and software

application

NB APIs

Network OS

SB protocols

SDN stack

config generation

authoritativeconfig store

Common configuration data models

● Common models provide an abstraction of device-level configuration○ cross-vendor configuration using a base standard

○ separates serialization and transport from the schema

○ validation of configuration instances

○ extensibility to accommodate device or vendor specific features

● “This has been tried before … why now? what’s different?”

○ SDN and automation glaringly absent in the management plane

○ network operators now demanding a common, automatable approach

○ growing traction for configuration DSLs in standards and practice

What makes a good common config model

● standards based

● commonly used naming and structure

● simple and “limited”

● defaults and constraints for validation

Existing standards and efforts we can leverage○ YANG configuration data modeling language (RFC 6020)

○ base configuration models for types, interfaces (IETF NETMOD wg)

○ other modeling work in IETF working groups and OpenDaylight

Supporting vendor-specific configuration items

base modelaugmented model with vendor-specific extensions

● vendors support base model directly

● vendors can add configuration items specific to their products as extensions

● vendor extensions are distributed as model augmentations separate from the base model

● users can use base model to configure across vendor devices

● users can adopt vendor extensions if they wish to use vendor-specific features or have single-vendor environments

“but I use that feature from [insert vendor name here] in my network!”

Model development process -- BGP example

identify required BGP options based on operator use cases

survey vendor BGP implementations to determine extent of support

- major and small vendor implementations- OSS implementations

determine an overall model structure

transcribe to YANG modules

validate / lint YANG modules (pyang)

BGP protocol config model

BGP policy config model

publish for comment

Roadmap

● Google is working on an initial set of vendor-neutral configuration models○ engaging other network operators to enhance, and add to, initial set

(e.g., BGP, VPNs, MPLS, …)○ adopted YANG as the configuration language

● Publish models and code jointly from a small set of users

● Invite participation, feedback, enhancements from other network users and vendors

● Work with device vendors to support these models on a variety of platforms

Additional elements of the “abstracted network”

Standard unified topology model○ Provide a common way for controllers, tools,

and administrative domains to communicate topology information

○ describe multi-layer network topology(Layer-0 - 7)

○ Google made significant progress in a structured hierarchical description of multi-layer connected graphs using protocol buffers* (aka protobuf)■ exploring ways to open the model schema and

associated tools to the community

facilities: buildings, conduits, cables

physical: device, linecard, chassis, port, ...

transport: OCH link, OTU link, ...

network: LSP link, BGP adj, interface, ...

logical: virtual network, logical link, ...

● Encourage more attention (and projects) oriented toward SDN-based network management

● Leverage YANG modeling expertise and experience from ODL (along with IETF, etc.)

● Work with the ODL community to improve, extend, and support vendor-neutral network models

Role of OpenDaylight

Software Defined Networks require Software Defined Operations

It is time to transform the management plane with the community!