A session in the DevNet Zone at Cisco Live, Berlin. The need to automate interactions with the network is ever more obvious. We have a plethora of tools built around legacy technologies, such as SNMP and screen scraping, but these are coming to the end of their useful lives. In this introductory talk we will look at how YANG data models are becoming ever more pervasive across networking, and how they may be used to more efficiently automating network configuration and operational management.

2. Introduction to Data Models
and Cisco's NextGen
Device-Level APIs
Einar Nilsen-Nygaard
Principal Engineer, Cisco

3. • Why network programmability matters
• Why data models?
• Industry & Cisco approach
• Tooling
• Conclusion
Agenda

4. 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

5. SDN Controller
Integration
Open SDN
Controller
Inventory / Topology
Configuration Mgmt
Access Control
Script Automation
DevOps
Custom
Application
Service Provisioning
Fault Mgmt
Configuration Mgmt
Application
Integration
OSS/BSS
Integration

6. 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 Friendly RFC3535
May 2003

7.  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?

8.  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?

9. Cisco’s Approach
9

10. 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

11.  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

12.  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

13.  Vendors such as Brocade, Cisco, YumaWorks:
 https://github.com/YangModels/yang/tree/master/vendor
Vendor-Specific

14. 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

15. Tooling
15

16.  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

17.  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

18.  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

19.  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

20.  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

21.  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

22. Thank you