A taxonomy of Intent-Based Networking (IBN)

You have probably heard all sorts of claims by various vendors and solutions that they are providing or supporting Intent-Based Networking (IBN), yet there is a wide range of capabilities that are all very confusing.

One way to make sense of this is to apply a “maturity model” like the one used to classify the maturity level of RESTful web services implementations. The Richardson Maturity Model divides capabilities of RESTful web services into levels, starting from 0 and going up as the maturity of the implementation increases. Just like IBN, REST had received its fair share of hype. While the REST principles were clearly defined in Roy Fielding’s dissertation, in practice the REST label was attached to implementations with wildly varying levels of conformance to the original principles, starting from anything that had the words “HTTP” and “JSON” in it to full blown “hypermedia as the engine of application state.”

The formation of a coherent model helped greatly in understanding the fundamental differences between the implementations in the wild that had the REST label slapped onto them.

Level 0 IBN: gradual introduction of capabilities

As IBN matures it is expected that there will be early implementations that do not have all the required capabilities initially implemented. Capabilities that may be present in these Level 0 systems include the ability to:

• Generate device configurations from declarative specifications. For example: scripts running Ansible modules or other declarative libraries such as NAPALM.
• Support a heterogeneous infrastructure.
• Ingest real-time network status in a protocol and transport-agnostic way.

The main capability missing at Level 0, which is the requirement for the next level, is the presence of a single source of truth that contains both intent and operational network state. This is the key requirement that enables reasoning whether or not the intent has been met and is therefore a fundamental aspect of a mature IBN implementation.

Level 1 IBN: a single source of truth

An implementation classified as Level 1 implements a single source of truth containing the intent and the network operational state. It contains data and state artifacts related to all aspects of a network service lifecycle: design, build, deploy, and validate. It is very important to emphasize that this single source of truth contains both the intent and the context rich operational network state. This clarification is important as in the absence of stored intent, it would be impossible to validate that the business intent has been met. In the absence of context it would be impossible to reason about the impact of operational failures on business objects. It would also be impossible to reason about new business rule changes (For example, can this change be implemented without impacting existing business objects and services?). To make an analogy, if you were playing in a symphonic orchestra you would look at the conductor (intent), as well as listen to other players (operational state), in order to produce the most fitting performance of your instrument.

Next, how do you test whether an implementation has a single source of truth? It is fairly simple: there should be an API that allows you to query the single source of truth to get the answers. For example, there should be an API that answers the question “What is the link utilization on all the links that carry traffic of customer Pepsi?” or “Which customers will be impacted if link x fails or gets congested?”

Now imagine how you would answer these questions without a single source of truth. You would have to:

• Consult a network map:
  • Verify it reflects the current state of the network physically
  • Verify the operational state of all the links
• Determine how the tenant is configured:
  • Identify where the end points reside
  • Overlay the end points on the network map in step 1
• Collect all the data:
  • Check the NMS for all needed counters from the union of step 1 and 2
  • Calculate by hand the effect of the reflowing of traffic for a link failure

… and stitch together the answer yourself, or write a script, or hire professional services to connect the dots. The need to stitch together the answer yourself indicates you are dealing with a Level 0 system. Getting the answer should be the job of IBN, especially as it forms the foundation for getting to the next level of maturity.

In summary, Level 1 introduces the notion of a single source of truth that ties intent and operational state together and can therefore be used to reason about whether the intent has been met. Consequently, in the absence of a single source of truth, the solution has little to do with IBN.

Level 1 can give you answers to important questions about the state of your intent and your infrastructure. The next level is having IBN ask the right questions on your behalf and do it at the right time.

Level 2 IBN: real-time programmatic reasoning of change

Level 2 addresses an important capability: real-time validation that intent is met.

Change is inevitable, and the fundamental task on IBN’s plate is how to deal with it. One set of changes comes from the operator in the form of a business rule change or policy change. Even more challenging ones (as you don’t control them) are changes coming from the infrastructure in terms of operational status changes or failures. If something failed and you didn’t ask a question, you will not know about it.

The real-time aspect comes in the form of real-time notification in response to a subscription that an event of interest took place. If an IBN implementation is doing batch processing at scheduled intervals it is not real-time. Batch processing may be perfectly suitable for some use cases and completely inadequate for others.

