Data Models

This section introduces data models and helps you answer these questions:

• How should I structure the data I need to describe devices in my network?
• Should I describe devices or should I focus on network topology and services?
• Can I use device-level data to create device configurations while presenting high-level data models to the operators?
• How could I transform abstracted (high-level) network- and services data models into device-level data models?
• How could I integrate data model transformation into my automation workflow?

After you built your data model, you have to create data structures (device, link, network, service, or customer data) in a format readable by humans and machines, describe the data model for documentation and validation purposes, and store the data somewhere.

This section dives deep into presentation formats (XML, JSON, YAML), data description languages (including YANG), and data stores, from text files and Excel to NoSQL databases.

After mastering the data model-, model transformation-, and data store concepts, you're ready for one of the most important network automation topics: single source of truth.

The guest presentation by Marcel Wiget (Juniper) describes YANG data models, briefly introduces NETCONF, and shows how you can use OpenConfig or your custom data model (described in YANG) to configure Junos devices.

While configuring network devices with OpenConfig sounds really interesting, don't expect to be able to do it any time soon - the vendors are (as usual) very reluctant to add yet another layer of indirection on top of their already-bloated software.

David Barroso decided to fix that problem within NAPALM, and wrote a set of libraries (napalm-yang) that perform translation between OpenConfig (or any other) YANG data model and device configurations.

You won’t be able to follow the rest of this module without a thorough understanding of Ansible. If you haven’t completed the Ansible for Networking Engineers online course, please do it now, and focus on the data modeling part of DMVPN case study.

Access content

In this part of the Network Automation Use Cases webinar David Barroso walks you through layers of network automation abstraction: from abstracting vendor-specific APIs with NAPALM to abstracting device configuration differences, and finally abstracting device state into infrastructure data model.

Most of the intent-based systems are nothing more than a fancy orchestration system with an abstraction layer. This section describes the many levels of abstraction you can implement in such a system.

Orchestration systems with an abstraction layer usually use network- and services data models to describe the desired system functionality, and device (or node) data models to describe the target state of the system.

In every such system, someone has to perform the mapping between the high-level and low-level data models, and this section describes how you can do that with Ansible.

In another network automation use case Dinesh Dutt talked about automated data center fabric deployments. Focus on how simple his data model is and how he builds a whole fabric from just a few configurable parameters.

In the hands-on exercises you’ll build a data model for your network automation solution and store it in one or more YAML files.

Hans Verkerk guided us you through some easy-to-understand scripts written in Python. These scripts abstract Cisco IOS configurations into Python data structures, enabling you to query the data gathered from network devices using standard Python utilities in a simple but effective way.

Want to know even more about data models in network automation? You might enjoy these webinars and presentations.