Courtesy - Jason Edelman
I mentioned in my previous post Nick McKeown, uber smart Entrepreneur and Professor at Stanford, gave what I thought was the finest presentation of the week at the Open Networking Summit hosted in Santa Clara this week. As I wait to board my plane back to the East coast, here is a more detailed recap of the presentation and what I took away from it…
Nick McKeown arguably gave the most well thought out and intellectually engaging presentation of the week. In my opinion, it was the best I saw. He painted a picture that should have been done in the key note on Tuesday. McKeown started by looking at IBM and the closed nature of the mainframe and PC business back 20-30 years ago. It was a closed industry and innovation was slow until the x86 instruction set was developed. This allowed others to build operating systems and even more to build applications rapidly increasing the pace of innovation in this market. Quickly, we saw pictures of BFRs (Big *** Routers) on the screen that may have been a Cisco CRS-1. I couldn’t tell from where I was sitting, but the goal was to compare this big router to IBM and their legacy closed model. One vendor provided the ecosystem of hardware, OS, and applications riding on top.
Is this why innovation has been lacking in networking? Maybe. McKeown talked about the architecture that could change this.
Enter OpenFlow. Enter Software Defined Networking (SDN). This is where the x86 instruction set always comes up as an analogy to OpenFlow. From here, many can probably speculate on what was said over the next few minutes. It was nothing more than has been talked or blogged about for the past 18 months. Yes, it is understood OpenFlow can separate the control and data planes, a network OS can be created (more than one of them), and applications can be written to interface on top of the network OS as easy and quickly as they are built for iPhones and Android devices. Okay, maybe not that easy!
The next few slides went on to depict on how strict HW/ASIC and software development is within their respective industries. It showed the rigorous processes entailed and how important it is to get it right before going to production. Do you really want to deploy a defective ASIC? The costs associated to that could be catastrophic. Numbers ($$) were then shown on how large the industries are for development and testing. They were upwards to $10B. Then we saw sample numbers on how many books, papers, and classes there are for these at Universities. I don’t recall the numbers for each, but they were large. Dare you ask about the industry of testing in the world networking? No money, no papers, no books, and no classes*. We saw a slide that stated a few things network guys do when issues arise – ping, traceroute, tcpdump, etc. some primitive commands and functionality. But, think about it, how do you really troubleshoot? There are methodologies used by experiencing network engineers, but no automated tools, right? Is this sufficient for us? Have we really become “master’s of complexity?” Quite possibly, yes.
*Feel free to check the slides when they are posted for the exact numbers and examples presented by Nick McKeown. There is a chance I got something wrong as I’m writing from memory.
**Master’s of Complexity – this is in quotes because it’s a phrase being quoted now quite often from Schott Shenker from his presentation at the last ONS.
Over the next section of his presentation, McKeown went on to show some pretty in depth slides on value that can be provided to the network by having a centralized control plane. Equating back to hardware and software regression testing and development, his focus was on automated debugging tools and testing, proactive and reactive, for a Software Defined Network. Before I go on, I’m going to quickly summarize a feature on Cisco ASA appliances to help in making the case for what Nick McKeown went on to say.
If an ASA is deployed and there are packets being dropped, one popular tool is to use Packet-Tracer for debugging. Packet Tracer analyzes a synthetic packet that an admin generates the details of (source ip/port, des ip/port) from when it would enter the ASA until it would exit, and since the device knows the order of operations of applying certain policies, it goes through certain checks such as applying NAT policy, applying ACL, etc. So, as one can imagine, this uncovers out of order ACLs or you can uncover mis-configured NAT policies, etc. This has become a pretty important tool to have in Cisco ASA environments.
Have you ever thought about having similar functionality in a switch or router? Sounds interesting given the amount of even more complex configs you’ll have on L2/L3 devices ranging from long and complex routing policies, filters, NAT, PBR, QOS, etc. Do we have that functionality today? Not that I know of. Regardless, McKeown is thinking bigger, much bigger. Imagine you have this Packet-Tracer functionality NETWORK WIDE – that’s right, network wide. Imagine wanting to test how a change may affect the network campus wide or enterprise or debugging an issue where a packet doesn’t reach its destination. Within a SDN, this becomes possible. This was actually eye opening for me in terms of looking at the product development and testing of software based solutions. His team at Stanford is already well underway on developing these types of tools for the Stanford campus network. Imagine specifying a flow in a simple UI, clicking submit, and the output quickly showing where the dropped packet is in a muilt-node network. The output may show the error is with the ACL on Router 5 port 3. Well, you really don’t have to imagine this because you can go to Stanford and see these types of developments.
This was just a glimpse of what McKeown spoke about and is one of the industries that he thinks will significantly increase as SDN adoption begins to gain wheels. Unfortunately, this isn’t good news for me and who I will call “traditional” network folks. When asked by a participant if this type of automation for testing, development, and debugging will “wack” us, you heard a light chuckle from the audience, but believe me, everyone wanted to know Nick McKeown’s thoughts. He answered honestly saying he sees an overall increase in jobs in the network industry, BUT, there will be less admins/engineers needed to maintain and operate networks.
The large surplus of jobs will be in software and application development for network systems. This is of no surprise for those who have been following these trends. It will be interesting though to see how it plays over the coming years (don’t worry, it’s not weeks or months!). The network engineer of yesterday could very well become the PBX phone guy of the late 90s early 2000s. These network guys will adapt new skills such as programming and system administration or find the company that won’t adopt new technologies to try and stay in their comfort zone.
What will I do? Who the heck knows? Maybe I’ll take on writing full time. Just joshin' with ya, this is a great new opportunity for Integrators and Partners to add value for their customers as well!
On a side note, I’m not going to lie; it felt pretty good for people to recognize me by this blog while walking around at the ONS (everyone was wearing badges that had your name and the company you represented). It wasn’t many, but a few, and it was indeed still very cool. Glad to see people are actually reading this thing =).
No comments:
Post a Comment