Privacy for Providers

While this talk is titled privacy for providers, it really applies to just about every network operator. This is meant to open a conversation on the topic, rather than providing definitive answers. I start by looking at some of the kinds of information network operators work with, and whether this information can or should be considered “private.” In the second part of the talk, I work through some of the various ways network operators might want to consider when handling private information.

Hedge 137: Old FRR Defects

Zero-day defects exist in every projects, whether they are open or closed source. John Fraizer and Alistair Woodman join Tom Ammon and Russ White to discuss an old defect John found in the FRR code, the history of this defect, and the problems inherent in finding and resolving defects in large, diverse code bases.

Hedge 136: The IPv6 ULA Mess

IPv6’s designers built the concept of Unique Local Addresses, or ULAs, into the addressing architecture to make network address translation unnecessary for IPv6 deployments. As with many other plans of mice and men, however, the unintended consequences of what is a good idea tend to get in the way. Nick Buraglio joing Eyvonne Sharp, Tom Ammon, and Russ White to discuss the many problems of IPv6 ULA, why it isn’t practical in most network deployments, and the larger question of how standards bodies sometimes fail to consider the unintended consequences of a good idea.

Hedge 135: Simon Sharwood, China, and IPv6

Over the last several years various Chinese actors (telecom operators and vendors) have been pushing for modifications to IPv6 to support real-time applications and other use cases. Simon Sharwood wrote an article over at the Register on their efforts and goals. While this effort began with big IP, moved into new IP, and has been called many other names. These efforts are being put forward in various venues like the IETF, the ITU, etc. Simon Sharwood, who writes for the Register, joins Tom Ammon and Russ White to discuss these efforts.

BGP Intra-AS and Route Reflection

Since BGP is designed to be an overlay protocol, it doesn’t really have good mechanisms for carrying routes within an autonomous system. In this video, I’m discussing some of the techniques developed to carry routes within an AS, including route reflectors.

Hedge 134: Ten Things

One of the many reasons engineers should work for a vendor, consulting company, or someone other than a single network operator at some point in their career is to develop a larger view of network operations. What are common ways of doing things? What are uncommon ways? In what ways is every network broken? Over time, if you see enough networks, you start seeing common themes and ideas. Just like history, networks might not always be the same, but the problems we all encounter often rhyme. Ken Celenza joins Tom Ammon, Eyvonne Sharp, and Russ White to discuss these common traits—ten things I know about your network.

On Building a Personal Brand

How do you balance loyalty to yourself and loyalty to the company you work for?

This might seem like an odd question, but it’s an important component of work/life balance many of us just don’t think about any longer because, as Pete Davis says in Dedicated, we live in a world of infinite browsing. We’re afraid of sticking to one thing because it might reduce our future options. If we dedicate ourselves to something bigger than ourselves, then we might lose control of our direction. In particular, we should not dedicate ourselves to any single company, especially for too long.

Hedge 133: Brooks Westfield and Multifactor Testing

Multi-factor testing is one of the most important jobs a vendor takes on—and one of the most underrated. Testing across all possible configurations and use cases is nearly impossible. Brooks Westbrook joins Tom Ammon and Russ White on this episode of the Hedge to talk about the complexity of multi-factor testing and some of the consequences of that complexity.

Revisiting BGP Convergence

My video on BGP convergence elicited a lot of . . . feedback, mainly concerning the difference between convergence in a data center fabric and convergence in the DFZ. Let’s begin here—BGP hunt and the impact of the MRAI are very real in the DFZ. Withdrawing a route can take several minutes.

What about the much more controlled environment of a data center fabric?

Several folks pointed out that the MRAI is often set to 0 in DC fabrics (and many implementations by default). Further, almost all implementations will use an MRAI of 0 for the first received update, holding the second and subsequent advertisements by the MRAI. Several folks also pointed out that all the paths through a DC fabric are the same length, so the second part of the equation is also very small.

These are good points—how do they impact BGP convergence? Let’s use the network below, a small slice of a five-stage butterfly fabric, to think it through. Assume every router is in a different AS, so all the peering sessions are eBGP.

Hedge 132: DNS Complexity and the DNAME

We all intuitively know the DNS is complex—and becoming more complex over time. Describing just how complex, however, is difficult. Siva Kesava and Ryan Beckett just published a research paper taking on the task of describing DNS complexity, particularly in light of the new DNAME record type. It turns out its complex enough that you can no longer really validate zone files.