Get Your Own Sticky Blog!
In our product – AOS™ – we create and manage a model that represents a single source of truth regarding infrastructure, policies, constraints etc. This model is subject to constant change and we need to query it for various reasons, and we represent it as a graph. With the graph, all information about our network is modelled as nodes and relationships between them.
Every object in a graph has a unique ID. Nodes have a type (which is a string) and set of additional properties based on a particular type. For example, all switches in our system are represented by nodes of type “system” and can have a property “role” which determines which role in network it is assigned (spine/leaf/server). Physical and logical switch ports are represented by an “interface” node, which also has a property called “if_type”.
Relationships between different nodes are represented as graph edges which we call “relationships”. Relationships are directed, meaning each relationship has a source node and a target node. Relationships also have a type which determines which additional properties particular relationship can have. E.g. “system” nodes have relationships of type “hosted_interfaces” towards “interface” nodes.
A set of possible node and relationship types is determined by a graph schema. The schema defines which properties nodes and relationships of particular type can have along with types of those properties (string/integer/boolean/etc) and constraints. We use and maintain an open source schema library, Lollipop that allows flexible customization of value types.
Going back to the graph representing a single source of truth, one of the most challenging aspects was how to reason about it in the presence of change, coming from both the operator and the managed system. In order to support this we developed what we call “Live Query” mechanism which has three essential components:
Query Specification
Change Notification
Notification Processing
Query Specification Having modelled our domain model as a graph, it is important to be able to find particular patterns (subgraphs) in a graph.
You do that by running searches on a graph specified by graph queries. The language to express the query is conceptually based on
Gremlin, which is an open source graph traversal language. We also have parsers for queries expressed in another language –
Cypher, which is a query language used by popular graph database
neo4j.
You start with a
node() and then keep chaining method calls, alternating between matching relationships and nodes:
The query above translated in English reads something like: “starting from a node of type
system, traverse any outgoing relationship that reaches node of type
interface, and from that node traverse all outgoing relationship that lead to node of type
link”.
At any point you can add extra constraints:
Notice role=”
spine” argument, it will select only “
system” nodes that have “
role” property set to “
spine”. Same with “
if_type” property for “
interface” nodes.
.out()
.node(‘
interface‘, if_type=ne(‘
ip‘))
That query will select all “system” nodes that have role either “spine” or “leaf” and “interface” nodes that have “if_type” anything but “ip” (“ne” means “not equal”).
You can also add cross-object conditions which can be arbitrary Python functions:
.out().node(‘
interface‘, name=’
if1‘)
.out().node(‘
link‘)
.in_().node(‘
interface‘, name=’
if2‘)
.in_().node(‘
system‘)
.where(
lambda if1, if2: if1.if_type != if2.if_type)
You refer to objects by giving them names and using those names as argument names for your constraint function (of course you can override that but it makes a convenient default behavior). So, in example above it will take two “interface” nodes named “if1” and “if2”, pass them into given “where” function and filter out those paths, for which function returns False. Don’t worry about where you place your constraint: it will be applied during search as soon as all objects referenced by constraint are available.
Now, you have a single path, you can use it to do searches. However, sometimes you might want to have a query slightly more complex than a single path. To support that, query DSL allows you to define multiple paths in the same query, separated by comma(s):
node(‘
a‘).out().node(‘
b‘, name=’
b‘).out().node(‘
c‘),
node(name=’
b‘).out().node(‘
d‘),
)
This match() function creates a grouping of paths. All objects that share same name in different paths will actually be referring to the same object. Also, match() allows adding more constraints on objects with where(). You can do a distinct search on particular objects and it will ensure that each combination of values is seen only once in results:
node(‘
a‘, name=’
a‘).out().node(‘
b‘).out().node(‘
c‘, name=’
c‘)
).distinct([‘
a‘, ‘
c‘])
This matches a chain of
a ->
b ->
c nodes. If two nodes “
a” and “
c” are connected through more than one node of type “
b”, the result will still contain only one (“
a”, “
c”) pair.
There is another convenient pattern to use when writing queries: you separate your structure from your criteria:
node(‘
a‘, name=’
a‘).out().node(‘
b‘).out().node(‘
c‘, name=’
c‘),
node(‘
a‘, foo=’
bar‘),
node(‘
c‘, bar=
123),
)
Query engine will optimize that query into:
.out().node(‘
b‘)
.out().node(‘
c‘, name=’
c‘, bar=
123)
)
No cartesian product, no unnecessary steps.
Change Notification Ok, now you have a graph query defined. What does a notification result look like? Each result will be a dictionary mapping a name that you have defined for a query object to object found. E.g. for following query
results will look like {‘a‘: <node type=’a‘>, ‘c‘: <node type=’c‘>}. Notice, only named objects are present (there is no <node type=’b‘> in results, although that node is present in query because it does not have a name).
You register a query to be monitored and a callback to execute if something will change. Later, if someone will modify the graph being monitored, it will detect that new graph updates caused new query results to appear, or old results to disappear or update. The response executes the callback that is associated with the query. The callback receives the whole path from the query as a response, and a specific action (added/updated/removed) to execute.
Notification Processing When the result is passed to the processing (callback) function, from there you can specify reasoning logic. This could really be anything, from generating logs, errors, to rendering configurations, or running semantic validations. You could also modify the graph itself, using graph APIs and some other piece of logic may react to changes you made. This way, you can enforce the graph as a single source of truth while it also serves as a logical communication channel between pieces of your application logic.
The Graph API consists of three parts:
Graph management – methods to add/update/remove stuff in a graph.
add_node(), set_node(), del_node(), get_node()
add_relationship(), set_relationship(), del_relationship(), get_relationship()
commit()
Query
get_nodes()
get_relationships()
Observable interface
add_observer(),remove_observer()
Graph management APIs are pretty self explanatory.
add_node() creates new node
set_node() updates properties of existing node
del_node() deletes a node
commit() is used to signal that all updates to the graph are complete and they can be propagated to all listeners.
Relationships have similar API.
The observable interface allows you to add/remove observers — objects that implement notification a callback interface. Notification callback consists of three methods:
on_node(),
on_relationship() and
on_graph(). Methods on_
node() and
on_relationship() are called when any node/relationship is added, removed or updated.
on_graph() is called when the graph is committed.
The Query API is the heart of our graph API and is what powers all searching. Both
get_nodes() and
get_relationships() allow you to search for corresponding objects in a graph. Arguments to those functions are constraints on searched objects. E.g.
get_nodes() returns you all nodes in a graph,
get_nodes(type=’
system
‘) returns you all “
system” nodes,
get_nodes(type=’
system
‘, role=’
spine
‘) allows you to constrain returned nodes to those having particular property values. Values for each argument could be either a plain value or a special “property matcher” object. If the value is a plain value, the corresponding result object should have it’s property equal to the given plain value. Property matchers allow you to express a more complex criterias, e.g. “not equal”, “less than”, “one of given values” and so on:
Property matcher example:
type=’
system‘,
role=is_in([‘
spine‘, ‘
leaf‘]),
system_id=not_none(),
)
In your graph schema you can define custom indexes for particular node/relationship types and the methods
get_nodes() and
get_relationships() pick the best index for each particular combination of constraints passed to minimize search time.
Results of
get_nodes()/get_relationships() are special iterator objects. You can iterate over them and they will yield all found graph objects. You can also use APIs that those iterators provide to navigate those result sets. E.g.
get_nodes() returns you a
NodeIterator object which has methods
out() and
in_(). You can use those to get an iterator over all outgoing or incoming relationship from each node in the original result set. Then, you can use those to get nodes on the other end of those relationships and continue from them. You can also pass property constraints to those methods the same way you can do for
get_nodes() and
get_relationships().
.out(‘
interface‘).node(‘
interface‘, if_type=’
loopback‘)
The code in the example above finds all nodes with type “system” and role “spine” and then finds all their loopback interfaces.
Putting It All Together
node(‘
system‘, name=’
spine_device‘, role=’
spine‘)
.out(‘
hosted_interfaces‘)
.node(‘
interface‘, name=’
spine_if‘)
.out(‘
link‘)
.node(‘
link‘, name=’link’)
.in_(‘
link‘)
.node(‘
interface‘, name=’
leaf_if‘)
.in_(‘
hosted_interfaces‘)
.node(‘
system‘, name=’
leaf_device‘, role=’
leaf‘)
))
def process_spine_leaf_link(self, path, action):
“””
Process link between spine and leaf
“””
spine = path[‘
spine_device‘]
leaf = path[‘
leaf_device‘]
if action in [‘
added‘, ‘
updated‘]:
# do something with added/updated link
pass
else:
# do something about removed link
pass
Any new technology in Silicon Valley will go through a phase where defining precisely what it is can be difficult to do. New ideas need new words to describe them, to keep these ideas distinct in people’s minds. In spite of this, many people will not have heard about any given new and emerging concept. This creates a window of time where existing vendors with existing products will invariably attempt to further blur an already blurry line in the minds of potential customers about what something new really is. We call this “washing.” For instance, “cloud-washing” is when something that really isn’t “cloud” is talked about as if it were.
Intent-Based Networking (IBN) is currently undergoing the same treatment. Many companies have announced intent-based initiatives or products. They are using the language and the surrounding ideas to talk about existing products that simply were not designed from the ground up with Intent as a guiding light.
At Apstra, we know that Intent-based systems are still emerging. Yet, we are delivering the world’s first and only vendor-agnostic, Intent-Based Networking System. From day one, our Apstra Operating System (AOS™) was built with Intent as our guiding light. Whether we are talking about our flagship data center management solution, or about AOS as a platform for others to develop their own apps, Intent has been the primary driving theme. Intent is what elevates Network Engineers and Automation Developers above the complicated minutia inherent in networking.
It’s been fascinating watching “Intent-Washing” happen right before our eyes every day in social media and at industry events. So we did something fun to shine a light on it. Please enjoy this short video we made about “Intent-Washing.”
And if you are really serious about understanding the concepts behind next-generation networks, read Sasha Ratkovic’s excellent blog “Intent-Based Networking: What Is It?”
…while you’re at it, please check out some of our other videos and articles. Schedule a demo and see first hand what AOS can do for you.
Introduction
Intent-based-networking (IBN) is the shiny new object in networking. Analysts and vendors alike are touting it as transformative to the data center and Cisco’s CEO said “Intent-Based Networking will redefine networking for the next 30 years”. Apstra pioneered Intent-Based Networking and delivered the first and only complete system which enables Cisco, Juniper, Arista, HP and white box customers to deploy an IBN system through the Apstra Operating System (AOS™). We are experiencing a phenomenon called “intent washing,” which Gartner predicted would happen. Vendors are rebranding existing products as “intent-based”. Some are even rebranding complete product lines. It’s confusing to discern marketing and reality — the ads, white papers and slides — vs shipping products that deliver on the value proposition of Intent-Based Networking.
In this article, I’d like to cut through this confusion by listing and defining the foundational aspects of an IBN system. I encourage you to spend the time to internalize them, and use them as criteria when considering or evaluating new products.
Motivation
The main motivation behind IBN is to allow companies to run their networks reliably and cost-effectively while offering more agility and control, both in terms of new features and vendor choices. To achieve that, the hard problem is how to compose the complex infrastructure capabilities in order to serve business needs in the presence of constant change in device capabilities and business rules?
The composition problem is a consequence of the fact that today’s data centers act as scale-out computers and there is a need to compose this infrastructure consisting of compute, network, and storage. But this is only one dimension of this composition problem. Another one is how do you incorporate complex business rules and policies? Infrastructure capabilities, as well as mechanisms to consume them, are subject to constant change. And the situation with business rules is even worse, both in terms of the frequency and the complexity of the changes. Every time a change happens, you are required to perform some composition. If you take something out, is what is left still acting as a coherent whole? If you add or modify something, is the new composite valid? With a single compute virtualization node, the problem the operating system has to deal with involves partitioning of resources as well as dealing with isolation. But with the data center acting as a scale-out computer, the distributed operating system first has to perform composition and only then again resource partitioning and isolation. But if you fail at composition due to changes in infrastructure and business rules, you will never even get to consuming your precious and expensive scale-out compute resources.
When we first spoke about our vision of Intent-Based Networking, one aspect about IBN mentioned by analysts was orchestration, but there is much more than that. Orchestration is an execution workflow and is less concerned with the state. So in that model, it is assumed that someone else creates the single source of truth about the state of infrastructure and business policies; and that this state is then fed into the orchestration workflow. In IBN, that single source of truth, originating from intent, (which we define more precisely below) is at the core of the platform, and drives everything else.
Definition So what is the intent? At the highest level, intent is a declarative specification of the desired outcome. And the desired outcome is complete automation of the whole network service lifecycle, which consists of the following phases:
design, build, deploy, validate. See
our videos from Networking Field Day 16 for more details about what these phases entail.
At a high level, Intent defines the “what” not the “how”. A key observation is that intent is dynamic, and a fundamental requirement of an IBN system is that it should be capable of ensuring that intent’s expectations are met in the presence of change. And changes can come from either the operator (business rule change) or the infrastructure (operational status change).
In order to enforce that intent expectations are met, the IBNS has to be the
single source of truth (regarding the intended state of both your infrastructure and your business rules) that one can
programmatically reason about in the presence of
change.
In the absence of this you will be spending most of your time immersed in accidental complexity developing a coordination layer that synchronizes a growing number of sources of truth that come with different formats and semantics.
One can argue that “everything can be done in software” and so can the reasoning logic described above. In a worst case example, one could envision writing a script that consolidates a set of all sources of truth scattered across various files and databases and then reason about the resulting output. Beyond simple automation tasks, the complexity of the system will quickly become unmanageable. Add the requirement for intent to be dynamic, and this solution becomes quickly unworkable
Reasoning about intent programmatically is the key enabler for the automation of all aspects of the service lifecycle such as design, build (including resource allocation), semantic validation, configuration rendering, expectation generation, test execution, anomaly detection, troubleshooting, change request validation and refutation.
And reasoning about intent needs to be maintainable and testable in the presence of change. In order to achieve this, the IBN solution is required to have the following capabilities:
Ability to easily extend the schema of this single source of truth to address new business rules and infrastructure capabilities.
Ability to programmatically decompose the single source of truth into subsets of elements of interest as it grows in size and complexity. This decomposition is the key to deal with scaling issues — i.e. an architecture that results in every piece of logic reacting to every change in intent will not scale.
Ability to get notified reactively about the nature of a change (addition, update, deletion) in the intent. This asynchronous, reactive capability (as opposed to polling) is another key to addressing scaling issues as intent gets more complicated.
Ability for components to communicate in reaction to a change in intent.
Ability for network operators to insert their expertise by enabling them to insert their own logic and programmatically reason about the intent, all in the presence of change.
Ability to add support for new innovative features offered by modern infrastructure platforms.
Ability to add support for a collection of new telemetry data.
Ability to launch Intent-Based Analytics to extract knowledge out of raw telemetry data.
We recommend that you use the above list as a checklist for validating IBN compliance when evaluating IBN solutions.
In summary, the intent definition language (allowing you to define that single source of truth) AND reasoning about intent has to be built into the IBN platform.
Why does “built into the IBNS platform” matter? Because it means less code (bugs) to write, review, and maintain, less tests to write, review, and maintain. In short, more agility and availability. In its absence you can expect the complexity of your solution to spiral out of control in the presence of change.
Intent-Based Networking brings the best software practices into network service lifecycle management. The benefit of starting with a good foundational architecture is a measurable increase in feature velocity. Another critical advantage resides in the opportunity to become hardware vendor independent. We encourage you to test drive a complete IBN system and explore the benefits today. We believe that you’ll be pleased by how quickly it will enable you to design, build, operate and validate your network — providing more agility and reliability than you have ever experienced before, while slashing your operational costs.
Network Field Day 16 was a good day for Apstra. Sasha Ratkovic, our CTO and cofounder, Damien Garros, Consulting Systems Engineer, and I all presented to a great group of people. This was our first opportunity to show the world what the Apstra Operating System (AOS™) looks like under the hood. We were excited to show developers and DevOps minded folk, who might leverage AOS to build custom network automation applications, the power that they have at their fingertips.
We first talked a little bit about how the network engineering family is growing with a new specialized persona: the Network Automation Architect. This isn’t necessarily a developer, but someone who has deep network engineering expertise that can work with developers to model end-to-end network services and their supporting mechanisms. By providing developers or DevOps folks with the right details (and using AOS as the automation platform), people in this new role will have serious impact on the operational effectiveness and service delivery capabilities of the broader organization. Fewer mistakes, more uptime, faster application delivery. Isn’t that what IT is all about?
For the remainder of the presentation Sasha and Damien went back and forth as they walked the audience through a few examples, with demos (all this is real, no slideware here!) showing how one might approach the problem of modeling where applications are located at the edge of the network. With this information we can craft interesting queries for AOS such as “show me where congestion is happening for application foo.” We also talked briefly about more complicated examples such as using VRFs to establish isolated forwarding domains in the network to contain various security zones. I do love me some VRFs!
There was a very important theme, however, throughout the presentation: Test-driven engineering. Both for the network and for developers building on top of our platform. At Apstra, we firmly believe that any Intent-Based Networking System must validate the state of the underlying systems both at the device and the more abstract inter-device level. In other words, changes in the network should always be tested by examining the resulting state of the network. For developers building apps on top of AOS, they need the right development tools to validate that their apps are working as expected before they are deployed. Again, AOS provides that!
Click on the links to the right to watch each of section of our presentation. When done, reach out to us if you have any questions. In fact, schedule an on-site demo! It’ll cost you nothing but time, and I promise it’ll be worth every second!
This is the second blog in a three-part series on “Examples of Intent-Based Networking”.
