Skip to main content


Showing posts from February, 2012

SDN vs SdN

May be they should have define software Driven network  as application driven network so as not to confuse it with software defined network (openflow and the rest...).  The former is all about network applications using the open APIs on the network to provision, reserve and optimize the path that the application data takes. The open API could be network as a service. The ultimate goal of this initiative is programmable network.

The latter is a rearchitecture of the switch with focus on virtualization of the hardware forwarding plane. A multi device network operating system and bunch of controllers that use use the NOS to configure the devices. The ultimate goal of this initiative is operational excellence.

Innovation is its own Business Case

"What is the business case for this innovation?" Heard that?

Innovation or lack of it is the reason for 2.x% GDP growth in the developed world and we still hear this call for justification. Fed funds rate is 0-0.25% and yet we have to justify NPV of a project. Everybody from company president to the country president is asking (no begging) for innovation, but we need to prove ROI for a project. The chinese did not need a business case to build so called "Ghost cities". They consume 40% of copper production in the world without business case. They are the equivalent of Apple in the world today with surplus cash to buy out several greek deficits. They even placed their machine on the Top 500.

Innovation is its own business case. You cannot calculate the ROI of innovation because you cannot measure the return. So think of the "I" in ROI as your ability to finance (means) and risk tolerance.


When J Hamilton said network gets in the way, I believe he was asking for a economical solution kind of like the way x86 based servers replace risc processors. The x86 world did not bring complexity, unknown paradigm with unknown cost and difficult to estimate performance. Software Defined Networking a.k.a SDN is apparently doing just that. What started as simple protocol to read/write/replace entries into a switch's forwarding table now has attracted a code bloat and frameworks which promise a network which does substantially what is already done with VMWare's vswitch.

The original call to simplify the network listed a few use cases as drivers which can be categorized as 1) Workload placement (includes all shapes/forms of vm mobility, code mobility etc.) and 2) big data processing. The first challenge attracted solution such as overlays and tunnels which can extend a vm's notion of its layer-2 domain within and across datacenters. What we need now is a standardized way of…