bringing sdn to the management plane
TRANSCRIPT
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