Bringing SDN to the Management Plane (@scale)Anees ShaikhGoogle Technical Infrastructure

Management plane challenges

Programmability in the management plane

OpenConfig -- community-driven development3

2

1

Agenda

Google backbone networks

70+ edge PoPs in 33 countries

connecting Internet-scale data centers around the world

traffic serving for

● hundreds of millions of hours viewed per day

● 300 hours of video uploaded per minute

Management plane challenges

Challenges of managing a network@scale

● 20+ network device roles● 4M lines of configuration files● more than half dozen vendors, multiple platforms● up to ~30K configuration changes per month● many tools, and multiple generations of software

Opportunity for significant OPEX savings: reduced outage impact, simplification of management stack, better scaling

Management plane is way behind

● proprietary CLIs, lots of scripts● imperative, incremental configuration● lack of abstractions● configuration scraping from devices● SNMP monitoring -- not “simple”

Lack of visibility leads to inefficiency

● SNMP is our de-facto monitoring mechanism but poorly suited○ legacy implementations -- poor performance and scaling

○ rigid structure -- limited extensibility to add new data

○ proprietary data -- require vendor-specific tooling

● Efficient traffic management requires tight control loops, and real-time visibility

Toward a programmable management plane

SDN applied to configuration managementSDN principle Applied to configuration

separation of controland data

authoritative configuration outside of devices; scraped config is not authoritative !

centralized controlnetwork-wide, coordinated, configuration and visibility

network abstractionsand APIs

knowledge in data models, pub/sub API for obtaining network state

standard protocols and interop

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

Configuration

• describes configuration data structure and content

• common modeling language: YANG

• multiple data encodings: protobuf, XML, JSON, ...

Topology

• describes structure of the network

• common modeling language: ?

• data encoding: protobuf, ...

Telemetry

• describes monitoring data structure and attributes

• common modeling language: exploring YANG

• data encoding: JSON, ...

Model-driven network management

Intent-based configuration flowabstract configuration models

Config Model

Topology Model

configuration intentoperators

declarative APIconfiguration flow

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

...

authoritativeconfig store

config generation

device-level configuration

standard models

vendor-neutral configuration models

generatedconfiguration instances

config generation

authoritativeconfig storeapplication

NB APIs

Network OS

SB protocols

SDN stack

Streaming telemetrynetwork state changes observed by analyzing comprehensive time-series data stream

● devices programmed with a data model describing desired structure and content

● stream data continuously -- with incremental updates

● support for efficient, secure transport protocols

OpenConfig

OpenConfig

● Informal industry collaboration of network operators

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

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

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

● Ongoing interactions with standards community (e.g., IETF, ODL)

“The fact that these distinctly different -- and often competitive -- service providers are working together is an indication of the urgency they feel ...”

LightReading, “The New IP”, 11/24/2014

“Collaboration innovation”

“Instead of waiting for standards, operators are pushing them forward and showing a willingness to move on their own as well, when it is in their best interests”

INTERNAL: Google Confidential and Proprietary

Extending OpenConfig models

● base OpenConfig model as a starting point

● vendors can offer augmentations / deviations

● operators can add locally consumed modifications

base model

X vendor modifications

local modifications

extended model

INTERNAL: Google Confidential and Proprietary

Models must be composed to be useful

● model composition framework is critical missing piece from existing model-building efforts

Example configuration pipeline with OpenConfig models

configuration instance data (protobuf / YAML)

validation I

validatedconfiguration (proto / YAML)

encode for transport to devices (XML, JSON, proto)

r/w to native config

device vendors

18

OC YANG models

configurationgeneration

validation IItopology, policies, constraints

OC to/from native model

OpenConfig progress

● BGP and routing policy models published

● MPLS / TE model in progress

● device meta-model in progress

● interfaces, system, IS-IS, L3VPN, …

● native implementation discussions with several major vendors

Summary● Time for the management plane to join the age of SDN

● Core principles: configuration and topology models; declarative configuration; streaming telemetry

● OpenConfig is a focused effort by operators to drive model development based on operational use cases

Invitation to additional network operators in all sectors:

leverage OpenConfig to enable your networks with a programmable management plane

Thank you

Google global CDN