Worth Reading: The IETF as a model
The post Worth Reading: The IETF as a model appeared first on 'net work.
Worth Reading: Certification road map
The post Worth Reading: Certification road map appeared first on 'net work.
Worth Reading: Is your tax data secure?
The post Worth Reading: Is your tax data secure? appeared first on 'net work.
Worth Reading: Topology of malicious activity
The post Worth Reading: Topology of malicious activity appeared first on 'net work.
Worth Reading: Rolling the root
The post Worth Reading: Rolling the root appeared first on 'net work.
RFC Reading List
While we normally think of RFCs as standards, there is actually a lot of useful information published through the IETF process that relates to basic network engineering concepts. Since this information is specifically and intentionally vendor independent, it often goes back to the theoretical basis of a line of thinking, or explains things in a way that’s free of vendor implementation jargon. From time to time, I like to highlight these sorts of drafts, to bring them to the notice of the wider networking community.
A lot of basic research has gone into quality of service from the perspective of queuing, marking, and dropping mechanisms. The result of this research is a wide array of quality of service mechanisms, which tend to be explained either using deep math, or in terms of “look what feature we’ve implemented, and here’s how to configure it.” RFC7806, published this month, is a useful intermediary between the high math and vendor implementation styles of presentation. This RFC describes a model often used for understanding quality of service, the Generalized Processor Sharing model, and how it applies to a few packet queuing, marking, and drop strategies.
Benchmarking routing protocols might not be something you Continue reading
Worth Reading: Datera emerges from stealth
The post Worth Reading: Datera emerges from stealth appeared first on 'net work.
Something Old, Something New…
Some time back a reader sent this question in—
Is there some list of design fundamentals which were “true” or at least “good rules of thumb” in the past (2 months to 20 years and beyond) which are still proclaimed as true and good, which we need to throw out, or at least question closely today?
It’s an interesting question—the problem is, of course, that there are two sorts of answers to this type of question. The first is rather specific, and the second is rather general. Let’s try the more specific answer first, and see if we can get to the more general one.
There are several rules of thumb that are no longer useful today.
OSPF and IS-IS flooding domains should be limited to 50/100/200 routers/intermediate systems. The old “50 in an area rule” is something several of us asked to be removed from Cisco Online something like 10 years ago, as it didn’t even apply then. I’ve heard 200 more recently, but the reality is—there is no right number here. I just did a two post series on dividing up flooding domains that might be useful here (part 1 and part 2).
There are provider Continue reading
Worth Reading: 30 years later, where is the smart home?
The post Worth Reading: 30 years later, where is the smart home? appeared first on 'net work.
Worth Reading: Reddit’s Warrant Canary
The post Worth Reading: Reddit’s Warrant Canary appeared first on 'net work.
Securing BGP: A Case Study (7)
In the last post on this series on securing BGP, I considered a couple of extra questions around business problems that relate to BGP. This time, I want to consider the problem of convergence speed in light of any sort of BGP security system. The next post (to provide something of a road map) should pull all the requirements side together into a single post, so we can begin working through some of the solutions available. Ultimately, as this is a case study, we’re after a set of tradeoffs for each solution, rather than a final decision about which solution to use.
The question we need to consider here is: should the information used to provide validation for BGP be somewhat centralized, or fully distributed? The CAP theorem tells us that there are a range of choices here, with the two extreme cases being—
- A single copy of the database we’re using to provide validation information which is always consistent
- Multiple disconnected copies of the database we’re using to provide validation which is only intermittently consistent
Between these two extremes there are a range of choices (reducing all possibilities to these two extremes is, in fact, a misuse of the Continue reading
Worth Reading: Cryptography isn’t easy
The post Worth Reading: Cryptography isn’t easy appeared first on 'net work.
Review; Algorithms in a Nutshell
Algorithms in a Nutshell
George T. Heineman, Gary Pollice, Stanley Selkow
O’Reilly Media
In the midst of the SDN craze (or haze, depending on your point of view), we often forget that all networks are, in the final analysis, driven by software. Every control plane ever developed or deployed is a software application running on top of a physical device. And every control plane, every queuing mechanism, every forwarding mechanism, and everything we work on in the networking field is based on some sort of algorithm. But what is an algorithm, really? What sorts of algorithms are there, and what are they used for? These are the questions this book specifically takes aim at answering.
The authors begin with a chapter discussing the concepts of algorithms; this chapter contains a really helpful section on the difference between the classes of algorithms available, such as greedy and Chapter 2 focuses on the math of algorithm performance, providing information on the difference between O(1), O(n), O(n log n), and many other expressions describing the feed at which algorithms operate. This is one of the most helpful and clearly explained sections in the book. The third chapter explains the building blocks of algorithms, specifically focusing on the conventions used in the book, and some challenges around measuring the performance and accuracy of any given algorithm.
Chapter 4 considers sorting algorithms, and chapter 5 search. These three kinds of algorithms probably cover 80-90% of all algorithm usage in real code. These three classes of algorithms actually provide the building blocks for many other kinds of algorithms. For instance, Shortest Path First (SPF) requires a sorted heap or list of nodes, edges, and reachable destinations in the network—but we have to sort a list to have a sorted list to use in SPF.
Chapter 6 jumps into material directly applicable to network engineering; here is where Dijkstra’s SPF algorithm is covered. This chapter will be extremely useful to network engineers to read and understand, even though the terminology is often different. Chapters 7, 9, and 11, on path finding in AI, computational geometry, and emerging algorithm categories, are interesting, but not all that useful for the average (or above average) network engineer.
Chapter 8 discusses network flow diagrams, which are a superset of many of the traffic engineering, service chaining, and queuing theory problems engineers face in real networks. Chapter 10 should be familiar to engineers who’ve looked at the m-way trees and treis used in packet switching.
Overall, this is really useful book for network engineers who want to dig deeper into the software roots of how network protocols and switching work. There are a few chapters that don’t directly apply to the common sets of problems network engineering involves, but readers won’t miss a lot skipping those sections if the overall length of the book seems like it’s too much.
The reading difficulty is moderate, and the time to read is pretty long (partially because of the many code examples and the depth of the concepts covered).
The post Review; Algorithms in a Nutshell appeared first on 'net work.
IETF 96: Berlin
I will be attending the 96th IETF in Berlin, Germany, July 17-22, 2016. There are always tons of interesting things going on at the IETF. If you’re going to be there, please let me know so we can find some time to chat.
The post IETF 96: Berlin appeared first on 'net work.