By Alan Zeichick
Tech Editor, NetEvents
With lots of inexpensive, abundant computation resources available, nearly anything becomes possible. For example, you can process a lot of network data to identify patterns, identify intelligence, and product insight that can be used to automate networks. The road to Intent-Based Networking Systems (IBNS) and Application-Specific Networks (ASN) is a journey. That’s the belief of Rajesh Ghai, Research Director of Telecom and Carrier IP Networks at IDC.
Ghai defines IBNS as a closed-loop continuous implementation of several steps:
- Declaration of intent, where the network administrator defines what the network is supposed to do
- Translation of intent into network design and configuration.
- Validation of the design using a model that decides if that configuration can actually be implemented,
- Propagation of that configuration into the network devices via APIs.
- Gather and study real-time telemetry from all the devices.
- Use machine learning to determine whether desired state of policy has been achieved. And then repeat,
Related to that concept, Ghai explains, is ASN: “It’s also a concept which is software control and optimization and automation. The only difference is that ASN is more applicable to distributed applications over the internet than IBNS.”
IBNS Operates Networks as One System
“Think of intent-based networking as software that sits on top of your infrastructure and focusing on the networking infrastructure, and enables you to operate your network infrastructure as one system, as opposed to box per box,” explained Mansour Karam, Founder, CEO of Apstra, which offers IBNS solutions for enterprise data centers.
“To achieve this, we have to start with intent,” he continued. “Intent is both the high-level business outcomes that are required by the business, but then also we think of intent as applying to every one of those stages. You may have some requirements in how you want to build.”
Karam added, “Validation includes tests that you would run — we call them expectations — to validate that your network indeed is behaving as you expected, as per intent. So we have to think of a sliding scale of intent and then we also have to collect all the telemetry in order to close the loop and continuously validate that the network does what you want it to do. There is the notion of state at the core of an IBNS that really boils down to managing state at scale and representing it in a way that you can reason about the state of your system, compare it with the desired state and making the right adjustments if you need to.”
The upshot of IBNS, Karam said: If you have powerful automation you’re taking the human out of the equation, and so you get a much more agile network. You can recoup the revenues that otherwise you would have lost, because you’re unable to deliver your business services on time. You will reduce your outages massively, because 80% of outages are caused by human error. You reduce your operational expenses massively, because organizations spend $4 operating every dollar of CapEx, and 80% of it is manual operations. So if you take that out you should be able to recoup easily your entire CapEx spend on IBNS.”
ASN Gives Each Application It Own Network
“Application-Specific Networks, like Intent-Based Networking Systems, enable digital transformation, agility, speed, and automation,” explained Galeal Zino, Founder of NetFoundry, which offers an ASN platform.
He continued, “ASN is a new term, so I’ll start with a simple analogy. ASNs are like are private clubs — very, very exclusive private clubs — with exactly two members, the application and the network. ASN literally gives each application its own network, one that’s purpose-built and driven by the specific needs of that application. ASN merges the application world and the network world into software which can enable digital transformation with velocity, with scale, and with automation.”
Three Key Use Cases for Intent-Based Success
Cisco sees IBNS as still in its infancy, and according to Prashanth Shenoy, Vice President of Cisco’s Enterprise Networking Group, the company sees three steps to using automation to achieve drastic operational simplicity – and thereby, cost savings.
The first step, he said, is to help them reduce OpEx “to drive drastic agility. The way to do that is day-zero operations. When customers install new things on the network and they want a design, can the network and the software sitting on top automatically recognize what that system is, and put the right configuration in place? It’s a very simple use case that IBNS can do.”
“The second key is around security,” Shenoy continued. “ The network can fundamentally make organizations more secure with IBNS. A use case there is as simple as segmenting your network: If you know who gets access to what, the network can use the intent of your business and automate the policy and segment the network. IBNS helps scale security, so that as the user or the device move, the policy and the profile moves with that user in an automated fashion.”
The third key use case is really around providing visibility, he added, “Our customers don’t know what is even connected to the network and they don’t have any visibility in the data. Providing a 360-degree visibility into who the users are, what are the devices connected, what are the applications, and what is the health of the user’s device application and the compliance requirement is where IBNS can play a huge role.”
Moving forward, he said, IBNS can evolve to add machine learning and artificial intelligence to do predictive analytics, predictive security, predictive assurance — all leveraging the telemetry and the data coming from the network to drive better efficiency.
Intent Requires a Trust-But-Verify Model
Historically, “we’ve seen this progression where manual operations are transitioning to more automated tool change via configuration management,” said JR Rivers, Co-Founder & CTO, Cumulus Networks, which helps enterprise networks scale with automation. “Administrators then use side tools to inspect the current state of the network and making sure it aligns with what their intent was.”
He continued, “One of the most important pieces as companies transition into this world is it becomes a trust-but-verify model. You can’t have a tool that you’re going to trust to do everything for you, because inevitably that tool’s going to fail. They always fail — it’s just the way the world works.”
What do you do if you can’t trust your tools to always work properly? Rivers advises, “You have to also put in place other mechanisms to verify that your intent is what you expected, and that you haven’t made a mistake along the way. This cuts off something from happening that you weren’t expecting.”
He added, “If you think about intent, you have to not only specify what you’d like to happen, you also have to specify what you’d like to not happen.”
Intent is Evolution of Best Practices
“IBNS and ASN aren’t necessarily new,” expressed Jeff Baher, Senior Director of Dell EMC Networking & Service Provider Solutions. “They are an evolution of best practices and how to design networks.”
He continued, “There are significant new technologies that are available to approach and to try to solve network-design problems, predicated on disaggregation. The disaggregated model can solve specific problems, and also dovetails into the expertise that drives the networks.”
It’s largely about scale, Baher explained: “A lot of what we talk about and what we see at Facebook, Amazon, and Google are problems, by-products or symptoms of extremely large-scale networks, where they simply could not manage the networks with people. With smaller-size networks, we might not have the same drivers.”
“There’s a balance with how much technology is at your disposal, what is your ultimate intention with those networks, and what you’re trying to do specifically with your business and with your infrastructure.”
ASN meets the IoT
Consider the Internet of Things as a strong domain for ASN, said NetFoundry’s Zino. “Imagine an IoT scenario where the device has a hardware router trust — that is, a trusted identity from that device, and you want to use that trusted identity to drive the network.”
And then something looks wrong. “If the data and the metadata about the device is passed by an API securely to the network, and the network then compares that metadata to a policy – for example, perhaps the latitude and longitude of that device,” he continued. That metadata doesn’t fit the policy, because the device isn’t here it’s supposed to be. “The policy says, spin up a network to divert to a honeypot, so we can find out what’s going on. So we’ve instantly built a network according to the context of that application. Or maybe the application is so sensitive or the device is so sensitive that if the latitude and longitude don’t match, we need a network kill switch.”
“Think about that example from the perspective of the network engineer, the application developer and the DevOps person, working together for that degree of automation, and essentially self-healing resiliency, That is, I believe, a common challenge for both IBNS and ASN,” Zino said.
Open Networks or Proprietary? It Depends
Should IBNS and ASN tools be open and interoperable – or will they work best in vendor-specific domains? “There is a balance between what you would like to see implemented in hardware and in software and as a result what may end up being proprietary in either of those,” expressed Dell EMC’s Baher. “But looking at the way markets typically have evolved, we’re seeing more choice, more capability with each generation. That again, as I mentioned before, I think that’s predicated largely on the ability to disaggregate some of those systems that were previously tightly integrated.”
Cumulus’ Rivers agreed. “There’s always this trade-off when you look at technology between highly- or tightly-engineered systems that start from the bottom and go all the way up to the top, versus loosely-coupled systems. Inevitably in industry, networking starts up in that very highly-engineered system world. At some point, all the pieces become so complex that no one organization can actually act upon it very well.”
Rivers continued, “You’re going to have people that use industry standard hardware that can be interchangeable, because a customer will pick one or two suppliers that they like to work with and be happy. They’ll pick operating system levels or controllers – again, independent pieces of software that people like, and you’ll have overriding intent systems that drive all of that, making it reasonable for the intent systems to be holistic.”
“In the end, each of these pieces is somewhat proprietary, or somewhat open, depending on the characteristic of the company that develops it – how they want to present the technology forward. What I don’t believe will ever happen is a unifying standard that makes all of these things interoperable,” Rivers added.
Apstra’s Karam mentioned, “Customers embrace horizontally layered, loosely coupled architectures, where you have abstractions and you have APIs. Last I checked, somewhere around 80% of companies out there have hardware from multiple vendors. They want to decouple their operational model from their choice of vendors.”
“We’re at the start of the intent-based journey, and it is a journey,” concluded NetFoundry’s Zino. “Although everything is very proprietary right now – and elements will remain proprietary – what we’ve learned in the past is that you build up a base that is common as the technology matures. In terms of looking forward for both IBNS and ASN, as those base layers built up and standardized as the APIs, and the interfaces, as the microservices start to standardize, then we introduce even more sophisticated behavior to drive the digital transformation, the agility, the velocity that we’re all looking to get.”
