Networking Field Day 7 – In Review

It’s been a week since I’d landed in San Jose and waited anxiously to meet the other delegates for Networking Field Day 7. The entire week was something like I’d never experienced and it definitely changed my perspective on not only the community, but my career as a whole. I can’t say this enough, but what Mr. Foskett has started and kept running for years now is something invaluable to the industry and I hope it keeps going to years to come.

When I’d landed in San Jose, I sent along a text to Stephen. He greeted me and promptly notified me that the other delegates had taken to a local bar inside of a bowling alley as the bar in the hotel hadn’t opened yet. I sat at the shuttle pickup for about 20 minutes waiting to be shuttled to the hotel, enjoying every minute of the 65 degrees and sun, and the fact that I’d just left 7 inches of another coating of snow at my house here in Connecticut. There is something inherently evil about the weather in Silicon Valley. I can see how it could become an addiction to live there. However, as the shuttle driver had pointed out to me, the hills are usually a lush green and with the current water shortage they were anything but that, more of an arid brown.

I’d finally arrived at the hotel and was promptly given the key to my room and I’d noticed the one and only Bob McCouch wasn’t far behind me, judging by his tweets. I send along a text and he was bout 10 minutes out. I hung my shirts and waited anxiously to see everyone. I’d meet a bunch from the previous Cisco Live but I hadn’t meet the other delegates whom I’ve now realized are a great set of people with whom I hope to keep a very active relationship with. Once I’d meet up with Bob and few other delegates we settled in and started talking tech right from the get go, while we waited for dinner. Awesome.

After our arrival dinner and some drinks we all settled in a bit early for the night to rest up for our first day of Networking Field Day!

The first day brought us three vendors exhibiting their wares :

The second day we was the first day which we were carted around the Valley to meet more vendors at their various facilities, I have to say this was my first trip to Silicon Valley and I was a bit in awe and caught myself, more than once, driving down the street and being amazed at seeing all of the big name companies with whom I’ve used their products.

The line up for the second day included :

After a very long day of presentations we were able to stop for some sushi for dinner where I introduced a good friend of mine Matt Oswalt to sake, both cold and warm. He didn’t seem to be thrilled at the flavor.

The third and last day of the event was a bit shorter than the others but we still have a great line up of vendors which included :

This post isn’t going to deep dive into any of the vendors or technologies, as it is more of a recap post than anything else and I’m still digesting the technologies and solutions and potential use cases for those technologies. But I wanted to give everyone a run down of the vendors I’ll be writing about over the coming weeks and let everyone know that there was one resounding message from this Networking Field Day and that was the networks and systems of today will definitely NOT be the networks and systems of tomorrow. The amount of open source involvement from the vendors and their commitment to the OpenDaylight Project has left quite the mark on me and where I see myself going within my career moving forward. And there will be PLENTY more of that coming down the pipe as I start to blaze my trail in that direction.

So, there you have it, the list of vendors who presented, the major overarching message that I’d received and what to expect from me in the coming weeks. Take the time to check out the links listed above for all of the Networking Field Day content and stay tuned for some of my posts regarding them!

The ‘Software Defined’ Policy Dilemma

Speaking with other individuals in the industry about what SDN is, specifically how we qualify and quantify it, has lead to me to quite a few conversations with people about how many people think of SDN as an NBAR / QoS on steroids solution instead of looking at it as higher level policy framework that can be applied across infrastructure. I, personally, can subscribe to the thought process there.

We got side tracked in the last Class C Block podcast I was invited to participate in, about what SDN is and how we can use it and I just recently listening to the latest Healthy Paranoia podcast where the discussion of how SDN could impact the security realm was had. And the key word that I kept hearing was policy. Policy that needs to be applied here, and policy that needs to be configured there.

I like the idea of defining a framework for our infrastructure in that we can mold the technology policies that we have within our organizations to the business. This is the fundamental reasons why IT exists. We’re here to transcribe business policy into technology solutions. That said sometimes there are very large gaps in translation from business policy into technology, and this brings me to my point.

If SDN, within the next 5 to 10 years, is going to yield us anything we need to make sure that we have not only engineers that can design, build, and deploy these next generation solutions, but they also need to understand the business side of the house a bit deeper. Right now we’re afforded the ability to understand the business logic on a lesser level as we’re living within a world of constraints defined, in majority, by the hardware and software we have deployed in house. To the point where businesses are willing to change their business policy to accommodate the limitations of their technology. The obvious constraint from the business side of the house that can be read into these new policies would be the financial impact. Being more network engineer than anything, the best I can align this with is having multiple upstream peers, all with different monetary costs and having the ability to intelligently shift flows in accordance with fiscal requirement. Right now its a lot of kludge edge policy that needs to be modified and addressed relatively regularly depending on demands within the network.

The more I think about it and the harder I examine the problems and pain points that organizations face and why so many of us are clamoring at the thought of having that panacea of flexibility that all of this hype promises to offer, we need ensure we really understand exactly what it is we’re trying to accomplish. From a business perspective, as well as technological. Otherwise, years from now we’ll look back at our next generation ‘software defined’ infrastructures and be facing the same problems we’ve been faced with over the previous decade. Except, this time we’ll be faced with unraveling a larger ball of yarn with all of the ‘code’, read pseudocode…ish…whatever you want to call it, that gets developed along the way.

Maybe I’m the only one that has seen this problem within organization but I still feel it necessary to at least bring this point to light.