Notebook 02.04.2013: SDN, VXLAN vs STT, Portfolio Changes and stuff…
For me, airplane time is writing time. I am presently inbound to SFO from BOS. When I am trapped in a metal tube for six hours, this is what you get.
1. Plexxi/Boundary News
Plexxi and Boundary have been working together for a few months on network/application orchestration. I have seen the details of what the teams have been doing and it is pretty cool from a technology perspective. I am highlighting the news (more tomorrow) because it relates to another dust up from two well known bloggers.
2. VXLAN vs STT
I first read this post by Greg Ferro. A few days later, Brad Hedlund posted this response. I am only interested in the two posts to highlight how my perspective is different. I think you need to read both posts to understand my next comment. In the STT protocol, there is a section (referenced by Brad as section 2.5) in which ECMP is implemented by using a randomly hashed source port. This means we have a protocol that defines optimal as: meaning most random. This is an example of the opposite strategy when compared to Plexxi.
There is nothing wrong with this type of network implementation strategy, it is a tried and true strategy, but it is no longer at the forefront of network design techniques. These types of implementation strategies are rooted in years of dogmatic network engineering and design principles. The idea is to smear traffic as evenly as possible across all the aggregated links, because you really do not have any information about the traffic (i.e. applications) with which to act upon in order to do something better. It is the quintessential example of an old-timey network engineering used to solve the internet problem (i.e. get connectivity everywhere and make it have some level of fault tolerance.)
In a Plexxi network, we believe that we can now use SDN (i.e. controller architecture) to orchestrate the network based on the needs of the application. Tell us about the (i) application, (ii) the network requirements of that application and (iii) we will orchestrate the network to meet the needs of the application. We call that Affinity networking and it is the role of the controller to perform a fitting function of the applications to the network. Perhaps this is an illustration of the bottom up versus top down view of network orchestration. I spend a lot time talking to people with ten, twenty, even thirty years of network design experience and it is challenge for people invert their thinking and work top down, but to me that is what SDN is all about. I think the cultural reason why experienced network people find the top down approach difficult to grasp is they have been trained to do the opposite their entire lives. We have been trained all our lives to solve the connectivity problem first and worry about the network experience later, if at all. Why have we been trained to do this? Because for the last 30 years we had no way of correlating the needs of the application to the capabilities of the network. If SDN is anything, it is a correlation tool between the network and applications. At Plexxi, we think the more you can learn about applications, then better you can orchestrate the network; hence the Plexxi/Boundary partnership.
3. Portfolio Changes
I was a seller of my CTXS and LNKD positions today. I had no other reason other than I had really good gains on both positions and I wanted to reduce equity exposure after the January run. I still want to put on CL1 position, but today I bought a small long position in NatGas.
I got an email from a friend today with an interesting market thesis. I have no idea if he is correct, but I thought it was contrarian enough to reproduce. “My thesis is CAPEX saw mega drop off in Jan 2013. A huge amount of CAPEX was pulled into Q4 2012 because the bonus depreciation tax credit renewal was somewhat in doubt. As bad as the Q4 2012 GDP was overall, the CAPEX portion was up huge. With the depreciation bonus maintained and sequester upcoming, zero incentive to spend now.”
/wrk