A Simple Routing Protocols Decomposition Model - Part 1

 

You might have heard about this term "Mental Models" earlier too. Mental models are essentially a very simple yet very powerful tool. At its core the purpose of mental models is to provide you with necessary tools and building blocks in order to understand how something is really built and how it works behind the scenes.

Whether we recognize this or not, we all have mental models of some kind in our mind that we use and apply to situations in our daily life. It's just that some of those are developed consciously to solve certain problems or how to we approach certain things, on the other hand some of those are genetically coded into our DNA by nature.

A quick example of consciously developed mental model would be "How do you manage your finances" while the unconscious one would be to "Run fast when you see a lion charging towards you".

The mental models can be simple or complex, layered and even blend of multiple models depending upon how complex the topic is at hand and how deep you want to go down the rat hole beside in some cases tracing down the roots of the real problem into its adjacent domains.

Last but not least, your experiments and experiences always help you enrich you mental model aka "Lesson learned the hard way". On the flip side mental models do create "biases" if totally ignored, as one of the tradeoffs to follow them. But we will keep that topic besides the other tradeoffs for another time.

Now you might be wondering:

1. What is than Decomposition Model

2. Do we have some of those being available for IP Networking

To answer the 1st one - The famous consulting firms were looking for some more glamorous term which would resonate better with business people, after all technology details looks boring to them for most part and they started calling it "Decomposition Models" and heavily use this term in various cases such as for "Maturity Model" .

Coming back to 2nd one which is more relevant for this conversation, IP Networking actually taught us few mental models at the very beginning of our career as Network Engineers in the form of - OSI Model, TCP/IP Model, RINA Model, Hourglass Model and so forth. But as we advance further into our journey, the numbers of models available to us starts to shrink if not completely disappear with an ultimate answer to every question not as the "number 42" but the magical two words " It depends ". Standard bodies such as IETF, IEEE, MEF & ONUG etc. don't offer much help either for the most part.

But then nothing stops you from to being a little more creative and come up with your own models.

Let's start with a " Routing Protocol Decomposition Model ".

It's a multi-purpose simple yet effective model that you can consider for :

- As a Routing Protocol Designer it allows you to breakdown the complex equation into smaller chunks

- As a Network Architect it allows you to breakdown you design choices into smaller & distinguishable sections/containers and allow you to tune the variables to achieve certain outcomes while having a better view of "Tradeoffs" that you are going to make as part of the process

- As an Implementation Engineer it allows you to breakdown the device configuration into logical containers which are easier to manage, understand & configure beside without falling in the trap of - Order of operation issues

- As an Automation Engineer (NetDevOPS, NetOPS, NetSecDevOPS of whatever else you may call it) it allows you to break down the protocol in such a way that you can now easily write a Data Model to code it, write test units for each individual block and so forth beside develop a "YANG Model" or build a " CICD Pipeline "

- As an Operation Engineer or TAC Engineer it allows you to approach the whole process more logically if you follow the direction of "Arrow" as it allows you to understand "Dependencies" as part of layered approach

- As a Systems Architect it allows you think clearly about " Interaction Surfaces" & " Leaky Abstractions " beside understanding " Dependency Relation "

- Helps you form an " Abstraction Model " to hide complexity & inner-workings/details

- It allows you to plan " Streaming Telemetry " better as you can map your use cases and dependencies more easily and feed it into a magical " Intent Based Networking (IBN) " solution

- A consultant can use this for "Maturity Modelling" & " Assessment/Observability "

- A tool to apply " Critical Thinking " to routing protocols

In next part of this series we we bring this model from current 10,000 feet view to 1,000 feet view by start populating sub blocks under each major block.

Meanwhile as an exercise, try to think of any feature or knob of your favorite routing protocol as see if there is anything you can think of that wouldn't fit into any of those layers. :)

HTH...

A Network Artist 🎨