A Simple Routing Protocols Decomposition Model - Part 2 (Peering Mgmt.)

 

So in the first part of the series, we started with rather a simple decomposition model to get bit more insights into the routing protocol internals.

So let's continue the series by expanding on the very first layer in our model - Peering Management.

In any routing protocol before we get fancy in terms of which all features, functions and knobs to use, the very basic requirement is to peer with other devices into the network since eventually a routing protocol is nothing but a distributed database. Routing protocols are designed to convey different set of information to its peer devices such as:

- Topology Information

- Reachability Information

- Policy Information

The type of information that a given routing protocol would exchange with its peers would largely depend on the protocol itself (OSPF, IS-IS, BGP) & where that proposed routing protocol is used into the network (Campus, WAN, Metro-E, DC) as implementation specifics do change.

[ Click on Image to Enlarge ]

As you may notice, there are lot of things working behind the scenes when it comes to peering in a routing protocol context. But don't get carried away by looking at the complexity. Once you look closely, all of these pieces kind of makes sense.

So let's start with the top row, reading it from left to right. 

Self Identity - Before the routing protocol determines whom it needs to communicate with and what information needs to be exchanged, it must find its own identity first. The most common way to give an identity to the routing protocol instance itself is assigning it a router id (RID). The RID can be configured manually or it can be derived automatically depending upon the platform and NOS. 

In real life assuming network virtualization is much more common today, you are allowed to configure unique RID for each routing protocol as well as a unique RID for each instance/process under same protocol. 

Protocol Addressing - Once the routing protocol is able to define its identify with a RID, the next step is to understand it's addressing. The addressing serves many purposes but the most basic one is to provide location services from the overall network view standpoint. Though protocols such as LISP was an attempt to separate device identity from device location, due to limited use cases (such as mobility) and other problems it never really took off well.

Every routing protocol has it's own addressing scheme which may further have impact on its scaling and expected working behavior if not done correctly.

Participation - The next step for the routing protocol is to determine its participating interfaces on a given device and in certain cases the entire device itself. Depending upon the design you may run into some interesting challenges though.

Reliable Transport - Every routing protocol needs a reliable transport to be able to effectively communicate with its peer device. The reliability itself is an important aspect and while some routing protocols such as BGP rely upon existing TCP stack, others like OSPF uses IP protocol 89 & EIGRP choose its own transport protocol namely RTP.

Neighbor Discovery - In the next step the protocol must discover its peer/neighbor/adjacent device depending upon which routing protocol you are following. The protocol while ideally should keep a track of its neighbor and relationship state, this may or may not be implemented.

The neighbor could be configured manually or dynamically discovered, while the discovery phase itself may use unicast or multicast as a transport for reachability purpose to the next hop device. Also the reachability to the neighbor could be over layer 2 transport or layer 3 transport depending upon the protocol. IS-IS and many other IOT industrial protocols operate at layer 2 for example. In case of eBGP, the neighbor in fact may be multiple physical hops away.

Neighbor Identity - While we may have discovered our neighbor, it doesn't mean the neighbor itself is a an intended neighbor or a legitimate neighbor always. After all someone might want to spoof or sometimes we may end up discovering somebody completely un-intentionally. So sharing any information with an unexpected neighbor won't make any sense. To prevent this we have several measures which we can put in place such as Authentication, Validating neighbor's identity (remember they also have RID), Validating neighbor based on IP Packet's TTL value etc. such as in OSPF & BGP. The modern day solutions such as SD-WAN usually uses RPKI over TLS/DTLS channel.

Establish Session - Once the neighbor is discovered and validated, we finally establish a session with it. Depending upon the protocol, we might have a single session vs. multiple sessions going on. A simple example would be networks running IPv4 & IPv6 at the same time under single routing protocol instance. While some implementations exchange information related to both IPv4 and IPv6 over a single session, some may do it over a separate dedicated session for each of them. Long time ago there was an attempt to run multi session bgp for MTR (Multi Topology Routing) for network virtualization use cases.

Capabilities Exchange -  This is an another interesting step where the routing protocol running on separate devices exchange capabilities with each other to find the lowest common denominator. For example we know BGP is more like an application that runs on top of TCP as opposed to a pure layer 3 routing protocol which only carries routes. BGP though can carry layer 3 routing information and in case with most vendors it's been the default behavior, BGP does allow us to carry many other set of information depending upon the use case in the form of AFI/SAFI which is essentially an encoding format. For example BGP can carry MAC Addresses information under Layer 2 VPN EVPN address family when enabled. Though with BGP, you got to be cautious about enabling a new capability/address family in production network as highlighted here.

Establish Adjacency - The protocol reach this far and finally the peers are ready to exchange required set of information needed to populate RIB & other details such as topology graph. An interesting example in a routing protocol context would be (In case you are wondering in which scenario two devices would be neighbors but not adjacent) OSPF.

Messages Exchange - Finally we [assuming by now you are thinking like a routing protocol :) ] reach this stage where in we finally start exchanging information through messages. The messages needs to be sent reliably, keeping track of to understand which one to prefer in case of being received from multiple sources, acknowledged and so forth besides how to queue and dequeue them and at what intervals those should be sent out vs. being hold back for a while to pack multiple events together for optimization and getting the latest information being sent out.

Further Readings:

Cisco IP Routing: Packet Forwarding and Intra-domain Routing Protocols: Packet Forwarding and Intra-domain Routing Protocols 

Network Routing: Algorithms, Protocols, and Architectures

Network Algorithmics,: An Interdisciplinary Approach to Designing Fast Networked Devices

Inside Cisco Ios Software Architecture

HTH...

A Network Artist 🎨

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 🎨