By now just about everyone has realized that OpenFlow is just vaporware. Technically, there was never any content behind the hype. The arguments used to promote OpenFlows revolutionary properties where simply the ignorance of all previous technologies that used the exact same design ideas from SS7 to PBB-TE.
Rumor has it that even the most religious OpenFlow supporters from Mountain View to Tokyo have realized that OpenFlow is pretty much dead. If you look back at it, it was a pretty silly set of assumptions to start with: that hardware design and not software the the limiting factor in network devices; and that you can define a low-level forwarding language based on the concept of a TCAM match that is going to be efficient across general purpose CPUs; ASICs and NPUs. Both assumptions can easily be proven to be false.
But OpenFlow’s promise was “too good to be true”. So a lot of people preferred to ignore any hard questions in search of the illusory promises of a revolution in networking. By now though, everyone gets it.
As an industry, what is the expected reaction to the OpenFlow hangover ? One would expect a more down-to-earth approach. Instead we get “Segment Routing”. Another “magic wand” proposal that is being presented by a bunch of industry luminaries and as such it really must be “the next thing”.
Segment routing consists of using the an “IP loose source routing header” approach to indicate the intermediate hops that a packet should traverse. So instead of creating state in network devices that correspond to a FEC, state is carried in the packet header.
The argument here is that this is supposed to simplify the network by the need to create less state in network elements. But of course, this is before you consider that the same state still needs to be managed: FECs still need to be calculated, bandwidth allocated, fast failover needs to be handled, etc. Not to mention the fact that carrying state in the packet would make the network really hard to debug.
Networking technology is about networking: the ability to build a distributed system among pieces that are provided by different vendors. There are cases in which centralized computations may be useful, but signaling is not an operation that needs to be or benefits from being centralized.
Distributed signaling is a technology that works well. It allows central policy control when required but it also allows for distributed decisions such as local repair. Reinventing signaling with a hop-by-hop header which is being proposed by the segment routing crowd hardly seems an answer to any real problem. It does however promise to attempt reinvent all the basic functionality that has been developed on MPLS over the past 15+ years.
I can’t wait until the next fashion comes up… hopefully with something a bit more orginal and more concerned about providing new functionality rather than re-inventing the wheel.