What Is Intent-Based Networking?

Whenever someone mentions intent-based networking I try to figure out what exactly they’re talking about. Not surprisingly, I get a different answer every single time. Confused by all that, I tried to find a good definition, but all I could find was vendor marketing along the lines of “Intent-based networking captures and translates business intent so that it can be applied across the network,” or industry press articles regurgitating vendor white papers.

This blog post is a summary of the introductory part of Intent-Based Networking section of Network Automation Concepts webinar. That webinar includes other aspects of intent-based networking like layers of abstraction, network-wide intent, intent validation and automated remediation.

The blog post was initially sent to the subscribers of my SDN and Network Automation mailing list. Subscribe here.

Next step: if we can’t find a good definition of what intent-based networking is, maybe we should define what intent is. Here’s what Merriam-Webster has to say on the topic:

Intent: a usually clearly formulated or planned intention.

Not exactly useful. So, what is an intention?

Intention: what one intends to do or bring about

To be fair, there are other more useful definitions, but you get my point: we’re pretty close to “recursion: see recursion”.

However, when reading vendor whitepapers, it seems most everyone who managed to move beyond fluff understands intent-based networking as telling the network what to do and not how to do it.

Now think about the way we deal with network devices. Did you ever tell a device how to do its stuff or did you tell it what you want to have done?

Unfortunately for tinkerers and fortunately for most networks we cannot tell the network devices how to do stuff, we can only tell them what we want to get done. For example, we tell a network device that we want OSPF running on a set of links, not how it should run OSPF or select the best paths.

Side note: every now and then there’s a networking engineer who’s pushing the devices beyond their design limits (example: running 1000 OSPF routers in an area, or redistributing the whole Internet routing table into OSPF), or trying to save his broken design by tweaking the way network devices do stuff… and thus the ever-more-convoluted nerd knobs are born.

To recap: like the network devices (apart from unmanaged hubs and cables) were always software-defined, the way we’re configuring network devices has always been intent-based. Intent-based Networking is thus as meaningless (as a term) as Software-Defined Networking.

However, that doesn’t mean that some of the ideas advertised by intent-based vendors are not useful. More about that in other blog posts in this series and in the Network Automation Concepts webinar.

9 comments:

  1. Intent based or software defined networking is too little nowadays. We define whole infrastructures with code (thousands of VMs, LB and DBs). Network is just a small piece in the puzzle. We don't see the network as a panacea. Write about IaC as you promised. It would be way more interesting than that intention thingy.
    Replies
    1. If you have thousands of VMs, then I'm assuming you already have hypervisor-based virtual networking, in which case you don't need any of this.
  2. Speaking as an operator, what I'm looking for in intent-based automation/orchestration is:

    Model-driven not syntax-driven. This makes rollbacks and multi-vendor support easier.

    Declarative (including "negative declarations" where anything that isn't intended gets deleted).

    Semantic error checking before the intent ever hits a device.

    Closed-loop, so the state of devices is constantly synchronized with the intent.
    Replies
    1. You wrote a very brief summary of the next few posts in this series ;) ... and I love the "negative declaration" concept, or should we call it "intent by omission" ;))
    2. BTW most of my points are motivated by experience with Ansible. After you use a tool for a while ideas for better tools tend to appear.
    3. Terraform for infrastructre provisioning and Ansible for configuration management are possible choices to consider. Alternatively consider server templating with Packer/Docker.
    4. @Wes: Agreed. Ansible sometimes feels like micromanagement gone wrong ;) We managed to squeeze a lot out of it in the network automation online course (including a lot of things you mentioned), but it definitely is a very low level tool. If you want to know more, contact me via email.

      Haven't seen anything better (yet) apart from high-end stuff like Cisco NSO, or potentially Apstra AOS (although that one still has ways to go).

      @Anonymous: as much as I love Terraform &co, and it's great for deploying full-blown application stacks, it doesn't solve provisioning of traditional network services (think L2VPN or L3VPN).
  3. Hi,
    The Apstra demo's look really cool. There seem to be nice blueprints available for a variety of scenarios in their GUI. However it looks like they will loose this edge if they interface with OpenStack/NSX Controller, as the GUI will be taken care by OpenStack/NSX. Is this a fair comment?

    Also do you think it will be reasonable to assume that there will be multiple configurations screens which operators/administrators will use? Use the existing tools for Compute/Storage and move to Apstra for network.

    Please let me know

    Sincerely,
    Arvind
    Replies
    1. "However it looks like they will loose this edge if they interface with OpenStack/NSX Controller, as the GUI will be taken care by OpenStack/NSX."

      That's an idea along the same lines as Cisco ACI/OpFlex/vSphere integration - too many moving parts and integration points. I understand why vendors keep pushing this stuff, but remain baffled as to why someone would be buying it ;)
Add comment
Sidebar