A few days ago Greg Ferro published an interesting post claiming DHCP is an example of intent-based networking (a bit less tongue-in-cheek than my “so is OSPF configuration” rant from 2017). BTW, so is RADIUS or TACACS+ ;)

He got quickly “corrected” by Phil Gervasi who loosely relied on Gartner’s definition of Intent-Based Networking, and claimed that an intent-based networking system should have three major components:

• Network abstraction;
• Continuous validation;
• Autonomous remediation.

That seems like a reasonable and useful set of requirements, but guess what - any decent routing protocol meets these three criteria… and so does vCenter with VMware Tools and DRS (although in server virtualization, not networking domain). The proof is left as an exercise for the devious reader ;)

Greg tried to save the day by trying to differentiate between automated- and autonomous intent stack (in which case a routing protocol would be an example of autonomous intent stack), but unfortunately you can’t win - like Software-Defined Networking, Intent-Based Networking is another fatality of Sturgeon’s Law with a meaningless name that a horde of well-paid marketers and industry analysts try to spin in 100 different ways hoping it will finally make sense to naive PowerPoint consumers.

We had systems with plenty of network abstraction decades ago. They were called Customer- or Service Management Systems, or Orchestration Systems, or Provisioning Systems.

Some of them included some sort of validation (Tail-F comes to mind), but we also designed networks in a way to make them autonomous and self-healing, reporting errors to the management system… and some of those management systems were able to perform pretty good root cause analysis in early 1990s.

If you wanted to add continuous validation and autonomous remediation to the mix, you could use tools like Cariden MATE… but nobody in their right mind allowed that tool to make automated changes to the network (or so Cariden’s engineers told me) - the tool would propose changes, someone would review them, and then they got pushed into the devices.

Those tools never had a fighting chance to be a big hit in the modern networking industry landscape: they tried to cope with never-ending MacGyverism of networking engineers, and they were not “disruptive” enough to excite VCs or IT vendors’ CEOs. Cariden was acquired for $141M, Tail-F for $175M, but a product implementing bridging over host-to-host tunnels at speeds barely exceeding 1 Gbps on modern x86 servers but branded with all the right buzzwords fetched a cool $1.26B.

So what’s the big deal with intent-based networking? After everyone realized SDN is an ill-defined lame duck, someone invented another random buzzword to get funding, VCs got a new hype balloon to invest in, and industry analysts were only too happy to have another category to draw quadrants in. A pure win-win-win scenario.

You can happily participate in that game and enjoy glitzy product pitches… or you can take the red pill and do your homework:

• Figure out what BUSINESS problem you’re trying to solve
• Is it a technology problem or a people/processes problem? You can never fix a broken process by throwing unproven technology at it.
• Can you solve the problem with existing tools?
• If not, what tools would you need to solve the problem?
• Even if you had those tools, would you be able to use them, or would you be back to square one due to people/processes?

Want to know more? Explore our Intent-Based Networking Resources or watch Intent-Based Networking section of Network Automation Concepts webinar.