Date post: | 27-Nov-2014 |
Category: |
Internet |
Upload: | anees-shaikh |
View: | 95 times |
Download: | 2 times |
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!