Framing SDN as Network as a Service (NaaS)

Tom Nolle absolutely nails the real promise of SDN in his latest blog post – Should SDN be About OpenDaylight and not OpenFlow? – which is essentially to create Network as a Service (NaaS). Readers of the Knetwork Knowledge blog will know that we have been advocating for some time that SDN is a lot more than just the separation of the network’s control and data planes, and that OpenFlow is “merely” a mechanism (not the only one) for SDN controllers to pass forwarding instructions to the underlying infrastructure. Our industry often gets lost in the technology details and misses the point, which in this case is about creating malleable network infrastructures that flex efficiently with business demands. The really interesting, valuable, and (yes) hard work is to supply the controllers with the intelligence they need to make smart infrastructure changes.   

And equally important is the recognition that we have to be able to deliver NaaS with existing network gear: A forklift upgrade to support new southbound protocols is not an option. We also need to be open to the notion that NaaS does not necessarily require a centralized controller. But it does require centralized intelligence.   

Mr. Nolle covers these points eloquently in his post, and sums his conclusion up nicely: “Should we be thinking about SDN and NFV and the cloud in terms of NaaS and OpenDaylight and leaving OpenFlow as a device control option?” We at Packet Design share his perspectives. Network as a Service. Yes, now we’re talking. 

See our recent interview with OpenDaylight Executive Director Neela Jacques for more about that organization’s latest progress in accelerating adoption of SDN and NFV.