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.\nOne 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\u2019s 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 \u201cHTTP\u201d and \u201cJSON\u201d in it to full blown \u201chypermedia as the engine of application state.\u201d\nThe 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.\nLevel 0 IBN: gradual introduction of capabilities\nAs 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:\n\nGenerate device configurations from declarative specifications. For example: scripts running Ansible modules or other declarative libraries such as NAPALM.\nSupport a heterogeneous infrastructure.\nIngest real-time network status in a protocol and transport-agnostic way.\n\nThe 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.\nLevel 1 IBN: a single source of truth\nAn 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.\nNext, 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 \u201cWhat is the link utilization on all the links that carry traffic of customer Pepsi?\u201d or \u201cWhich customers will be impacted if link x fails or gets congested?\u201d\nNow imagine how you would answer these questions without a single source of truth. You would have to:\n\nConsult a network map:\n\nVerify it reflects the current state of the network physically\nVerify the operational state of all the links\n\n\nDetermine how the tenant is configured:\n\nIdentify where the end points reside\nOverlay the end points on the network map in step 1\n\n\nCollect all the data:\n\nCheck the NMS for all needed counters from the union of step 1 and 2\nCalculate by hand the effect of the reflowing of traffic for a link failure\n\n\n\n\u2026 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.\nIn 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.\nLevel 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.\nLevel 2 IBN: real-time programmatic reasoning of change\nLevel 2 addresses an important capability: real-time validation that intent is met.\nChange is inevitable, and the fundamental task on IBN\u2019s 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\u2019t control them) are changes coming from the infrastructure in terms of operational status changes or failures. If something failed and you didn\u2019t ask a question, you will not know about it.\nThe 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.\nSubscription is also a mechanism for scaling the complexity by partitioning the problem domain into manageable chunks. You don\u2019t 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.\nWhile real-time is the meat of this requirement, \u201cprogrammatic reasoning\u201d also deserves attention as it is about how the validation is implemented. Let\u2019s give a few examples to introduce this concept, in the context of validation.\nLet\u2019s say a business rule change like \u2018add a new tenant and\/or security zone\u2019 was submitted to an IBN system. Before making the change, the IBN system may want to query the following:\n\nDoes the request conflict with any existing policy?\nWhat resources (IPs, VNIs) should be used?\n\nAnother 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:\n\nIs this an appropriate time window for this action?\nAre there any other leafs in maintenance mode? How many?\nIs there a mission critical app running on servers attached to this leaf switch?\n\nAll 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. \u201cProgrammatic reasoning\u201d 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.\nProgrammatic reasoning is also an enabler for creating more sophisticated functions such as root cause analysis, identification of complex symptoms (\u201cIs my total fabric ECMP imbalanced?\u201d) etc. \u2026 Being at least Level 2 is the only reasonable way to implement IBN requirements in a scalable and extensible way.\nLevel 3 IBN: corrective actions\nWhile 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.\nCompleteness and scale\nIn 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:\n\nSolution may be vendor specific\nSolution may be tailored to a specific reference architecture with no intent to make it generally applicable\nSolution may focus on a subset of network service lifecycle phases (a subset of design, build, deploy, validate)\nSolution may be focused on specific function (security, or reachability, etc. \u2026)\nSolution\u2019s single source of truth may be focused on intent only or operational state only\nSolution may be applicable only at limited scale\n\nIf any of these constraints are present they could be added as a qualifier to the classification, i.e.:\n\nLevel 1 (reachability only)\nLevel 2 (vendor x only, deployment only)\n\nWhen 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 \u201cbundle\u201d usually reduces the maturity level of the composite to Level 0 as bundling fundamentally breaks a \u201csingle source of truth\u201d. 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.\nYou 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.\nYou 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\u2019s DNA for this kind of plasticity. If you buy yourself a snake, don\u2019t 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 \u2013 buy yourself a mammal.