Sep 15, 2017

Intent-Based Networking Architecture Part 2: Examples of Rendered Configuration

This is the second blog in a three-part series on “Examples of Intent-Based Networking Architecture”.

In our first blog “Intent-Based Networking Architecture: Examples of Intent” we illustrated that an intent should have three distinct characteristics:

  1. Natural language, which is auditable, as the single source of truth for SLA and compliance purposes.
  2. Service-level, which allows you to manage the network as a system, vs. individual components.
  3. The what, not the how — so network engineers are elevated from how to configure vendor A devices, how to collect SNMP MIB ABC from device XYZ, and so much more.

You might ask immediately: What about the detailed configuration of each device? That’s the focus of this blog.

See this actual, detailed configuration for an Arista device:

Arista device configuration

If you want your intent rendered onto a different vendor device, you have a wide range of choices. All you need to do is to assign a different vendor’s device to your intent and let the network operating system re-calculate the configuration. While the syntax of the config may be different, the role or behavior of the device will be exactly the same.

Apstra AOS configuration options

The goal here is to decouple your intent from vendor-specific configuration syntax and procedures so you don’t spend your precious time hard coding your intent into static configurations.

In our final blog in this series, we will provide examples of “closed-loop telemetry”.