Russ

About Russ

This author has not yet filled in any details.
So far Russ has created 1142 blog entries.

Thoughts on Impostor Syndrome

How many times, on reading my blog, a book, or watching some video of mine over these many years (the first article I remember writing that was publicly available, many years ago, was the EIGRP white paper on Cisco Online, somewhere in 1997), have you thought—here is an engineer who has it all together, who knows technology in depth and breadth, and who symbolizes everything I think an engineer should be? And yet, how many times have you faced that feeling of self-doubt we call impostor synddome?

I am going to let you in on a little secret. I’m an impostor, too. After all these years, I still feel like I am going to be speaking in front of a crowd, explaining something at a meeting, I am going to hit publish on something, and the entire world is going to “see through the charade,” and realize I’m not all that good of an engineer. That I am an ordinary person, just doing ordinary things.

While I often think about these things, what has led me down the path of thinking about them this week is some reading I’ve been doing for a PhD seminar about human nature, work and leisure. Another part of the reason is that I have been struggling recently with some specific things at work. And, finally, another part of the reason is that I ran into a terrific post over at The Humble Lab on the topic of the impostor syndrome.

Some of this will be in agreement, and echoing, what I’ve read in other places. Other parts of this will be unique to my worldview (worldview warning here, for those too delicate to read things from a different perspective). Yes, this is going to be an honest post. Yes, this is going to be a long post.

Why do I feel like an impostor? For me, it is often fear. I think this is probably true of most people, if we are to be honest with ourselves.

I know many people who are afraid of public speaking. When talking to them in depth about this, what I normally find is a fear of failure. Some people who don’t get a degree or certification are hindered by a fear of failure. There are two kinds of fear of failure, I find: looking foolish in front of others, and losing control. I used to be able to climb tall towers without clips, and without fear. I could monkey the side of the RADAR tower at McGuire, 90 feet tall, and walk around on the top platform knocking wooden blocks out of their stays with a sledge. I could shimmy a 30 foot pole to reach the wind bird. I would struggle in doing those things now; I think more about what I cannot control.

So part of what drives the impostor syndrome is these two kinds of fear: fear of failure, and fear of losing control. Both of these tend to manifest themselves in another fear: the fear of missing out.

What can we do to address these fears? One answer I often hear is “man up and deal with it.” In other words, just address your fears, and get over them. There is some truth in this answer. Sometimes this is really what is necessary. My daughters have a hedgehog; this is one scared little animal. The only way the little hedgie is going to learn that it’s okay is to be placed in traumatic situations, and for nothing to happen. Sometimes we are hedgehogs, and our nails just need to be trimmed for our own good.

Sometimes you just have to deal with fear and keep going. Sometimes you are going to fail. It’s okay to fail.

To quote The Humble Lab here—

The point is, it’s what you do with that failure that defines you—not the fact that you failed at all. We need to drive a culture that encourages people to learn from failure, and grow from it.

But there is a danger in this answer, as well—that we will take this as the only answer. That whenever we face something we fear, or some obstacle, we will say to ourselves, “you can do anything you set your mind to, if you just try hard enough.” Or even “you can use every failure to learn something,” which implies that if you don’t learn from a failure, you are… a failure. The danger here is when stated absolutely, this is a lie. You cannot do anything you want to if you just set your mind to it. I cannot be a great baseball player, ice skater, or Olympic swimmer. I simply do not have the bodily attributes to do such things. And no amount of failure, with the attendant learning, is going to make me any of those things. Sometimes what you need to learn is I cannot do this.

This leads to a second answer to the impostor syndrome: learn to live in your limits There is a difference between pushing yourself to achieve something and pushing yourself too hard. I cannot tell you how to know the difference, because I think it is different for every person, but I know there are times in my life when I have pushed too hard. The more you realize that everyone has limits, the less limited you will be by your own limits.

For instance, I recently picked up a small bit of thinking by reading about Keith’s Law in the area of complexity. One of the corollaries of Keith’s Law is this:

You can only know what is at your layer, and a little above and below. The rest is rumor and pop psychology.

We work on complex systems. When I was in tech school in the USAF, we had one classroom where all the circuit diagrams for the AN/FRPS-77 RADAR system had been pieced together into one large diagram on the wall. This is before the days of the computer being common, of course, so everything was on paper. Folks from other career fields would borrow that room from time to time, and that set of patched together diagrams always gave them a start. Yes, a RADAR system is complex. But the systems I deal with now, networks and their environment, are far more complex. I can describe the intersection topological aggregation and summarization, virtualization, and protocol stacks, but there is no way I could draw it.

The reality is I cannot know it all. And that means there will be many times when I push a button, thinking it will do one thing, and it will actually do another. In other words, I will fail. Not because I intended to fail, but simply because I do not have all the knowledge in the world.

Not knowing does not make me a bad person, or a bad engineer; it just makes me human. It is okay to be human, and it is okay to fail because I don’t know everything.

