The post Worth Reading: Cryptography isn’t easy appeared first on 'net work.
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.
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.
The post Buenos Aires Under Construction appeared first on 'net work.
I’ll be speaking at Interop 2016 on the topic Engineer versus Complexity. The slides are final yet, so I’m not entirely certain what all this is going to include—which means this will be an exciting talk. Feel free to ping me if you’re going to be there.
The post Interop Las Vegas 2016 appeared first on 'net work.
The post Worth Reading: Warrantless Searches appeared first on 'net work.
I’ll be speaking at the Chicago Network Operator’s Group (CHI-NOG) 2016 on the 12th of May 2016 on BGP security. As we come closer to what we’re actually going to deploy to make BGP more secure, I can come closer to describing it in the talks I give. Feel free too ping me if you’re going to be there.
The post CHI-NOG 2016 appeared first on 'net work.
The post Worth Reading: Intel and the Network Arms Race appeared first on 'net work.
This post is going to be a little off the beaten path, but it might yet be useful for folks interested in the process of standardization through the IETF.
Last week, at the IETF in Buenos Aires, a proposal was put forward to move the IPv4 specifications to historic status. Geoff Huston, in his ISP column, points out the problem with this sort of thing—
The idea to push IPv4 to historic is, apparently, an attempt to move the market, in a sense. If it’s historic, then the market won’t use it, or will at least move away from it.
Right.
Another, similar, line of thinking came up at the mic during a discussion around whether Continue reading
While the IS-IS book is still useful, it is getting on a little in age, and some people find learning through video to be more helpful. I’ve recorded seven hours of video on IS-IS in the form of a LiveLesson with Cisco Press. They should be available on the 18th of April (just a few days from now), and apparently they’re already available as a sneak peek.
Thanks to Brett (who runs, and has run, all my projects at Cisco Press and Addison-Wesley), Pete (who patiently recorded my many fumbles), and Chris Cleveland, who has been my steadfast editor for all things Cisco Press and Addison-Wesley for some fifteen years now), for making this happen. This is the first, I think, of a number of new video projects I have on tap, so watch this space.
And no, I’m not going to stop writing books (just a gentle reminder).
The post IS-IS LiveLesson Publishing Soon appeared first on 'net work.
So far, in our investigation of the design mindset, we’ve—
We also considered the problem of interaction surfaces in some detail along the way. This week I want to wrap this little series up by considering the final step in design, act. Yes, you finally get to actually buy some stuff, rack it up, cable it, and then get to the fine joys of configuring it all up to see if it works. But before you do… A couple of points to consider.
It’s important, when acting, to do more than just, well, act. It’s right at this point that it’s important to be metacongnitive—to think about what we’re thinking about. Or, perhaps, to consider the process of what we’re doing as much as actually doing it. To give you two specific instances…
First, when you’re out there Continue reading
I will be speaking at NANOG on the road tomorrow—the topic is “An Introduction to Network Complexity.” If you’re in the Raleigh area, this is well worth taking the time off to come to, as the speaker lineup is fantastic.
The post Introduction to Network Complexity at NANOG on the Road appeared first on 'net work.
I’m presenting at two sessions this year at Cisco Live: BRKRST-3014, Policy, Complexity, and Modern Control Planes on Thursday afternoon, and TECCCDE-3005, The Cisco Certified Design Expert, on Sunday afternoon. If you’re attending, feel free to look me up—when I’m not speaking, I’m generally hanging out at Cisco Press, at the Certification Lounge, or just walking around the show floor.
The post Cisco Live 2016 Las Vegas appeared first on 'net work.
Before talking the final point in the network design mindset, ,act, I wanted to answer an excellent question from the comments from the last post in this series: what is surface?
The concept of interaction surfaces is difficult to grasp primarily because it covers such a wide array of ideas. Let me try to clarify by giving a specific example. Assume you have a single function that—
This single function can be considered a subsystem in some larger system. Now assume you break this single function into two functions, one of which does the addition, and the other of which does the multiplication. You’ve created two simpler functions (each one only does one thing), but you’ve created an interaction surface between the two functions—you’ve created two interacting subsystems within the system where there only used to be one. This is a really simple example, I know, but consider a few more that might help.