The process of going back to the beginning is an amazing journey, seeing what you long ago learned, with the fresh eyes of experience, success and failure; new lenses on the world. As I create building blocks for other work I have planned, I start at the beginning again, for example this tutorial on IP routing forwarding plane. In creating it, I summarized it with the following takeaways / learnings, that in real and abstract ways apply to many walks of life:
- Forwarding: info in IP packet PLUS info added to forwarding tables
- Summarization: reduces info required, while reducing clarity/certainty and creating complexity.
- Summarization errors:
– add more specific information where needed
– further increasing forwarding complexity
- Longest prefix match: increases flexibility, increases computation requirements, and processing complexity
- Info creation & distribution: tradeoffs – people / scale and automation
- Manual configuration: what is not automated, increases burden on people, and compromises network efficacy
These are generic information problems we all face as we go about communicating. We especially face them in the context of information going up and down a management chain, but also in areas such as strategy. Let me discuss what I mean.
Forwarding: info in IP packet PLUS info added to forwarding tables
The total amount of information required to make a good decision can come from many sources. In IP networking it can come from the IP packet header itself, potentially higher-layer protocol information, and of course, IP routing protocols. A long running discussion in networking is what information should be clear and explicit in the forwarding header itself, and what should be in routing protocols. As I have written before, Segment Routing for IPv6 (SRv6) is a bit of a rotation back to the idea that we should be using more of what is already in the IP header.
In the normals, there is a constant clash of information from different sources, and also a need of information from different sources. In a business context, there is often the bottoms-up analysis that has to be merged with the top-down analysis. Sometimes it is not merged, and there is simply a power struggle, resulting in incomplete information and bad decision making. How information is combined from different sources is critical to the effectiveness of a business, government, or any other entity.
Summarization: reduces information required, while reducing clarity/certainty
In networking, we respond to finite resources by trying to reduce the amount of resources that are required. One example is route summarization. Instead of advertising/distributing all hosts and/or all subnetworks/subnets, the routing protocols summarize routes, and strategically chosen places in the architecture. This works pretty well in terms of balancing the tradeoffs between good enough routing decisions and the amount of information required in routing & forwarding tables. It is not without its challenges though. As the IETF RIFT(routing in fat trees) work has argued, certain topologies may be particularly exposed to summarization leading to packets not being delivered. The answer to that problem? Where applicable, add more specific information, either positive (do send in this direction) or negative (don’t send in this direction). In addition, summarization can hide details fo the topology which may lead to suboptimal routing.
In strategy work, and also in some areas of science, summary statistics are used. A famous joke highlights the problem: A man with one foot in the oven and one foot in the freezer, is on average, the right temperature. Averages, and other summary statistics hide important information. Part of the art of using data as the basis for making decision, is knowing when to augment the summarized data with critical insight, which is done all the time in networking by adding more specific information, which has shaped the forwarding paradigm of IP routing. Whether it is done enough in business and journalism is debatable.
Figure 1. Above image is from: IP routing forwarding plane tutorial
This is a particular challenge in any organization with hierarchy, as there is a tendency for each layer to summarize the information it received from the layer below it. As the number of layers increases, so too does the problem of summarization. It becomes like that children’s game called Telephone, where a message is passed along a line of people, and once it gets to the end, the message no longer resembles what it was at the start. In organizations there are of course other dynamics. Some organizations attack this problem by trying to develop inclusive and curious cultures, others just chop out as many layers of hierarchy as they can. Cutting out layers of hierarchy maybe something required in networks from time to time as well, but hierarchy is a key approach to scale, so once again, there are tradeoffs.
Summarization errors: add more specific information where needed, increasing forwarding complexity
In networking, when summarization causes a problem, there are a number of ways to address that. One way is to add more specific information, for example, specific routing information for a network that is currently unreachable. Summarization also makes planning around address usage/allocation/configuration more important, but that is not the specific point of focus here.
In a business, if you have a summary, but you want to add more specific information, that can be a really tricky exercise. What if the more specific information leads to a question about something that requires even more information? What if the more specific information creates more confusion than clarity. Famously, people with a technical bent have a propensity to give gobs of specific information for fear of not explaining something to other technical people who understand all the detailed information (this is a stereotype of course, the Internet ethos is be conservative with what you send). OTOH, management oriented people, have an (in)famous propensity to admire people who give them short sound bites – hyper summarizers. Dealing with summarization errors can be a tricky, complexity driving exercise in networks, and in other walks of life. The alternative is for everything and everyone to consume all the raw data. In both networks and other walks of life, that is not viewed as being practical.
Figure 2. Above image is from: IP routing forwarding plane tutorial
In IP networks, the presence of summarization and more specific information, leads to Longest Prefix Match (LPM) forwarding, where a tree of less specific to more specific is created, and the more specific is favored. LPM requires more sophisticated and expensive approaches to forwarding, if performance is to be maintained. This can still be a cost/performance/scale challenge for some access routers. Whether access routers with limited physical connections to the rest of the network need extensive routing information is another issue.
Information creation and distribution: tradeoffs across people, scale, and automation.
One of the reasons IP routing has been so successful is the automation of path learning. Depending on the routing protocol, IP routers are either told by other routers what the best path is, or they can derive what the best path is by examining the network topology. This automation is a huge network operations time saver, and also fairly robust in the face of changes.
If only everything we did in networks and life was so automated! Often, when you first do something in business, it is manual. When I have had jobs that involved a significant amount of data collection, analysis, and presentation, once I had futzed around for a while and knew what I was doing, reasonable amounts of time were spent automating. Not only to save time, but to reduce error rates, well mostly, sometimes automation can have snags. The work I did left me with the perspective that “if it can be automated, it will be”. Which is a little bit like saying “if what you are doing can be automated, you better look for a new way to add value”. Automation, love it or hate it, it is the stuff of productivity gains that also facilitates vastly increased scale.
When we add something to networking, but don’t automate it, that may place a burden on operations. For example, if we all decide that IP address summarization is the only way to scale an IP network, then we have created a network address plan burden somewhere, because with a network address plan, summarization can be difficult, or at least sub optimal. The alternative is to deal with more information in routing and forwarding tables. An IP routing network that only had host addresses could a) be optimized in the forwarding plane to just do exact match host address-based forwarding and b) would have much larger routing and forwarding table requirements, which would not only be expensive, it may have not even been possible at some points in the past. There are any number of tradeoffs between human labor, processing/storage capacity requirements in routers, and automation.
It is similar in business. If you work on business transformation for example, and you are trying to push through a new quote to cash model, if the people that have to make it happen, realize it is not going to be automated and it is going to cause them more manual work, expect a bunch of other reasons not related to that, why it cannot be done. People don’t like to come across as not supporting change. They also don’t like additional manual work thrust in them. Result: obfuscation of what the real issue is, another information problem.
Manual configuration: what is not automated, increases burden on people, and compromises network efficacy
This point has been covered already, but it is worth emphasizing, if something new is added to the pile of manual work that has to be done, without automating it, it becomes an inhibitor to change, suffers from resistance, places additional burden on operations, and possibly lead to compromising the efficacy of the network if there are frequent errors in the manual changes.
From one admittedly narrow perspective, humans are just information processing, storing and transmit / receive units. We are going to have the same kinds of information problems as silicon-based life forms, even if we each have different quirks. We are going to have similar problems arise from hierarchy, we are going to have similar problems arise from merging information from different sources, and we for sure have limits. Many lessons learned from networking are applicable to other aspects of life, and many aspects of life have lessons for networking. In the end, there are many common information benefits and challenges.