Skip to main content

Four steps to understanding intent based networking – and six pitfalls to avoid

(Image credit: Image Credit: Ra2Studio / Shutterstock)

We humans are brilliant at pattern recognition and, especially with training, we can be very good at devising clever solutions – what we call “thinking outside the box”.

What we are not so good at are mundane, repetitive tasks over a long period. We get bored and make mistakes.

Any project begins with a vision of what it is intended to achieve, its objective. But if the project is highly complex and involves multiple changeable components, then it is too easy for people to get bogged down in the detail and lose track of that original intent. This is a very inefficient way to run a business, and one that digital transformation is intended to address.

Boeing 777 pilots begin with a clear intent: to fly their craft safely on schedule to the expected destination. The flight might take hours but apparently, on an average trip, they only spend about seven minutes manually flying the plane. They input the flight parameters (intent), and the plane’s internal systems translate that expressed intent into all the operational minutiae necessary to complete the flight. But what about unpredictable changes such as weather shifts? Throughout the journey, the auto-pilot constantly adjusts to maintain compliance with the original intent.

The 777 pilot isn’t eliminated, and the pilot’s role isn’t trivial. On the contrary, the pilot is relieved of the simple minute-to-minute tasks and can better apply his expertise to the overall mission. Unexpected bad weather, flight path restrictions or system failure, and the pilot can always take over. Increasingly, though, the system can also take over in the event of a pilot error.

Intent based networking

That too is the essence of Intent Based Networking (IBN). The company’s business objectives will make demands on the network that the networking team will express as a technical intent. This might be something along these lines:

  1. Deploy an L2 network interconnecting VMs for application X in the data center.
  2. Ensure 3:1 oversubscription or better on all links.
  3. Isolate the network from all other tenants in the data center.
  4. Provide external access through routers Y1 and Y2, applying security policy Z.

Before the advent of IBN, this would be the start of a very long design process that involves reconciling diverse hardware, planning configuration and building a blueprint for installation. Instead IBN takes over all the mundane tasks of creating that blueprint. Automation completes days of planning in minutes and eliminates the common mistakes that human designers make.

The installation takes place relatively seamlessly, because the configurations have been reconciled for the actual hardware and modelled for compatibility. But IBN does not stop there: when the system is up and running IBN will continue to monitor the network’s operation in real time and ensure that it does not deviate from the intent. The network is now its own auto-pilot.

Four steps to true IBN

  1. Automation alone is not IBN, but it is a fundamental part of IBN. Some single vendor systems provide a measure of automation that can generate configurations based on declarative statements and push them out to network nodes. This is helpful, but it could ultimately lead to a piecemeal conglomerate of many different automated parts.
  2. True IBN depends on creating and maintaining a single source of truth that not only stores the full system intent but also recursively updates the actual state of the network as an accessible database. This enables comparison between the way the network is operating, and the way it is intended to operate. It also provides answers to questions such as: “What is the status of interface X on node Y?” You can also ask potential questions such as “What would be the impact on bandwidth utilization if I take node Z offline?”.
  3. Real-time change validation looks at actual network status in real time and compares it with expected operation and intended operation. This will identify and flag any change from normal behavior – which could be caused by overload, system fault or cyber-attack. Real-time change validation means continuous verification of network state against expressed intent.
  4. Self-operation is the current pinnacle of IBN. Given a single source of truth and the ability to compare network status in real time, it becomes possible to incorporate deep analytics, machine learning and expert system techniques to enable the system to not only detect changes in status but also to analyze their significance, then either flag a specific warning or actually adjust the configuration to return the system to its intended status. While steps 1 and 2 provide intent fulfilment, Step 3 provides self-operating intent assurance. This frees operational staff members from those boring low-level, tasks and empowers them to monitor your network holistically. Operations that used to take hours or days are now performed in seconds, giving you an adaptive, agile network.

Does that sound good? It should do, because it really is good. Experience has demonstrated that IBN can:

  • Reduce time to delivery by 90 percent.
  • Eliminate 85 percent of all outages by in-depth verification before deployment.
  • Lower OPEX by up to 83 percent.
  • Lower capital expenses (CAPEX) by up to 60 percent.
  • Lower mean time to resolution by 70 percent.

Six pitfalls to avoid

You probably can’t wait to get going, but please just wait while we offer some necessary cautions.

  1. Don’t start with hardware
    Smart network and network service design should always begin with intent.
  2. Stipulate your business intent.
  3. Then design the services that will fulfil that intent.
  4. Then design a network to support those services.
  5. Only then do you shop around for the vendors offering the capabilities that support the network you designed.

IBN is fundamentally brilliant tool because it starts where you start — with business intent. As you work down to the specifics, you leverage the industry best practices integrated into reference designs, then network and service abstractions, and only then consult inventory to fit what you have or assess what’s available to you.

2      Avoid vendor lock-In

Starting with intent goes beyond the initial design stage and informs the whole network life cycle. When you deploy new services or modify your network, you again want to start with the intent, as above, and then let IBN take you to the best vendor (and vendor model) that supports the intent. Even if you’re a single-vendor shop, IBN keeps you informed of all options available to you.

3      Don’t be dazzled

As a major industry trend, IBN is a must-have marketing buzz word and almost everyone will claim an IBN solution – it’s called “intent washing”. Look back at the four steps above and make sure that the system you are considering does indeed meet the criteria for true IBN. You may not yet need full step 3 autonomous operation, but at least be sure that what you get really will match your business intent.

4      DIY with caution

DevOps integration of development and operations is another important trend. It has pushed development skillsets such as automation tools and programming into operations. But there is a risk of becoming too reliant on operations tools built in-house. Good design may ensure a superb fit to the specifics of your network, but will it evolve as your network changes? When a vendor makes changes, how big a challenge will it be to adapt to those changes? And are you sure your in-house tools truly follow industry best practices?

5      Avoid big data swamps

“Big data” telemetry can sap major resources to extract the data you need, and then swamp you with too much stuff to sift through for meaningful information. This scenario is true whether querying the network in a steady state, setting performance thresholds, or trying to get at the root of a problem. IBN is essential for reducing data analyses from days to minutes. It delivers a more efficient, economical, and agile network, and frees up key resources for more important work.

6      Don’t stick with old school thinking

Top-tier architectural teams are often wasted on firefighting instead of strategic planning. Frontline operations can become bogged down in data searches and discrete element management instead of stepping back to view the big picture. IBN makes it possible to think big. And get bigger.

Mansour Karam, Founder and President, Apstra