Another answer to the impostor syndrome is to learn more. This is in tension with the second point, I know, but it is still an important point. Just like being afraid does not let you off the hook of dealing with hard situations, accepting that you cannot know everything does not let you off the hook of learning new things. There is a technique to learning, of course, but I have talked about this enough in other places (here, for instance), and this post is already too long.

Intentionally learn to counter your fears.

Finally, there is something else that needs to be said here: perhaps the best guard against impostor syndrome is to live and work in a community. Not a community of competitors, or a community of followers, but rather just a community. This means you need to stop trying to compete with everyone around you, and it means you need to stop treating everyone around you as competitors. It means not thinking I am better than another person because I know more, or I have done more. It means opening up about my fears with that community, and not being afraid to ask for help when I don’t know. It means accepting that I am never the smartest person in the room.

Intentionally build, and be a part of, a community. It’s okay to fail in front of other people.

On the ‘net: The Tradeoffs of Information Hiding

I recently joined Ethan Banks for a Packet Pushers episode around the trade offs of hiding information in the control plane. This was a terrific show; you can listen to it by clicking on the link below.

Today on the Priority Queue, we’re gonna hide some information. Oh, like route summarization? Sure, like route summarization. That’s an example of information hiding. But there’s much more to the story than that. Our guest is Russ White. Russ is a serial networking book author, network architect, RFC writer, patent holder, technical instructor, and much of the motive force behind the early iterations of the CCDE program.

Weekend Reads 071318: Nice to Haves

I had about four hours of highway driving yesterday. Even though I probably could’ve navigated it on my own, I opted to use Apple Maps, which is integrated with my car’s Apple CarPlay “infotainment center.” It was nice. It told me how many miles I had remaining and my expected time of arrival. But it wasn’t a life changer. @The Old Reader

More than ever before Internet users are now interacting with people living/working in other economies. And as a result of these interactions, there are an increasing number of ‘legal contracts’ (intentional or not). Internet policy researchers and academics debate about the changing landscape and the boundaries of the international and domestic laws, without conclusive agreements. —Yeseul Kim @APNIC

The plague that is Spectre continues to evolve and adapt, showing up in two new variants this week dubbed Spectre 1.1 and Spectre 1.2 that follow the original Spectre’s playbook while expanding on the ways they can do damage. —Curtis Franklin Jr. @Dark Reading

These vast routing events that are propagated globally already provide a hint that some ISPs do not set filters at all, or there are vastly malformed AS-SETs. We decided to measure the number of filters that were already bypassed by routing anomalies. To do so, we checked the way route leaks were propagated: if a route leak is received from a customer link and it does not belong to the customer cone then IRR filters were malformed. —Alexander Azimov @APNIC

Recently, a CEO of a roaring unicorn in Silicon Valley drew my attention to the following: “If you compare Amazon’s stock price over the recent years against the cost of housing and the rise of homelessness in Seattle, the progression is identical…” —Frederic Filloux @MondayNote

Why do many problems in life seem to stubbornly stick around, no matter how hard people work to fix them? It turns out that a quirk in the way human brains process information means that when something becomes rare, we sometimes see it in more places than ever. —David Levari @The Conversation

Two web-based attacks against IoT devices made the rounds this week. Researchers Craig Young and Brannon Dorsey showed that a well known attack technique called “DNS rebinding” can be used to control your smart thermostat, detect your home address or extract unique identifiers from your IoT devices. —Gunes Acar

Reaction: Some Sayings that Sum Up Networking

Over at the CIMI blog, Tom Nolle has a mixed bag of sayings and thoughts about the computer networking world, in particular how it relates to the media. Some of these were interesting enough that they seemed worth highlighting and writing a bit more on.

“News” means “novelty”, not “truth”. In much of the computer networking world, news is what sells products, rather than business need. In turn, Novelty is what drives the news. The “straight line” connection, then is from novelty to news to product, and product manufacturers know this. This is not just a vendor driven problem, however; this is also driven by recruitment, and padding resumes, and many other facets of the networking nerd culture.

On the other hand, novelty is never a good starting place for network design. Rather, network design needs to start with problems that need to be solved, proceeds by considering how those problems can be solved with technologies, then builds requirements based on the problems and technologies, and finally considers which products can be used to implement all of this at the lowest long term cost. This is not to say novelty is not useful, or is not justified, but rather that novelty is not the point.

How can you overcome the drive to novelty through the news cycle? Go back to basics. Every “novel” thing you are looking at in the latest news story is something that has been invented and implemented before in a different package, and with a different name. Apply rule 11 liberally to all marketing claims, look for the problem to be solved, push back on the requirements, think systemically, manage your own expectations, and go back to basics.

To a user, “the network” is whatever isn’t on their desk or in their device. This is a point folks who work on the network for a living often forget. Talking to a non-networking person about networking technology is often like talking to someone who commutes on the train about how the train works; it might be interesting, but they often just do not care. There are several implications here: the first is that if your business relies on the network (and most do, whether or not they realize it), as the network engineer, you need to go beyond just making the train work, to helping others understand that why and how the network (the train) runs is important to reaching the overall business goals. There is an entire movement within the networking world that would say: “networks are a commodity, just like the train is, just move the packets and shut up.” I do not tend to agree with this; for a city, a train is not a commodity, it is a vital resource that grows business and interacts with people’s lives. The network is like the train to a city; it might be a commodity for the person riding it, but it is not for the overall business.

