Lately we have been discussing the topic of the Network Automation Journey. While the previous article covers the path towards network (or infrastructure) automation, let’s take a step back and take a closer look at the elements that build the complete solution.
Today we focus on the Source of Truth, which I prefer to call Source of Intent.
Source of Truth - why do we need it?
Every network, every infrastructure or every service starts with a design - or at least it should. This design can take different forms: a diagram or a text description, but the intention is the same - having a concept of this new entity described in a way that it is understandable and accessible. And this is quite easy for a small setup, where a small group of people is involved. But what if our infrastructure grows? What if new devices, new connections, new services are delivered?
Quite often the operational teams divide the responsibility among themselves. Each team is responsible for something else, its own piece of the infrastructure (which can be virtual, an IP address for example). In time those teams grow apart and work together only when a new entity is required. They do not know how the other teams work in their responsible area, where they keep the data, or how they use it.
And regarding the data itself, in such scenarios there is no common requirement or expectation on how (and where) the data should be stored. If one started with a spreadsheet to store IP addresses, it is probably still the way it is being kept. And if a service has been designed in the form of a diagram, those diagrams are the way it is being preserved. There is very little correlation between those two and it is very hard to understand the whole picture. Especially with such dispersed knowledge stored in many different locations and in different formats it is very difficult to find all the pieces of the puzzle.
This is where Source of Truth / Source of Intent comes into play. It is important to understand that Source of Truth / Source of Intent is mandatory if one thinks of implementing network automation. This is explained in the Network Automation Journey article mentioned before.
The difference between the Source of Truth and the Source of Intent
By definition a Source of Truth (SoT) is a source of reliable data for a given entity. One may also encounter the term Single Source of Truth (SSoT), which means a strategy where there is a single place for storing data and only references to this data are allowed (there is no copy).
This is quite a good definition, but how to apply it when it comes to a network or infrastructure? Let’s consider a simple example: imagine we have two routers connected by a single link. Router A’s interface is IF1A and its address is 192.168.0.1/24. IF1A faces the IF1B interface on router B. IF1B’s address is 192.168.0.2/24. This is what has been designed and is expected to be implemented. Now let’s imagine that someone, working a long night shift who has been doing manual changes in a few other places, has made a mistake: they accidentally swapped the IP addresses, so 192.168.0.1 is on IF1B and 192.168.0.2 is on IF1A. In such a case what is the truth? Should we update the SoT with the actual configuration from the live network (and risk that each mistake is propagated and stored) or leave it as it is, thus having different data in the SoT and in a production environment.
In this simple example (and we haven’t even touched on the operational state yet!) we can see that using the term ‘truth’ may not be best in the case of network or infrastructure. Therefore I prefer to use the term 'Source of Intent (SoI)' - it implies that whatever we store in the database (or any other means of keeping the data) is our intention, that we want to have reflected in the real network; this is the concept. And if something is different it is most probably a mistake.
With such an approach the Source of Intent defines the expected state / the intended state and expects the live infrastructure to follow it.
Plan vs. configuration vs. operational state
In the section above we have been discussing an example of swapping two IP addresses between the two ends of the same link. This will not cause any operational problems - most probably no one will even see it - but it will cause a discrepancy between the concept (defined in the Source of Truth / Source of Intent) and the actual configuration. If one uses the term Source of Intent it seems obvious that the live network configuration is incorrect and probably should be changed. With the term Source of Truth it is not so obvious anymore - shouldn’t the network be the source of real data?
Let’s add one more variable to the picture - operational state. As in the example above, one can have an incorrect (unintended) configuration in place and everything working as expected, or on the contrary: both the intended and applied configuration are the same, but the service is not working properly. So, what about the latter case? How do we see it in the context of Source of Truth / Source of Intent? Here the answer is simple - we don’t. Source of Truth / Source of Intent does not touch the operational state. It only defines how the infrastructure / addressing / service should look, but it is not its role to track the operational state of any of it. There are different tools and solutions for that, but those are beyond the scope of this article.
If the reader is interested in ways to track the operational state of the network, infrastructure or application, we encourage you to take a look at the Observability section of our blog.
How to implement Source of Intent?
So the question of how to implement the Source of Truth / Source of Intent remains. What data should it gather? How should that data be stored? As one can imagine, there is no simple answer to those questions.
First, even though the name may suggest so, a Source of Truth / Source of Intent doesn’t have to be (and usually isn’t) a single database that gathers all the data. This is because the data has different structures as it represents completely different entities. For example, it would be difficult to find a common structure for storing IPAM data and DCIM information - they differ too much. And in addition to those two a SoT/SoI must also store cloud-related information (if clouds are used), hardware inventory, configurations (also as golden templates and variables), services and protocols.
That is a lot of data of different types. In such cases it can be desirable that each group uses different means of storage (possibly still run by different teams), but what is important is that there is a single means of entry to that data, and all interested parties are working on the same data source, so everyone will always have access to the same information.
There are solutions that serve as a Source of Truth / Source of Intent already available on the market. Nautobot 
or NetBox have been known for some time now. There is another solution being prepared by OpsMill . In the end, a repository like GitHub can even be used as a simple form of Source of Intent, although it would require some work to set it up.
There is no single solution that serves as a Source of Truth / Source of Intent, but there are possibilities to explore.
Conclusion
In this short article, we wanted to explain the difference between the Source of Truth and Source of Intent and explain their role. We have also mentioned some already available software to fulfill this role.
In the next article we will explain the concept of a Digital Twin, stay tuned.
