introduction to data models & cisco's nextgen device level apis: an overview

Introduction to Data Models and Cisco's NextGen

Device-Level APIs

Einar Nilsen-NygaardPrincipal Engineer, Cisco

• Why network programmability matters

• Why data models?

• Industry & Cisco approach

• Tooling

• Conclusion

Agenda

Why Network Programmability Matters

0

100%

67%

Source: Forrester

CAPEX OPEX

33%

0 10 100 1000

Compute Networking

Seconds

Source: Open Compute Project

Network Expenses Deployment Speed

SDN ControllerIntegration

Open SDN

Controller

Inventory / Topology

Configuration Mgmt

Access ControlScript Automation

DevOps

Custom

Application

Service Provisioning

Fault Mgmt

Configuration Mgmt

ApplicationIntegration

OSS/BSSIntegration

Requirements of NextGen Config Management

Easy to Use

Separation of Configuration and Operational Data

Lots of Tooling

Accessible Format

Error Checking

Backup/Restore Capability

Human and Machine FriendlyRFC3535

May 2003

Separation of models from protocols and encodings

Devices become self-describing: Including definition of constraints

We can apply tool chains: Becomes simpler to generate API language bindings

Becomes simpler to setup data transformation pipelines

Easier to add new protocols and encodings

Why Data Models?

YANG – https://tools.ietf.org/html/rfc6020

Interface protocols today:

NETCONF – https://tools.ietf.org/html/rfc6241 Evolution of original NETCONF, encompassing YANG data models

RESTCONF – https://tools.ietf.org/html/draft-ietf-netconf-restconf-09

…and any new protocols or encodings...

Which Data Modeling Language?

Cisco’s Approach

9

Data Model Taxonomy

10

• Standard definition (IETF, ITU, OpenConfig, etc)

• Compliant with standard, e.g. “Policy”

• ietf-diffserv-policy.yang,

• ietf-diffserv-classifer.yang,

• ietf-diffserv-target.yang

Open

Industry

Standards

• Vendor-specific definition

• Common across >1 vendor platform• E.g. on Cisco platforms

there may be an OTV model common across IOS-XE and NX-OS

Vendor

Common

• Vendor-specific definition

• Unique to specific vendor platform or OS• e.g. IOS-XE-specific BGP

extensions

Vendor

Specific

IETF:

https://github.com/YangModels/yang/tree/master/standard/ietf/RFC

Range of basic models standardized Interfaces, notifications, IP address management, etc.

More model in draft status under development: Inventory, ACLs, routing protocols, L2VPN, MPLS, Segment Routing, etc.

IEEE & MEF also spinning up initiatives in areas such as service modeling, 802.3, 802.1, etc.

Open Industry Standards

OpenConfig:

https://github.com/openconfig/public/tree/master/release/models

Range of basic models:

Interfaces, ethernet, link agg, routing protocols, etc.

More models focused on OpenConfig member use cases:

Optical, telemetry, inventory, etc.

Open Industry Standards

Vendors such as Brocade, Cisco, YumaWorks:

https://github.com/YangModels/yang/tree/master/vendor

Vendor-Specific

Benefits:

Developers can use open models where available, giving commonality across platforms

Native models available for functionality not yet in open models

Platforms can advance native models as required while still maintaining open model compatibility

Native & Open Models

Open Models

Platform Native Models

Platform Config & Oper Data Stores

Map

Client Application

Tooling

15

pyang (open source)

pip install pyang

https://github.com/mbj4668/pyang

goyang (open source)

https://github.com/openconfig/goyang

YANG Design Studio (open source, AT&T)

https://github.com/openconfig/yang-design-studio

YANG Schema Tools

pyangbind (open source)

pip install pyangbind

https://github.com/robshakir/pyangbind

JNC (open source)

https://github.com/tail-f-systems/JNC

ODL Yangtools (open source)

https://github.com/opendaylight/yangtools

Code Generation Tools

ncclient (open source)

pip install ncclient

https://github.com/ncclient/ncclient

libnetconf (open source)

https://github.com/CESNET/libnetconf

JNC (open source)

https://github.com/tail-f-systems/JNC

NETCONF Libraries

XSLT, various language bindings:

Ruby – “nokogiri”

Python – “lxml”, “ElementTree”

Java – “Xalan”, “SAXON”, etc.

JOLT, JSON-to-JSON transformation

http://bazaarvoice.github.io/jolt/

Dozer, a Java Bean to Java Bean mapper

Combine with something like JAXB and JNC

http://dozer.sourceforge.net

JSON/XML Transformation Tools

netopeer (open source) https://github.com/CESNET/netopeer

ConfD Basic (freemium) https://developer.cisco.com/site/confD/

MG-Soft (commercial) http://www.mg-soft.com/mgProductsNetConf.html

YANG Forge (open source) https://www.npmjs.com/package/yangforge

Yang Explorer (open source) https://github.com/CiscoDevNet/yang-explorer

More Offerings

Momentum building behind data models for device and network layers

Vendors and operators unifying behind open YANG models

Broad availability of YANG data models at device layer a reality

Community investing in tooling built around YANG models

Easy for users to transition to models

Conclusion

Thank you