Yesterday was an interesting day in that I attended a full day ONUG academy session that was all about writing SDN applications.  Big thanks to Matt Davy and Chuck Black for leading the session.  While we weren’t hacking on code, there was a lot of discussion around APIs, network programmability, and the approach to take when building SDN applications [that leverage northbound APIs of a controller].  I’ve made it pretty public that I’ve been working with onePK building my own controller (using the term controller very loosely here) communicating directly with network devices as opposed to natively integrating with an existing controller like OpenDaylight, Floodlight, etc. and leveraging their northbound APIs.  

In a 3-tier software defined network (SDN) that has control and data plane separation leveraging a protocol such as OpenFlow, there are generally data plane devices, controllers, and applications/control programs.  Pretty straightforward.

If a packet enters the network switch (data plane device) and doesn’t have a match in the flow table, it’s punted to the controller to see how to handle that packet and the subsequent packets in that flow.  This is classic reactive forwarding.  Due to latency and possible scaling issues, it’s recommended to leverage and deploy proactive flow forwarding whenever possible.

I recently participated in two podcasts where the focus was all about Software Defined Networking and the changing network landscape. 

If you are interested in listening, check them out:

• The “Providing Cloudy Service” podcast Episode 14: Is Software Defined Networking turning you into a Developer?, hosted by Theo Harvey.

• The Cloudcast - #114 – Evolving to SDN DevOps, hosted by Brian Gracely.

On a side note, Brian and Theo rock.  If you haven't been listening to Providing Cloudy Service or The Cloudcast, I suggest you start! 

-Jason

Training and use cases are still emerging in the world of Software Defined Networking (SDN).  Luckily, there is an event, local (for me) in New York City, that has two full days dedicated to SDN (some call it open networking nowadays since it’s never been more cool to be open) on October 29 & 30.  The event is ONUG Fall 2013.  On day one there will be solid hands-on training on building your own SDN applications, understanding white box networking, and how to get started with OpenFlow deployments.  Day two is structured more like a traditional conference.

I was driving home tonight and saw a tweet from Ethan Banks (@ecbanks) that stated, “After all these years of IPSEC (a standard, after all), bringing up a tunnel between disparate vendors is one of the hardest tasks I do."  When I see these kinds of statements and have these thoughts myself, I think, there is clear problem, do others have the same problem, is this a problem looking for a solution, and can be there be a better way?  In this particular case, it’s definitely a problem, but can there be a better way?  Can we view this as an example where the network and security industry has been okay with mediocrity?  Maybe.  

A few weeks ago, I wrote about where I was in the world of programming.  As I said then, I am still focused on building a onePK application.  This onePK application now dubbed Network Control Manager is a central interface to the network.  It can be used to gather real time data as well as make changes to the network in a more centralized, automated, and real-time fashion.  Following the SDN model, this application can be seen as a SDN controller if you wish to call it that.  The southbound API used is Cisco’s onePK and the northbound API is self-defined as “je-nb-API” :).  The application/controller exposes northbound RESTful interfaces to be consumed by 3rd party applications and control programs, the first of which is a CLI application that interacts with the network via Network Control Manager.