SDN, OpenFlow, and Google

SDN for Everyone!

Let's face it, everyone is talking about SDN-- Software Defined Networking. Vendors all up and down the infrastructure stack are evangelizing SDN. As a future-focused kind of engineer I recently had a chance to watch what Goolge is doing ( has done ) with OpenFlow in their environment  ( video ). From a conceptual perspective, SDN isn't new-- we've used SDN in various incarnations since the dawn of networking. For example, leveraging SNMP to send a trap to an NMS and having that NMS server send an SNMP set to bring down a link or backup a configuration. Another example would be Remotely Triggered Black Hole routing ( RFC5635 ) whereby a controlling component signals all other nodes to discard a source or a destination IP address ( in this case the triggering component could be an IPS/IDS or an application that detects unwanted behavior). Still another would be RSVP ( RFC2205 )which is a solid first-attempt at making the network more application aware.

Leading from in Front

What was so impressive about the Google talk was not the technology but the leadership and focus on Engineering. In the end, the business needs to run applications that people use to bring in money-- its not particularly interested in how the network provides such a service. Introducing OpenFlow, as Urs explained, was not a small-risk proposition. Certainly any business would find it better to stick with a system that works now than to go with a system that may work later ( or otherwise has characteristics that may be useful in the future). There's where the technical leadership comes in. All too often the best technical solution is cast aside for the status quo or the "tried and true." Google's OpenFlow rollout is a prime example of the technical organization understanding the risks, deciding the path, executing, and, hopefully reaping the rewards.

Cannot Improve What you Can't Measure

Before Google rolled out a single change, they took the time and invested in making sure they could properly test the change. What that meant for Google was building a simulation environment--it paid big dividends in that they could prototype their controller in an environment that closely matched the operational parameters and characteristics of their network. Without this, the development-deployment feedback loop is broken as there's no way to precisely measure the impact of your change. In this case, the change is in shifting how path selection is done. Instead of a report driven, trending, analysis loop--path selection is near real-time, based on the real-time constraints of the network and needs of the application. Google envisioned the tool needed to test the product, not just the tool itself.

Hello World

Hello World!

Welcome to DeepDive a blog focused on diving deep into all manner of topics related to Network and System Engineering. I have an background in Computer Science and work professionally as a Network Engineer. If I'm not deploying some new equipment, researching various features, or haunting Cisco's learning network forums, you can find me researching various aspects of Network Engineering.

Why blah, Joe? I do it for the soapbox

I think its useful to share and develop ideas in a collaborative way. I find that I learn things much more thoroughly when I'm forced to explain it to someone else or answer someone's question. In this blog, nothing is remedial and I will try to make no assumptions and keep each post as complete as I can. I'm looking forward to feedback--correct me if I'm wrong, tell me my idea is flawed..I learn, you learn, we all learn.

I'm still relatively new to the field and have a lot to learn about the discipline of Network Engineering. For me, Network Engineering is not just about knowing how to design, implement, and troubleshoot network related hardware/software. Its not just about plugging in commands are sticking to tried and true designs/methodologies. To me, Network Engineering is a philosophy-- a lifestyle. Its a way of thinking and doing. Too many Network Engineers are only superficially interested in what they do. Many do not care what happens under the hood or how things actually work. Many focus on certification, achieving only a superficial knowledge of the curriculum. Still many, due to personal/professional obligations, do not have the time to invest in going deep and looking critically at applications, protocols, architectures, and designs. I hope to address those short comings in myself and others with this blog.

Enough of the soapbox. What's the blag about anyways!?

So you got a blog, who cares? What's this about, Joe?

Simply put: Messing with stuff. It is about verification and validation of the things I'm told by vendors, things I tell myself about my work, and things others tell me about Networking. I will post/review code and packet dumps, datasheets, interesting articles and just about anything else under the sun related to network applications, protocols, design, and architecture. If it talks on a network, I will try to cover it in detail.

Okay, this is too long, I'm leaving now...

While this blog is aimed at technical folks, I don't assume every knows everything all the time--I won't assume I'll remember those things going forward. As a result, I'll try to make my post as complete, verbose, and engaging as possible. My post will be long, drawn-out, and verbose. If your looking for a quick answer--flee from this place.

Hoping you enjoy!