Software-defined networking is in an enviable position: Everyone is excited about the concept and wants to believe in it. Among networking professionals, expectations are high. But don’t make the mistake of looking at SDN as just a new tool to solve yesterday’s problems.
are falling into this trap as they seek to market and monetize SDN before the new-car smell wears off. OpenFlow, because it’s a standard, is an exception, but we see SDN-like capabilities baked into a number of proprietary and only partially standards-based systems. Sure, most vendors promise to support OpenFlow in addition to proprietary code, but the temptation is strong to “embrace and extend.”
As chief architect of the InteropNet and CEO of a technical design company, I understand that it’s normal for IT organizations to come at software-defined networking from the perspective of an engineer: What’s broken that can be fixed by the ability to program a network to dynamically change its operating mode or parameters via a programmatic method?
Use SDN to make the current network better, sure. But it’s more important to think differently about how SDN will help us design and build the network of the future.