CONTENT TYPE
The Hedge 65: Jacquelyn Adams and the Future of Work
Everyone in networking—and beyond networking, in fact—thinks about what the future of work might look like. Jacquelyn Adams joins Eyvonne Sharp, Tom Ammon, and Russ White on this episode of the Hedge to discuss what work might look like based on this era of rapid change, and how you can prepare for that future.
The OSI Model: STOP IT!
The OSI model is perhaps the best-known—and perhaps the most-loved—model in the networking world. It’s taught in every basic networking course, and just about every blog (other than this one) has some article explaining the model someplace or another (for instance, here is one of the better examples).
The reality is, however, that I’ve been in the networking business for 30’ish years and I’ve never once used the OSI model for anything practical. I’ve used the model when writing books because just about every book on networking has to have a section on the OSI model. I’ve used the model when writing a paper comparing two different protocols, back in the multiprotocol days (VIP versus IPX versus IP), but we don’t have those kinds of arguments very often any longer.
So, we all learn the OSI model, and yet I don’t know of anyone who actually uses the OSI model in understanding how protocols work, or how to troubleshoot a network. There’s the “it’s a layer two problem” statement, and that’s about the end its useful life, it seems.
Let me make a suggestion—learn, use, and teach the RINA model instead. Okay, so what is the RINA model? It is the Recursive Internet Network Architecture, hence RINA. The observation John Day made when creating the RINA model is this: there are only four problems you need to solve to move data from one host to another. It just happens that those four problems need to be solved multiple times: across each physical link, between each pair of hosts, and then again between each pair of applications (at least—John Day argues there should be eight layers rather than seven, but that argument is outside the scope of this simple blog post).
The four problems are: transport (which I would call marshaling), multiplexing, error control, and flow control. Protocols that solve these problems tend to solve two of the four problems rather than one; the pairings almost always seem to be marshaling with multiplexing and error control with flow control.
On a single Ethernet hop, multiplexing and marshaling are generally solved by the physical link Ethernet protocol. Error and flow control, on the other hand, are generally solved by the data link protocol (something we don’t much think about any longer). Again, multiplexing and marshaling are generally solved by IP, while error and flow control are generally solved by TCP.
The model doesn’t perfectly describe the purpose of every protocol in the modern networking stack, but it comes much closer than the OSI model. Since it’s recursive, you can even insert layers to represent tunnels without a lot of hand-waving in the process, or “breaking” the model.
Why is the RINA model better for understanding protocols? Because it describes what the protocol is trying to accomplish, rather than where it lives in the stack, or what kinds of interfaces it provides. Why is the RINA model better for troubleshooting? Because if you know what isn’t working, it gives you a better general area to look in to find the problem.
My challenge for 2021 is, then—learn and use the RINA model. I (humbly) believe it will actually make you a better network engineer.
On Important Things
I tend to be a very private person; I rarely discuss my “real life” with anyone except a few close friends. I thought it appropriate, though, in this season—both the season of the year and this season in my life—to post something a little more personal.
One thing people often remark about my personality is that I seem to be disturbed by very little in life. No matter what curve ball life might throw my way, I take the hit and turn it around, regain my sense of humor, and press forward into the fray more quickly than many expect. This season, combined with a recent curve ball (one of many—few people would suspect the path my life has taken across these 50+ years), and talking to Brian Keys in a recent episode of the Hedge, have given me reason to examine foundational principles once again.
How do I stay “up” when life throws me a curve ball?
Pragmatically, the worst network outage in the world is not likely to equal the stresses I’ve faced in the military, whether on the flight line or in … “other situations.” Life and death were immediately and obviously present in those times. Coming face to face with death—having friend who is there one moment, and not the next—changes your perspective. Knowing you hold the lives of hundreds of people in your hands—that if you make a mistake, real people will die (now!)—changes your perspective. In these times you realize there is more to life than work, or skill, or knowledge.
Spiritually, I am deeply Christian. I am close to God in a real way. I know him, and I trust his character and plans for the future. Job 13:15 and Romans 12:2 are present realities every day, from the moment I wake until the moment I fall asleep.
These two lead to a third observation.
Because of these things, I am grateful.
I am grateful for the people in my life—deeply held friendships, people who have spoken into my life, people who have helped carry me in times of crisis. I am grateful for the things in my life. Gratitude is, in essence, that which turns what you have into what you want (or perhaps enough to fulfill your wants). Gratitude often goes farther, though, teaching you that, all too often, you have more than you deserve.
So this season, whatever your religious beliefs, is a good time to reflect on the importance of all things spiritual, the value of life, the value of friendship, the value of truth, and to decide to have gratitude in the face of every storm. Gratitude causes us to look outside ourselves, and there is power (and healing) in self-forgetfulness. Self-love and self-hate are equal and opposite errors; it is in forgetting yourself, pressing forward, and giving to others, that you find out who you are.
Have a merry Christmas, a miraculous Hanukkah, or … just a joyful time being with family and friends at home. Watch a movie, eat ice cream and cookies, make a new friend, care for someone who has no family to be with.
To paraphrase Abraham Lincoln, most folks are just about as happy as they choose to be—so make the choice to be joyful and grateful.
These are the important things.
The Hedge 64: Brian Keys and Burnout
Burnout stalks most network engineers—and most people in the world of information technology—striking at least once in every career, it seems, and often more than once. In this episode, Brian Keys joins Eyvonne Sharp, Tom Ammon, and Russ White to discuss his personal experience with burnout. The discussion then turns to general strategies and ideas for avoiding burnout on a day-to-day basis.
Pulling Back the Curtains
One of the major sources of complexity in modern systems is the simple failure to pull back the curtains. From a recent blog post over at the ACM—
Yegor describes three different reactions when a coder faces something unexpected when solving a problem.
Throw in the towel. Just give up on solving the problem. This is fairly uncommon in the networking and programming fields, so I don’t have much to say here.
Muddle through. Just figure out how to make it work by whatever means necessary.
Open the curtains and build an excellent solution. Learn how the underlying systems work, understand how to interact with them, and create a solution that best takes advantage of them.
The first and third options are rare indeed; it is the second solution that seems to dominate our world. What generally tends to happen is we set out to solve some problem, we encounter resistance, and we either “just make it work” by fiddling around with the bits or we say “this is just too complex, I’m going to build something new that simpler and easier.” The problem with building something new is the “something new” must go someplace … which generally means on top of existing “stuff.” Adding more stuff you do understand on top of stuff you don’t understand to solve a problem is, of course, a prime way to increase complexity in a network.
And thus we have one of the prime reasons for ever-increasing complexity in networks.
Yegor says being a great programmer by pulling back the curtain increases job satisfaction, helping him avoid depression. The same is probably true of network engineers who are deeply interested in solving problems—who are only happy at the end of the day if they know they have solved some problem, even if no-one ever notices.
Pulling back the curtains, then not only helps us to manage complexity, it can alos improve job satisfaction for those with the problem-solving mindset. Great reasons to pull back to the curtains, indeed.
The Hedge 63: Anycast with Andree Toonk
Anycast is a bit of a mystery to a lot of network engineers. What is it, and what is it used for? Andree Toonk joins Tom and Russ on this episode of the Hedge to discuss the many uses of anycast, particularly in the realm of the Domain Name Service (DNS). Andree helped build the OpenDNS network and service, so he has deep experience with anycast routing on the DFZ.
Current Work in BGP Security
I’ve been chasing BGP security since before the publication of the soBGP drafts, way back in the early 2000’s (that’s almost 20 years for those who are math challenged). The most recent news largely centers on the RPKI, which is used to ensure the AS originating an advertisements is authorized to do so (or rather “owns” the resource or prefix). If you are not “up” on what the RPKI does, or how it works, you might find this old blog post useful—its actually the tenth post in a ten post series on the topic of BGP security.
Recent news in this space largely centers around the ongoing deployment of the RPKI. According to Wired, Google and Facebook have both recently adopted MANRS, and are adopting RPKI. While it might not seem like autonomous systems along the edge adopting BGP security best practices and the RPKI system can make much of a difference, but the “heavy hitters” among the content providers can play a pivotal role here by refusing to accept routes that appear to be hijacked. This not only helps these providers and their customers directly—a point the Wired article makes—this also helps the ‘net in a larger way by blocking attackers access to at least some of the “big fish” in terms of traffic.
Leslie Daigle, over at the Global Cyber Alliance—an organization I’d never heard of until I saw this—has a post up explaining exactly how deploying the RPKI in an edge AS can make a big difference in the service level from a customer’s perspective. Leslie is looking for operators who will fill out a survey on the routing security measures they deploy. If you operate a network that has any sort of BGP presence in the default-free zone (DFZ), it’s worth taking a look and filling the survey out.
One of the various problems with routing security is just being able to see what’s in the RPKI. If you have a problem with your route in the global table, you can always go look at a route view server or looking glass (a topic I will cover in some detail in an upcoming live webinar over on Safari Books Online—I think it’s scheduled for February right now). But what about the RPKI? RIPE NCC has released a new tool called the JDR:
Finally, the folks at APNIC, working with NLnet Labs, have taken a page from the BGP playbook and proposed an opaque object for the RPKI, extending it beyond “just prefixes.” They’ve created a new Resource Tagged Attestations, or RTAs, which can carry “any arbitrary file.” They have a post up explaining the rational and work here.