I’ve spent a lot of time thinking about intent based networking – trying to define it – identifying its core tenets. Without a library of IETF drafts to go by, I listened to vendors explain their platforms, I read their whitepapers, I explored their solutions trying to figure out the commonalities among them and pinpoint exactly what they were all really trying to do.
I believe I came to a pretty good conclusion. IBN is a closed loop system of analytics, orchestration, and continuous validation. And in that process micro-configuration is abstracted from the network operator and replaced with higher level macro-configurations otherwise known as “intent.”
Using that definition, is Cisco Software Defined Access intent based networking?
Many of the self-identified IBN vendors fit into that paradigm. And though they each may approach IBN differently from a technical perspective and perhaps focus on different areas of the network, they all contain those basic elements – abstraction, validation, and closed loop automation.
For me, there’s always been one exception. Cisco SD Access has been marketed heavily as an intent based networking platform, and honestly I’ve never really been sure that it is, at least using my own definition of IBN.
Cisco jumped on the IBN bandwagon a few years ago in a big way during a Cisco Live keynote, and since then it’s felt like they’ve been trying to attach the term to anything in their portfolio that isn’t end of life.
That’s probably why I didn’t believe SDA was intent based networking: not because of the actual technology, but because the messaging felt sloppy.
What I’ve realized is much of the difference between SDA and other IBN vendors is in the marketing. Cisco hasn’t talked about the closed loop validation and orchestration component nearly as much as endpoint mobility and policy consistency. Sure, those things are very important, but I feel like the messaging has been missing vital components of IBN.
But now in early 2020, and in spite of what I believe has been lackluster messaging, I do believe SD Access is an intent based networking solution.
Software Defined Access is a technology with several components working together. It’s not one platform, and it’s certainly not just one specific technology working alone. Instead, SDA is a combination of many elements including Campus Fabric, APIC-EM 2.x, the Network Data Platform, ISE, and a range of supported hardware.
The intent based networking piece is really the sum total of how these components work together in the context of Assurance, which is Cisco’s term for the continuous validation.
Seldom I’ve come across some marketing or design guide snippet that digs into “Assurance”, which I do agree is a core component of Cisco IBN. It’s not a big part of the messaging, though, and I’m not sure why.
It’s taken some time, but both my experience with the technology and a couple pieces of literature Cisco has published online have changed my mind about SDA.
In Cisco’s e-book Cisco Software-Defined AccessEnabling intent-based networking, 2nd edition, the authors define Assurance as “the ability to quantify network availability and risk.” This is a very broad definition, but as we read further in this e-book and also its companion, Cisco DNA Assurance: Unlocking the Power of Data, we find that Cisco’s main engine driving IBN is the Network Data Platform, or NDP, which is a main component of the DNA Center controller.
In the first publication mentioned above, the authors define IBN in this way:
Automation and orchestration, as defined in the Software-Defined Access overview section, brings the “software-defined “concept to the campus “access” network, trans‐lating the user’s “intent” into meaningful configuration and verification tasks.
Cisco Software-Defined AccessEnabling intent-based networking, 2nd edition (page 135)
The literature suggests that IBN is the process of translating intent into meaningful configuration and verification tasks. The automation piece is there, the word “translate” implies abstraction, and continual validation is certainly expressed in “verification tasks.”
(Some of this is now reflected in very recent IETF drafts here and here. )
These are foundational components of IBN, and to the extent that the folks at Cisco agree with me on the definition, SDA is therefore an IBN platform in spite of it being so different under the hood from other vendors.
Through the NDP engine, DNA Center collects and analyzes network information to identify network anomalies and validate metrics such as configuration and performance. The APIC-EM part of DNA Center abstracts away much of the manual configuration needed to keep the network in line with the baseline architecture configured in DNA Center and policy configured in ISE.
In spite of the significant complexity of an IS-IS routed underlay network, VXLAN data plane, LISP control plane, and ISE policy plane, SDA absolutely meets the definition of IBN.
And maybe it’s not in spite of that complexity, but because of it. Cisco approaches IBN differently than other vendors from a technical perspective. I think many engineers get caught up in the complexity of IS-IS, LISP, VXLAN, and Trustsec, and miss the bigger picture. These are the mechanisms that provide the abstraction, continuous validation, automation, and perhaps one day autonomous remediation.
Maybe SDA isn’t a fully mature IBN platform yet. Maybe there are still bugs to work out. I’m still waiting to see how integration with ACI and Cisco SD-WAN play out. However, based on my own understanding of IBN, the sum total of these components working together clearly make SDA an intent based networking platform for the campus network.
{networkphil} 