Anees ShaikhGoogle Network Operations

www.openconfig.net

An open management plane

The era of SDN and open networkingwhitebox switches, merchant siliconOpen Compute ProjectOpen Network Install EnvironmentOpen vSwitch, LINCOpen Network Operating System

OpenDaylightOpen Network LinuxOpenContrailAtriumOpenFlowRouteFlow

2

The era of SDN and open networkingwhitebox switches, merchant siliconOpen Compute ProjectOpen Network Install EnvironmentOpen vSwitch, LINCOpen Network Operating System

OpenDaylightOpen Network LinuxOpenContrailAtriumOpenFlowRouteFlow

3

● open data planes● open control stacks● open protocols● NB APIs and abstractions

What about open operations?

Where we are today● many proprietary integrations

○ CLIs, scripts, templates, modules, cookbooks, minions, ...

● lack of available abstractions and common APIs

● configuration scraping from devices

● SNMP monitoring -- start with standard, end with enterprise

4

Elements of an open management plane

5

interoperable network-wide view

multiple vendor devices

API

common API for configuration and monitoring management system

transport and RPC protocols that are open, streaming, secure

Configuration

• describes configuration data structure and content

Topology

• describes structure of the network

Telemetry

• describes monitoring data structure and attributes

model-driven network management

OpenConfig: users defining the APIs● Informal industry collaboration of network operators

● Focus: define vendor-neutral configuration and operational state models based on real operations○ Adopted YANG data modeling language (RFC 6020)

● Participants: Apple, AT&T, BT, Comcast, Cox, Facebook, Google Level3, Microsoft, Verizon, Yahoo!

● Primary output is model code, published as open source via public github repo

● Ongoing interactions with standards and open source communities (e.g., IETF, ONF, ODL, ONOS)

● Partnership with major vendors to drive implementations6

OpenConfig development process

7

Example configuration pipeline

configuration datavendor-neutral, validated

multiple vendor devices

8

OC YANG models

configurationgeneration

gRPC req

operators

intent API

“drain peering link”

update topology model

gRPC endpoint

OpenConfig releases and roadmapData models (configuration and operational state)

● BGP and routing policy○ multiple vendor implementations in progress (incl. Cisco, Juniper)

● MPLS / TE consolidated model○ RSVP / TE and segment routing model as initial focus

● design patterns for operational state and model composition● tools for translating YANG models to usable code artifacts

9

Models currently in review● interfaces, system, local routing, optical transport, ...

Summary● SDN focus mostly on programmable control and forwarding

○ it’s time for the management plane to join the age of SDN

● Core principles:○ model-driven management○ streaming telemetry to scale monitoring and improve freshness○ vendor-neutral, extensible APIs for managing devices

● OpenConfig is a focused effort by operators to develop vendor-neutral models to define management APIs

10

www.openconfig.net : models, FAQs, discussion list

Thank you!

11

“This has been tried before ... what’s different now?”

12

● SDN and automation glaringly absent in operations○ lagging innovation in management plane

● network operators demanding a common, automatable approach

● better support for extensible, not proprietary, models

● growing traction for configuration modeling languages in standards and practice

Extending OpenConfig models

● base OpenConfig model as a starting point

● vendors can offer augmentations / deviations

● operators can add locally consumed extensions

base model

X vendor modifications

local modifications

extended model

13