There’s no substitute for knowing what you’re doing. But what does it mean to “know what you are doing?” In a large complex system, you can know what is on “your layer,” or “your piece of the system,” plus one or two levels above and below. The rest is rumor and pop psychology.

In a world where there is just too much information, how can you “know what you are doing?” First, you can use rule 11 to your advantage, and realize that everything that is, has been before. If you know the underlying technology, then the implementation is much easier to learn (if you need to learn it at all!). If you know the pattern, then you can see the details much more easily. Second, you can insist on radical simplicity, which will make the process of knowing the entire system much easier. Third, you can intentionally think systematically, and functionally, rather than orienting yourself to products.

Recent BGP Peering Enhancements

BGP is one of the foundational protocols that make the Internet “go;” as such, it is a complex intertwined system of different kinds of functionality bundled into a single set of TLVs, attributes, and other functionality. Because it is so widely used, however, BGP tends to gain new capabilities on a regular basis, making the Interdomain Routing (IDR) working group in the Internet Engineering Task Force (IETF) one of the consistently busiest, and hence one of the hardest to keep up with. In this post, I’m going to spend a little time talking about one area in which a lot of work has been taking place, the building and maintenance of peering relationships between BGP speakers.

The first draft to consider is Mitigating the Negative Impact of Maintenance through BGP Session Culling, which is a draft in an operations working group, rather than the IDR working group, and does not make any changes to the operation of BGP. Rather, this draft considers how BGP sessions should be torn down so traffic is properly drained, and the peering shutdown has the minimal effect possible. The normal way of shutting down a link for maintenance would be to for administrators to shut down BGP on the link, wait for traffic to subside, and then take the link down for maintenance. However, many operators simply do not have the time or capability to undertake scheduled shutdowns of BGP speakers. To resolve this problem, graceful shutdown capability was added to BGP in RFC8326. Not all implementations support graceful shutdown, however, so this draft suggests an alternate way to shut down BGP sessions, allowing traffic to drain, before a link is shut down: use link local filtering to block BGP traffic on the link, which will cause any existing BGP sessions to fail. Once these sessions have failed, traffic will drain off the link, allowing it to be safely shut down for maintenance. The draft discusses various timing issues in using this technique to reduce the impact of link removal due to maintenance (or other reasons).

Graceful shutdown, itself, is also in line to receive some new capabilities through Extended BGP Administrative Shutdown Communication. This draft is rather short, as it simply allows an operator to send a short freeform message (presumably in text format) along with the standard BGP graceful shutdown notification. This message can be printed on the console, or saved to syslog, to provide an operator with more information about why a particular BGP has been shut down, whether it coming back up again, how long the shutdown is expected to last, etc.

Graceful Restart (GR) is a long available feature in many BGP implementations that aims to prevent the disruption of traffic flow; the original purpose was to handle a route processor restart in a router where the line cards could continue forwarding traffic based on local forwarding tables (the FIB), including cases where one route processor fails, causing the router switches to a backup route processor in the same chassis. Over time, GR began to be applied to NOTIFICATION messages in BGP. For instance, if a BGP speaker receives a malformed message, it is required (by the BGP RFCs) to send a NOTIFICATION, which will cause the BGP session to be torn down and restarted. GR has been adapted to these situations, so traffic flow is either not impacted, or minimally impacted through the NOTIFICATION/session restart process. This same processing takes place for a hold timer timeout in BGP.

The problem is that only one of the two speakers in a restarting pair will normally retain its local forwarding information. The sending speaker will normally flush its local routing tables, and with them its local forwarding tables, on sending a BGP NOTIFICATION. Notification Message support for BGP Graceful Restart changes this processing, allowing both speakers to enter the “receiving speaker” mode, so both speakers would retain their local forwarding information. A signal is provided to allow the sending speaker to indicate the sessions should be hard reset, rather than gracefully reset, if needed.

Finally, BGP allows speakers to send a route with a next hop other than themselves; this is called a third party next hop, and is illustrated in the figure below.

In this network, router C’s best path to 2001:db8:3e8:100::/64 might be through A, but the operator may prefer this traffic pass through B. While it is possible to change the preferences so C chooses the path through B, there are some situations where it is better for A to advertise C as the next hop towards the destination (for instance, a route server would not normally advertise itself as the nexthop towards a destination). The problem with this situation is that B might not have the same capabilities as a BGP speaker as A. If B, for instance, cannot forward for IPv6, the situation shown in the illustration would clearly not work.

To resolve this, BGP Next-Hop dependent capabilities allows a speaker to advertise the capabilities of these alternate next hops to peered BGP speakers.

Complexity Sells

According to Roman philosophers, simplicity is the hallmark of truth. And yet, networks have become ever more complex over time. Why is this? Because complexity sells. In this short take, I talk about why complexity sells, and some of the mental habits you can use to overcome our natural tendency to prefer the complex.