The document presents an introduction to data models and Cisco's APIs, emphasizing the importance of network programmability and the separation of configuration from operational data. It highlights Cisco's approach to data models including compliance with industry standards like YANG and emphasizes the development of tooling to assist in working with these models. The conclusion notes the increasing adoption of open YANG models across vendors, facilitating easy transitions for users.

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