Tractors, Cars, and the meaning of Intent-Based Networking
Distinguished Systems Engineer (DSE)
Technology, Innovation, Enterprise Networking, SDN
Intent-Based Networking (IBN) is a hot topic right now and as with many hot topics there is often confusion. Even though Cisco announced it a year ago at Cisco Live US, at this year’s event the most frequently asked question was still: “What is intent based networking?”.
Part of the confusion comes from the definition of intent itself. Dictionaries say intent is the notion of “purpose or design”. Marketers will say that intent in the network means “the network knows what to do and it runs itself”.
Network engineers, however, have a slightly different understanding and will tell you that the network has always been automated and self-driven. After all, the whole point of the sophisticated network protocols created back in the day was to optimize the use of multiple network paths, optimize application use of bandwidth (QoS) and automatically cope with link failures (routing). A single node may fail, but others will take over.
So why did we go from calling our network - which by definition has always had “intention” and “purpose” – Intent-Based Network? What changed?
Traditionally, the autonomous approach to networking has worked well where requirements did not change. It has also worked well where capabilities were constrained to a device, and did not involve multiple devices.
The challenge today is that the requirements and demands on the network are now changing by becoming more frequent (for example reacting to security concerns) and broader (think about Quality of Service, which requires some level of synchronization across many network devices).
Now, think about what it takes to configure all these devices. When scale and scope was smaller, we would typically use the Command Line Interface (CLI) instructions all network engineers know. However, as powerful as that language is, it’s also complex and expensive to deploy if you think about the time and highly skilled individuals needed. With devices growing by the second, this traditional way of networking became limited in face of the demand to scale and be operationally efficient.
This is where “intent-based networking”, as we now call it, comes in. The core principle here is abstraction, with a clear separation between what you would like to achieve and how it gets done.
Let me give you an example: driving a car. With an automatic transmission, the “what” is quite simple, for example move forward or backwards. The gear lever allows me to specify that. However, under the covers there is a lot going on, and the good thing is that I don’t need to understand how gear boxes work to drive a car. In networking terms, this would be our intent-based networking, and a simple expression such as “webex is business relevant” (intent) leads to a desired outcome without having to understand the intricate details that go behind the scenes.
Growing up on a farm, my first vehicle was a tractor with non-synchromesh gears. I had to learn to “double shuffle” or “double declutch” in order to match the speed so the gears did not crunch. I had to understand a lot about how gearboxes work in order to use it. This is the old, CLI-based networking.
From abstraction to integration: the next step in intent-driven networking
It takes powerful technology to mask such complexities. It took several decades with cars; nearly 30 years in networking. And just like in the agriculture or automobile industry, we are not stopping with the equivalent of automatic transmission. In fact, we’ve made tremendous strides in the last year to deliver this next level of intent in networking. This includes Cisco’s DNA Center, the heart and soul of this new intent-driven network. It provides a simple single pane of glass for all networking technologies, which translates intent into network commands and provides a view of how well the network system is working through Assurance.
While this is awesome, the tremendous insights DNA Center has on network performance were still isolated. Integration was the missing piece. This has now been addressed by opening up DNA Center to integrate with business applications through APIs. In my earlier driving analogy, this would be the integration we now see between the steering system and GPS in a tractor to accurately trace an optimal path through a crop, increasing efficiency and reducing waste.
In enterprise, one of the integrations the DNA Center platform provides is IT Service Management (ITSM). DNA Center can recognize a network event, open a ticket, augment that ticket with network context and even remediate the event, all while tying into the approval process of the ITSM tool.
DNA Center Platform provides a rich set of API, giving partners and customers complete control over the integration. For those that do not want to write code, there is also a set of pre-packaged “adaptors” into popular vendors. For example, ServiceNow in the ITSM space.
It is amazing to see how far we have come in a single year with a tremendously exciting year to come. Opening up DNA Center will lead to the next wave of automation and create opportunities for further integration and innovation.
Do I regret learning to double declutch and drive a tractor without power steering? Not like I had an option, but not at all. It gave me a lifelong appreciation for simplification and abstraction.