I see this question rather often asked on various social media. A post on Twitter a few days ago triggered this little blog post and I deeply appreciate the poster. The question was simple “Is it really necessary for an engineer to know or understand the key RFC numbers?”. Some of the engineers I work with once took it to the next level – that let’s call a spade a spade, right? So; “The RFCs are so dry and rigid that are hard to follow, can I skip those?”. There are two questions hidden here and that’s actually one question. “Do I need to know and understand the RFCs themselves?” and “Do I need to know and understand the RFC numbers?” . Well, to me the argument between the two is a moot point and I’ll show you why.
But what are the RFCs after all?
To start off, the word RFC stands for “Request For Comment”; and if you’re a bit familiar with a few RFCs, you already know at least on the surface they are not necessarily a request for any comments as it would be the intended meaning in English. But there is more to this.
In contrast to what many engineers think, the only application of RFCs is not to define a standard. In fact, the IETF clearly says “RFCs produced by the IETF cover many aspects of computer networking. They describe the Internet’s technical foundations, such as addressing, routing, and transport technologies.” .
What that entails is that instead of each vendor defining their own way of doing things, the Internet Engineering Task Force (IETF) has a long list of Working Groups (WG) that are formed by the community to discuss different key topics, developments and improvements needed in each area. For instance, if you love BGP as much as I do, one of the coolest things you could do is to subscribe to the IDR (Inter-Domain Routing) Working Group’s mailing list.
While at times, the amount of back and forth on the mailing list could be overwhelming, yet there are ways to summarize updates and catch up on the latest developments around BGP version 4 with IPv4 or IPv6. As a bonus point, you’ll know the most active people and companies in that field.
The WG for IDR explains this as “The IDR working group will work on correctness, robustness and capability of the BGP protocol, as well as clarity and accuracy of the BGP document set. The group will also work on extensions beyond these areas when specifically added to the charter.”. Practically speaking this includes one of my favorite topics including this one: “Specify a means to non-disruptively introduce new BGP Capabilities to an existing BGP session.”.
Even if you just listen in to the chatters, without actively participating in them, before long you’ll find out the WG is currently working on “BGP Color-Aware Routing (CAR)” which is led by Cisco Systems. The minimum benefit here is that if an interviewer challenges you that “Your resume says expert level knowledge in BGP; tell me about the newest thing you know about the protocol”, you won’t have to talk the 4B ASN traversal story or how BGP supports IPv6. That’s an update as of last week; hot out of the oven.
That all said, there are different types of RFCs and serve different purposes: Internet Standard, Proposed Standard, Experimental, Informational, Best Current Practice, and Historic are the six different categories at the time of this writing. Again, not everything is centered around Internet Standards. For example, one of my favorite RFCs is an informational one that it contains a ton of useful information to run BGP in data centers at massive scale or RFC-7938. While it does not explain anything brand new that you have never seen before, it makes certain suggestions to vendors and operators, that helps people like me understand yet another way to deploy a routing protocol at scale in massive data center that actually works, along with all the pros and cons. This RFC of course is built on top of RFC-4271, which is the latest BGPv4 standard, which in turn obsoleted the legendary RFC-1771 (or RFC-1654), that had defined the nuances of BGP as the de facto standard for the IDRs in 1995. But RFC-7938 goes after one very specific purpose, and that’s one of the applications of BGP at scale.
The readers might ask, that’s you, who else might have the same need or passion? I mean, “why would anyone care?”. I configure my routers and switches as the configuration guides say and they always work just fine. Well, at least almost always.
There is a long list of people who could benefit from spending time on RFCs; to name a few: network or security engineers and architects and even a large group of CNEs (Cloud Network Engineers). If they wish to go beyond junior and mid-senior level, they will need to know and understand the RFCs:
- People involved in product development
No matter if you’re developing your own white box products, working for a networking or security vendor as a PM (product Manager), TME (Technical Marketing Engineer) or a SDE/SDM in software development, you can’t just do what you feel is right. In reality, no one will stop you from developing a a well-known protocol they way it doesn’t follow any standards or best practices outlined by the RFCs; although you are going to have a really hard time marketing that, deploying your solution and then making it work in real networks alongside what’s out there. Such solution, in many cases must go through the IETF (and at times the very slow IETF) process. Admittedly, nothing is impossible. If you are large enough or extremely efficient to force your ideas upon the community and convince them about your amazing benefits, you might get away with that but that’s probably not something just everyone would want to try. To close the loop here, if you’re a competent PM, TME, SDE or SDM working for a vendor you must know the RFCs related to your field inside-out. You need to be very much familiar with how your competition has implemented those, how you can fit your ideas within the guardrails of the RFCs and where you have to deviate. You need to master that not just to develop your products but because many customers will ask; the same way when you’re purchasing a car you ask if the vehicle has the steering wheel on the left or right. Why would they? Keep reading.
- People involved in multi-vendor environments
So why would anyone want to know if and how you support a particular standard? There are many reasons, but the main driver here is that many networking and security deployments are multi-vendor. In the core you have your Cisco routers, the top-of-rack solutions are white boxes, the VPN solutions are Palo Alto, while you have Juniper at the edge. This doesn’t stop your customer connectivity team to deploy Arista boxes in the POPs. Let’s go back to the BGP example; I guess, one can live with different timers across multiple vendors. After all, we will talk and agree on something; even something like ISIS won’t care much. But beyond the basic, how does each vendor handle the route aggregation process in BGP? Do we carry the AS_SET? Do we really have to? What if a young engineer, after passing his CCIE assumes everyone does aggregation the way Cisco does? The engineers and architects involved in multi-vendor designs must be familiar with the RFCs. In fact, having sat on the vendor side of the table for year, it would surprise me if any of a customers do not ask about our “deviations” from the RFC and how we handle inter-operability, at the latest during the PoC. Therefore, anyone beyond the junior person who does what he or she is told, needs to know how each vendor behaves; and that’s not random. They either follow an RFC or take their own path to an extent; regardless the engineers and architects would need to understand the consequences. Or even at times, needs to choose one over the other to optimize their architecture. But even then, sometimes even with all the precautions, they get in trouble; there might be a software bug or an undiscovered non-RFC behavior; that leads us to the next bullet point:
- People involved in advanced troubleshooting
Not just the TAC engineers. Everyone who deal with “deep” troubleshooting cases need to understand how different technologies are implemented and behave, beyond the configuration guides. Here I emphasize on the keyword “deep” because at this point we’re going beyond the show commands and what one would expect to see. Here is where you’re drawn into a flurry of captured packets to analyze flows and you are scratching your head, trying to find out why your firewall is now permitting certain traffic in for one new neighbor while in 99 previous customer cases that you never encountered any issues. Why this particular code or platform? Is it a bug? Or something else?
- People involved in job interviews for advanced positions
I saved this for the last. While it’s not the most technically elegant reason, yet we care about the outcome of our job interviews. If you’re looking to demonstrate your deep knowledge instead of offering lengthy answers to simple questions that could eventually bore the interviewer, next time try this technique. Strengthen your understanding of the key RFCs in your space and how the behaviors of major technologies (say routing protocols) have changed from one RFC to another. I bet you 99% of interviewers, when they ask about BGP route reflectors are not aware of all the changes they’ve gone through. Let’s have you take a look at RFC-1966 and RFC-4456 as your homework. What a pleasure it would be to hire and work with someone who understands such nuances and not just what their CCIE or JNCIE books have told them!
At this point, I hope some of the readers are convinced that there is value in knowing the RFCs and spending time on them as one effective way to take your networking knowledge to the next level.
Now, let’s go back to the original question to show you why I painted that as a moot point: “Do I need to know and understand the RFC numbers too?”. Ask Janet. Janet once was a junior engineer. She worked and studied long hours including weekends and late-night shifts to climb up the slippery ladder of her job and then the CCNP and CCIE/JNCIE certifications. Ten years later she’s a seasoned and qualified architect. She also took my advice and even doubled down on it. She printed out 50 major RFCs related to her field and not just studied them but gutted the documents by highlighting portions on them and comparing how major vendors have implemented each one of the “features”. She spent almost a year to get there. She also regularly visits the web page of her WGs to learn about the latest development in the field or has subscribed to their mailing lists. In all honesty, I don’t think that’s a question Janet would bother herself with. She lives with those numbers and can’t unsee them. I asked her and she said I never attempted to memorize them, it happened naturally.
Long story short, do I really need the RFCs? Remember even if you are not developing products, you might be purchasing, and even if you are not purchasing you might wind up in an interoperability troubleshooting case involving different codes from the same vendor or even multiple vendors. But as usual, probably no one will force you to love the RFCs; except your passion to be in that top 1% who know why it is not working.
