Petr Ankudinov made an interesting remark when I complained about how much time I wasted waiting for Cisco 8000v to boot when developing netlab device configuration templates:

For Arista part - just use AVD with all templates included and ANTA for testing. I was always wondering why netlab is not doing that.

Like any other decent network automation platform, netlab uses a high-level data model (lab topology) to describe the network. That data model is then transformed into a device-level data model, and the device-level data structures are used to generate device configurations.

This diagram from a blog post I wrote almost exactly five years ago nicely illustrates the concept¹:

Any network automation platform has to deal with three challenging questions:

1. What high-level data model will you use to describe the network and network services?
2. What data model will be used to describe device data?
3. What mechanism will be used to configure network devices?

There are high-level data models describing network services (IETF working groups produced plenty of them), but they tend to be a union of all possible nerd knobs ever dreamed of and thus way too complex for what we were trying to achieve. Compare, for example, the IETF EVPN YANG data model² with the few parameters we use to configure baseline EVPN functionality³. Using a select few high-impact parameters per technology/protocol seemed like a much better option.

Selecting a device data model was also easy. As we wanted to support a very large number of different platforms with netlab, we couldn’t rely on cool kids like OpenConfig or IETF YANG data models; too many devices still don’t support them. Furthermore, these data models are either focused on the needs of their creators (OpenConfig) or represent the least common denominator of humming consensus⁴ (IETF). They might thus not contain all the parameters we might care about. Finally, even though a device might implement a data model, it doesn’t necessarily implement all its nuances (data model augmentation is part of the YANG RFC). The only sane choice seemed to be a data model that is as simple as possible while still covering the parameters we need.

Finally, the configuration mechanism. We try to be as flexible as possible. Most devices are configured with device configuration snippets; we use bash scripts with some Linux-based containers or VMs, JSON-RPC for SR-Linux, and gRPC for SR-OS⁵. In all cases, we use Jinja2 templates to transform our device-level data into configuration snippets or JSON⁶ data structures.

Could we use our approach with Arista AVD? Sure, but we’d either have to adopt their data models, which would make even less sense (considering our multi-platform focus) than using IETF data models, or transform our device data into Arista AVD device data, and then use Arista’s configuration templates to generate configuration snippets.

Likewise, we could have a template that would transform our device data into OpenConfig- or IETF-defined device data. Unfortunately, we’d still have to check whether the transformation is done correctly and whether the transformation results work as expected on network devices, so we’d still be limited primarily by how fast the virtual devices boot (which, in Arista’s case, is not a bottleneck at all – I love their containers⁷).