Cisco Has (Re)discovered Intent Modeling, and it Means it!

We need a new network architecture.  That’s a view that Cisco has expressed, relating to the coronavirus impact, but it’s actually been true for over a decade.  Not only that, most network operators and many CIOs have agreed with that position, according to my own research.  The problem isn’t recognition of the need as much as recognition of what the architecture would look like.  Cisco’s vision isn’t new, but it seems pretty clear that they’re newly committed to it, and that could be very significant for both Cisco and the market.

Scott Harrell, head of Cisco’s Intent-Based Networking unit, is quoted in what’s certainly a strong lead-in to this topic: “This is a huge innovation cycle we have to go through,” Harrell explained. “But just doing it from a hardware point of view won’t be enough.”  Let me phrase the point slightly differently:  our focus has been on building network devices, and it needs to be on building network services.  Even Harrell’s turn of the phrase is a revolution for a device vendor, and that’s why I’m seeing this as a new and significant shift in Cisco positioning.

Devices have been central to networking from the first, so having a device-centric bias is certainly understandable.  The problem is that if you evolve network services by evolving devices, you tend to be constrained by the historic way that devices relate to and create services.  If you evolve a super-modern conceptualization of a router, and you stick the new device in place of an older router, how truly different is the result going to be?  Can a single-device tail, or even a small set of new devices, wag a very large dog of installed base?

I also think Harrell is right in his view of the role of intent modeling.  It’s a “huge shift in how you build and operate networks….”, and while he’s talking specifically about enterprise networks, it’s just as true for service provider networks.  An intent model is a function in a black box, an abstract feature that you can compose into a complex multi-feature service, and implement in any way that meets the “intent”.  If today’s networks are networks of devices, then future networks should be a network of intent-modeled functions.

That doesn’t foreclose having devices inside those functional black boxes, of course, nor does it commit Cisco to filling them with something other than devices.  What it does do is tell the world that open-model networking is coming, in some or several forms, and that vendors like Cisco need to differentiate themselves not at the box level, but at some higher level—like those functional black boxes.

Things get a little murky at this point, and as usual it’s difficult to say whether Cisco’s Harrell isn’t explaining things well, whether Cisco/Harrell don’t believe intent models are what I just explained them to be, or whether the publication didn’t grasp what Harrell was saying.  Whatever the case, the article now brings in things like 5G, WiFi6, and AI, and it’s hard to make a clear connection between any of them and what intent-model networks would look like.  Let’s try to fill in the gaps.

One principle that Harrell articulates is that enterprise networks are transforming to a wireless-first world.  The argument here, which I think is valid, is that even without coronavirus pressure, we were already seeing a need to decouple workers from a specific workplace.  You used to go to work, and now work comes to you.  Part of the drive here is obviously work from home (WFH), and part is the longer-term drive to empower mobile workers.  Whatever the root cause, it’s clear that as you try to create a virtual workplace, you have to focus on a network of identities not a network of termination points.  Who/what something is matters a lot more than where it is, which in a mobile or WFH sense could be anywhere.

I think the wireless-centric vision is a driver for the new architecture rather than an intent-modeled element, but you could express the notion of an identity network in an intent model.  The “feature” of the modeled element is the ability to connect named entities whose names reflect “what” and not “where”.  That’s actually at least somewhat true of mobile networks, so it’s hardly a revolutionary concept, and in fact the IETF has wrestled with the dichotomy of what/where for decades.  WiFi 6 and 5G are certainly ways of achieving real connectivity to identity-named elements.

The link with AI is, I think, a good example of a benefit of intent modeling.  If we look at the trends in software design and deployment, we see that the emerging standard way of automating the operations lifecycle of a network or IT service is through state modeling.  A cooperative system like a network has a “goal state” that represents optimum operation.  It also has a “current state” that may not be the goal state, if something has happened that has to be dealt with.  Operations automation in any form can be viewed as the set of tools and functions that translate the cooperative system from an abnormal current-state condition to the goal-state condition.

This is easier to do with intent modeling, for two reasons.  First, the intent model can express, as its external properties, the specifics of the goal state.  That expression, the interfaces to the black box, can be seen as a contract made with the higher level, and also as a specification that the contents of the black box have to meet.  Second, the concept of the intent-modeled functional black box lets each modeled element work within its implementation to meet the external specifications.  That breaks down the task of remediation into manageable (no pun intended) pieces.

Suppose we have an intent modeled function called “VPN-Core”.  This would define (directly or implicitly) the SLA of the service.  If that SLA isn’t met, then the fault would have to be reported upward to the retail service level, which would then either try to remediate through recomposition, or recognize an SLA violation.  However, VPN-Core would first try to fix its own problems internally.  If it included all the trunks and devices and software of an entire VPN core, that could be a mighty task.  In reality, though, VPN-Core would likely decompose into more primitive intent models, like “MPLS-VPN-Core” or “SD-WAN-VPN-Core”, and these would then decompose into administrative or vendor subnetworks.  Only the bottom layer would decompose into devices/software instances.

In this approach, a fault (which of course has to occur somewhere at the bottom) would first be managed by the low-level model, which could use AI/ML or whatever else seems best.  It would try to fix the problem, and if normal operation was then restored, everything is sweetness and light.  If a fix wasn’t possible, it would report an SLA fault to the superior modeled element.  There, AL/ML could again be applied to recompose that superior element’s inside-the-box structure to rebuild a working feature that meets its SLA.  As before, success would stop the process and failure would escalate up the structure toward the commercial/retail top.

This, I think, is what Harrell is getting at when he says “It’s about going from managing a box at a time to managing the entire fabric at a time. So instead of just managing one box, I’m managing the entire network.”  Intent modeling lets us decompose a service into features, and decompose a service SLA into feature SLAs.  Those features and their SLAs are then further decomposed until you get to a primitive behavior set, and if there are multiple possible ways of creating those features, you have multiple behavior sets.  All this is managed at every level, via AI/ML or whatever works.

If all this is correct, then the tie-in with coronavirus is also clear.  An intent-modeled network is easy to equip with automated operations lifecycle management; in fact, it’s implicit.  An intent-modeled network is easier to recompose under load—again, it’s implicit.  An intent-modeled network is easily adapted to new implementations because any implementation of a specific intent-modeled feature is conformant to the service usage requirements.

And Cisco could be the ideal candidate for leadership here.  They’re committed to change, clearly, and for the best possible reason—that the status quo isn’t going to be profitable, and may not even be survivable.  They have a mighty marketing fist to batter opposition aside, and sweet talk to build consensus among wary CIO and CTO types.  Best of all, they actually grasp what’s needed.  As is often the case these days, they do need to refine their messaging a bit, creating the same kind of intent-within-intent that the whole intent modeling thing proposes to do, but at the positioning level.

We need a revolution, applied as evolution.  For that, you need a cheerleader, but one with a careful eye on the bottom line, who can make revolution palatable by evolving to it.  Cisco could be the one, and of the network equipment vendors, I think it’s likely the only player who could say that.