Declaration of Intent!

After presenting IP Fabric at Networking Field Day 23, a number of Twitter threads started probing at the idea of Intent-Based Networking (IBN) - is it simply a marketing term that vendors use to sell more gear or does it have a deeper meaning? And what impact does it have on the network team? Does it automate them out of a job?

The Problem IBN Tries to Solve

It’s safe to say that every modern business depends on its IT, and the network provides the underpinning to all the systems on which we rely. Business needs IT to just “be”. It should be permanently available, supporting business process with a minimal operational overhead. But it’s obvious to anyone in IT just how big a stretch that is due to many factors, not least:

• Complexity. We often hear talk of how the latest technology or product can simplify our IT and our networks. But we do need to face the fact that complexity is often completely necessary! We typically manage and maintain multiple networks in an organisation and the interactions between them. These would include one or more office or campus LANs, data centre(s), WAN, and Public Cloud.  
• Technical Debt. In a recent blog post, Terry Slattery described technical debt as “the accumulation of aging devices, old operating systems, unnecessary or partial configurations, and variances in deployment”. Need I say more? Every network environment has at least an element of this. Think of the “nearly complete” migration project; the mergers that never completely rationalised systems and applications?
• Implementation Quality. Time and project pressures on implementation teams invariably lead to cut corners in project delivery. The most common result is incomplete documentation and gaps in monitoring and support cover at handover time.
• Manual operational processes which have a requirement to harvest network data before progress can be made. This can be everything from ITIL-based change control, to troubleshooting incident tickets, to validating support contracts
• Regulatory compliance may be a more recent addition to the operational overhead of many organisations. The regular wholesale audits, followed by remediation programme, is becoming an annual feature of most organisations’ IT operations.

Network Automation

Automating regularly occurring network tasks helps reduce the operational overhead of running the network, of course. You might use controllers or scripts, templates, zero-touch provisioning and automated change mechanisms. There are plenty of benefits in being able to treat a network domain as a macro entity and allow the micro tasks that are required to maintain the environment be taken care of by automated processes.

However, it's vital that we fully understand the networks we build. This ensures that the automation platform is deploying configuration with the expected outcome. Configuration still happens in a network domain on a box-by-box basis. The process uses configuration detail from a knowledgeable and experienced network engineer. In reality, the automation system functions like a fast, consistent network analyst. It makes and tests changes and fetches data about operations, based on rules defined by its "superiors"!

Intent-Based Networking

IBN takes the automation approach to the next level. Given the business intent for the network, you first translate it to a set of technical capabilities, then:

1. render it in configuration across different network domains;
2. verify that state of the network correctly reflects intent; and
3. provide a feedback mechanism to fix configuration should the network drift from that intent.

What we’re really doing here though is subtly evolving the roles of the network architect, designer and engineer.

The business intent may include such abstract ideas as “make sure that my critical applications are always available”. The traditional approach would involve a network architect in translating that intent to some design criteria: “always use High Availability, no SPOFs, converge my routing protocol within x seconds, define QoS across the network” and so on. A network designer will then take those principles, and looking at each network domain in turn, consider how to turn out specific bills of material, Layers 1, 2 and 3 topologies and designs using specific vendor platforms. The network engineer would finally deploy this. They would turn the designs into actual configuration, and then manage and maintain the resulting network.

How does IBN work?

IBN automates much of this process, taking business intent and delivering a self-regulating, self-healing network environment. 

It centres on a “Source of Truth” (SoT) – a picture of the network as it is intended to look, developed from the business intent using logic defined by the network architects and designers. It is then used as a central reference point for all intended configuration data – often referring to other “Systems of Record” as definitive reference sources where necessary.

Updating intent in the SoT triggers orchestration workflows to render the configuration in the different network domains. These configurations might include organisational or industry Best Practice templates, security policy data or specific network domain detail to support the intent. And typically the orchestration workflows then kick off automation tasks in controllers or as scripts to interact with different sets of network devices, potentially from different families from different vendors. Subsequently, they might also update policy engines which devices are using to refer to without having to keep local copies of configuration or policy.

Assurance workflows are built first to harvest state information from the network devices and controllers. They then analyse that data to ensure that they are meeting the intent.

And if intent is not being met, the assurance element then triggers a feedback loop into the orchestration platform to update configuration through the automation layer.

Sounds great – where do I sign?

There are of course a few words of caution.

1. Without the full visibility of the entire network, it simply isn’t possible to deploy any form of IBN environment. The information about how networks are configured, which technologies are in use and how the different network domains interact, in particular, becomes vital to making sure that orchestration workflows can be built which have the desired effect;
2. Building an effective and definitive Single Source of Truth that is able to hold (or proxy for) the answers to any questions about intended state is key. Once established, it becomes the one point of reference for all intent. And keeping it accurate is vital;
3. Network architecture, design and engineering roles are still key to this. The whole venture will fail without:

• the ability to translate business intent to technical capabilities;
• the design nous of knowing that to deliver a certain capability, then certain topologies and configurations will be required; and
• the engineering knowledge to bring deep configuration knowledge and experience to the templating, and troubleshooting should the software fail.

And so you can see, the network architect, designer and engineer are still key - they simply demonstrate their knowledge and experience in different ways.

How can IP Fabric help?

As we mentioned in an earlier post, IP Fabric is not well-positioned as the SSoT for intent, simply because the product focus is on being the informational reference for the actual network state. 

IP Fabric can sit squarely at the heart of your intent-based networking ecosystem however. As it provides full inventory, configuration and state visibility of the entire network, it then becomes well-placed to serve as the System of Record for those elements. It would be used to carry out an initial population of the Source of Truth, and then as a regular source of true-up data to ensure that the SoT genuinely represents the active network.

As IP Fabric is already harvesting all the network data, it is in a great position to begin carrying out the assurance elements of the IBN system. We would define rules in IP Fabric that validate elements of configuration and state, which are checked at every snapshot. Rules are not only created through the UI but also through the API. This means that they can then be pushed to the platform from an agent acting for the Source of Truth. Webhooks can then be fired from IP Fabric at calculation of those intent verification rules, to provide a feedback mechanism to the orchestration platform should intent not be met.

The real beauty of using IP Fabric with its complete network database and open API is that it can then serve as a reference source for whoever else needs that network data. The same system operating as part of the IBN platform could thus be used to keep monitoring platforms up to date, feed data to ITSM tickets at creation time, and later be queried through slash commands in Slack.

And so, the network engineer already has all the detailed configuration and state data they need to maintain, troubleshoot and deploy the networks they run. The network designer has an understanding of inventory, and topology relatinships at all layers. And the network architect can then get a picture very quickly of the current state of the interoperation of the network domains to help plan for transformation.

Note, the original version of this article appeared as a blog post at: https://ipfabric.io/blog/declaration-of-intent!/ (opens in a new tab)

If you have found this article helpful, please follow our company’s LinkedIn or Blog, where more content will be emerging. If you would like to test our solution to see for yourself how IP Fabric can help you manage your network more effectively, please contact us through www.ipfabric.io.