Bringing SDN to the
Management Plane (@scale)
Anees Shaikh
Google 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 management
SDN principle Applied to configuration
separation of control
and data
authoritative configuration outside of devices;
scraped config is not authoritative !
centralized control
network-wide, coordinated, configuration and
visibility
network abstractions
and 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 flow
abstract configuration models
Config
Model
Topology
Model
configuration intent
operators
declarative API
configurationflow
configuration pusher
NETCONF, RESTCONF, JSON-RPC, ...
...
authoritative
config store
config
generation
device-level configuration
standard
models
vendor-neutral configuration models
generated
configuration instances
config
generation
authoritative
config storeapplication
NB APIs
Network OS
SB protocols
SDN stack
Streaming telemetry
network 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
validated
configuration
(proto / YAML)
encode for
transport to
devices (XML,
JSON, proto)
r/w to
native
config
device vendors
18
OC
YANG
models
configuration
generation
validation II
topology, 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

Bringing SDN to the Management Plane

  • 1.
    Bringing SDN tothe Management Plane (@scale) Anees Shaikh Google Technical Infrastructure
  • 2.
    Management plane challenges Programmabilityin the management plane OpenConfig -- community-driven development3 2 1 Agenda
  • 3.
    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
  • 4.
  • 5.
    Challenges of managinga 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
  • 6.
    Management plane isway behind ● proprietary CLIs, lots of scripts ● imperative, incremental configuration ● lack of abstractions ● configuration scraping from devices ● SNMP monitoring -- not “simple”
  • 7.
    Lack of visibilityleads 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
  • 8.
  • 9.
    SDN applied toconfiguration management SDN principle Applied to configuration separation of control and data authoritative configuration outside of devices; scraped config is not authoritative ! centralized control network-wide, coordinated, configuration and visibility network abstractions and 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
  • 10.
    Configuration • describes configuration datastructure 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
  • 11.
    Intent-based configuration flow abstractconfiguration models Config Model Topology Model configuration intent operators declarative API configurationflow configuration pusher NETCONF, RESTCONF, JSON-RPC, ... ... authoritative config store config generation device-level configuration standard models vendor-neutral configuration models generated configuration instances config generation authoritative config storeapplication NB APIs Network OS SB protocols SDN stack
  • 12.
    Streaming telemetry network statechanges 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
  • 13.
  • 14.
    OpenConfig ● Informal industrycollaboration 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)
  • 15.
    “The fact thatthese 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”
  • 16.
    INTERNAL: Google Confidentialand 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
  • 17.
    INTERNAL: Google Confidentialand Proprietary Models must be composed to be useful ● model composition framework is critical missing piece from existing model-building efforts
  • 18.
    Example configuration pipelinewith OpenConfig models configuration instance data (protobuf / YAML) validation I validated configuration (proto / YAML) encode for transport to devices (XML, JSON, proto) r/w to native config device vendors 18 OC YANG models configuration generation validation II topology, policies, constraints OC to/from native model
  • 19.
    OpenConfig progress ● BGPand 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
  • 20.
    Summary ● Time forthe 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
  • 21.
  • 22.