Apstra Blog

Intent-Based Networking Part 2: Examples of Rendered Configuration

Updated Sep 15, 2017

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

In our first blog “Intent-Based Networking: 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:

detailed_config.jpg

 

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.

available_devices_for_config_changes.jpg

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

 

Follow Apstra