How I met FRR

FRR or Free Range Routing is a routing software suite. It is open source that is distributed under the terms of GPLv2. It is widely deployed in data centers via CumulusLinux.

My first FRR encounter was three years ago. One of the multicast applications that I was working on at that time needed support for anycast-RP (Rendezvous Point). FRR already had support for PIM (Protocol Independent Multicast) and it simply needed to be extended. 

This was 2016 and I was a networking-forwarding engineer. Now what exactly does a forwarding engineer do? Well usually one or both of two things. Develop the networking stack that terminates traffic and in some cases, software forwards it. And/Or handle hardware acceleration of packet forwarding via a network ASIC. These days hardware acceleration is typically via a merchant silicon manufactured by Broadcom or Mellanox or Marvell etc. 

So not only did I come from a world of closed source, I dealt with third party SDKs (Software Development Kits). These SDKs are wrapped in layers of ironclad NDAs. So I never got to write about my work; Hell I was afraid of even telling Violet what I really did! Violet is my six year old daughter. Kids these days are very social media savvy; what if she tweets about Tridents?!

Well anyway, here I was. Having spent a lifetime writing closed source code; suddenly thrown into the world of open source. But to me it really wasn’t a question of closed source vs. open source. Or having to go through a philosophical change of mindset. It was really about implementing a network protocol using an existing infrastructure. And that infrastructure happened to be the open-source FRR.

The protocol I needed for anycast-RP was MSDP (Multicast Source Discovery Protocol). In case you haven’t heard about it that’s PIMs skinny second cousin. Implementing something like MSDP requires the supporting infrastructure to already be there. And sure enough FRR had all the necessary libraries. It was scalable, readable and extendable. Three weeks later MSDP was done. 

People who know me know that I am deliberate (yeah, that is a euphemism for slow!). So it was really FRR that catalyzed MSDP into happening quickly.

After MSDP I went back to writing more closed code. Then EVPN called and who can refuse that call! So I am back as a full time FRR developer, implementing features like EVPN-PIM and EVPN Multihoming in FRR. And this time around I got to linger on the philosophical questions around open source.

Open source in the networking-past has been limited. Network designs have been opened up with the intent of industry standardization. But the code itself has been kept closed, mostly. Locked up as secret sauce. The occasional opening of code has had questionable motives. Community edition as a teaser for the commercial edition i.e. the real shit (which is firmly closed). Or done as a counter move to squash competitors; remember ODL (open day light?).

FRR is different. It is that real shit. Actively developed and actually deployed. FRR is not just code, it's a vibrant community. It has folks like Vivek Venkatraman and Russ White who have been dancing with routing protocols for decades. It has the new wave of engineers like Quentin Young and Sarita Patra who are already rocking it. It has Donald Sharp with his manic energy.

Now I see FRR everywhere, in SONiC (Microsoft Azure), in DENT (Amazon’s Distributed Enterprise), in Red Hat’s distribution. As FRR continues its climb to becoming the routing suite of choice you have to wonder; are the days of developing routing protocols, OSPF, BGP, PIM, ISIS, MPLS, from scratch (just so they can be packaged into a closed source binary) over?

The advantages of open source seem apparent i.e. you know what you are using. You can build tools, apps on top of it. But could closed source be preferred for some reason?

What questions would a network architect ask while building a new site. Does the software serve the purpose? Is it robust? Does it scale well? Is it already deployed in similar applications? 

Would the question of open vs. closed source feature on that list?