Subscription is also a mechanism for scaling the complexity by partitioning the problem domain into manageable chunks. You don’t want everyone notified of every change. You want specialized behavior implemented by its own module and by subscribing only to a subset of events that are relevant to this specific behavior.

While real-time is the meat of this requirement, “programmatic reasoning” also deserves attention as it is about how the validation is implemented. Let’s give a few examples to introduce this concept, in the context of validation.

Let’s say a business rule change like ‘add a new tenant and/or security zone’ was submitted to an IBN system. Before making the change, the IBN system may want to query the following:

• Does the request conflict with any existing policy?
• What resources (IPs, VNIs) should be used?

Another example is an operator who wants to put one of the leaf switches into maintenance mode. Before performing the request, the IBN system may want to check:

• Is this an appropriate time window for this action?
• Are there any other leafs in maintenance mode? How many?
• Is there a mission critical app running on servers attached to this leaf switch?

All of the points noted involve some sort of query against the single source of truth, containing resource allocations, policies, and operational state. The query response is processed by a callback function. “Programmatic reasoning” is a requirement that all these specialized behaviors are implemented using a standard, repeatable pattern. While most systems can be implemented in software, we are insisting on the need for testable, maintainable software. How do you ensure this with your IBN vendor? Simply ask to add a few specialized behaviors and see how repeatable and digestible that process actually is.

Programmatic reasoning is also an enabler for creating more sophisticated functions such as root cause analysis, identification of complex symptoms (“Is my total fabric ECMP imbalanced?”) etc. … Being at least Level 2 is the only reasonable way to implement IBN requirements in a scalable and extensible way.

Level 3 IBN: corrective actions

While validation closes the loop between the intent and operational state by providing observability, the last step is doing something about what is being observed, if and when it is applicable. This ultimate level takes IBN on a path to self-operating networks. This step does not appear to be a huge technological challenge given the supporting features in the first three levels, but it is expected that current operational practices and (understandably) human reluctance to relinquish control to software will throttle the adoption. As maturity of IBN solutions improves, so will the acceptance of the capabilities offered at this level.

Completeness and scale

In addition to solutions being classified according to maturity model levels there may be other constraints present in the solution that need to be taken into consideration. Constraints you should give a second thought to when evaluating an IBN solution include that the:

• Solution may be vendor specific
• Solution may be tailored to a specific reference architecture with no intent to make it generally applicable
• Solution may focus on a subset of network service lifecycle phases (a subset of design, build, deploy, validate)
• Solution may be focused on specific function (security, or reachability, etc. …)
• Solution’s single source of truth may be focused on intent only or operational state only
• Solution may be applicable only at limited scale

If any of these constraints are present they could be added as a qualifier to the classification, i.e.:

• Level 1 (reachability only)
• Level 2 (vendor x only, deployment only)

When constraints are present it may be important to assess how likely are they to be removed in the future as the implementation evolves? In other words, is the implementation likely to remain a silo applicable to constrained domain space, or is it going to break the silo and remove the constraint? Also note that putting multiple silos as a “bundle” usually reduces the maturity level of the composite to Level 0 as bundling fundamentally breaks a “single source of truth”. More often than not, constraints indicate that certain assumptions have already been made early in the design and modeling process and removing these constraints later may be a challenge. Therefore, understanding an implementation and its ability to evolve is crucial.

You can make sense of the different capabilities of the various offerings that claim IBN by mapping each into one of the levels we have identified. Once you fit an offering into a level, you can understand the limitations from a capability standpoint. The next step is evaluating an offering on how complete and scalable the offering is at that level. But if you are really looking to deploy IBN, as you should be, you can use the levels to think about what capabilities you need for your network and what scale and scope you require for these capabilities.

You also may want to consider the ability of the chosen solution to evolve. Phenotypic plasticity refers to an ability of a code in our DNA to have variability and respond to changes in the environment. For example, in response to availability of more food and increased activity, mammals can gain muscle mass whereas snakes cannot. In turn, you should check your IBN vendor’s DNA for this kind of plasticity. If you buy yourself a snake, don’t expect it to grow muscle in response to a new requirement, though your vendor may try to sell you a bigger, more muscular snake. If you are not into building a snake farm and if you need to adapt to a change in the environment and stay competitive by keeping the options open – buy yourself a mammal.