Last week I presented the results of the TechValidate survey of network operators we commissioned on the extent and impact of routing issues in the WAN. We also asked three questions about their current adoption of and expectations for WAN SDN (also referred to as Carrier SDN or Telecom SDN). The respondents were network professionals and executives working for mostly regional/tier-2 network operators in 27 countries on five continents (none were Packet Design customers to avoid skewing the results). Here’s what they said.
Nearly half are either using SDN controllers in production or testing one or more. There is an interesting discrepancy between roles: 62 percent of managers and executives said their organizations are either using SDN in production or testing it, while only 38 percent of network practitioners (network engineers, architects, planners, operations technicians, etc.) said this. This suggests that “SDN” means different things at different organizational levels. It could also mean that executives are aware of SDN in use outside of the practitioners’ routing domains.
Almost one-third of the survey respondents said they will start testing in the next six to 24 months. Only 26 percent of service providers said they have no plans for WAN SDN. In contrast, we had TechValidate conduct a similar survey last year (this time of our customers) and only 12 percent had no plans to implement SDN. Most of our customers are tier-1 network operators, so it makes sense that they would invest in SDN projects earlier than smaller operators. Of course, we believe our customers are better prepared to manage and monitor SDN. In fact, 90 percent of customers surveyed last year said they would use Packet Design products to implement and/or manage SDN.
When broken out by role, 46 percent of execs/managers listed this as a top challenge compared to 67 percent of network practitioners. Practitioners understandably see more challenge in managing disparate technologies. Clearly, most network operators will evolve to SDN rather than forklift upgrade. Therefore, SDN-enabled infrastructure will coexist with “legacy” infrastructure, and both must be managed.Some people assume (although as market understanding increases this is becoming less true) that the SDN controllers will know everything about the network. In fact, controllers only know about the devices that they own/provision. So there is a need for holistic monitoring and analytics. Otherwise, it’s conceivable that automated SDN provisioning could take place in one part of the network without understanding the impact on other, non SDN-enabled parts. In addition, if separate tools are needed to monitor/manage legacy and SDN-enabled network infrastructure, that creates a headache for operations teams who must manually correlate data from each to get the whole picture.
From this it appears that some people are worried that the SDN controller(s) they select won’t be network equipment vendor neutral (e.g., a controller such as Juniper’s NorthStar might not support Cisco routers). In fact, because most controllers adhere to industry standards, like PCEP, this shouldn’t be a major concern. Also, Open Source controllers seem to be the preferred choice for many/most network operators, so this really shouldn’t be a big issue. The answers probably reflect lack of real SDN controller experience at this time.
As we have written many times, traditional tools that “pull” network metrics are inadequate in very dynamic SDNs. And we are certainly not alone in our thinking. Google has long been an advocate of “streaming telemetry” where management data is “pushed” by the network to management systems. Our previous surveys have also shown that a number of people figure they will need to at least augment their existing tools with new ones.
Network pros must constantly deal with routing-related issues, as our survey shows. In fact, in last year’s survey every one of our customers said that real-time and historical analysis of routing paths will be equally important (40%) or more important (60%) with SDN. Our SDN Traffic Engineering (SDN-TE) application leverages the Packet Design SDN Analytics and Automation Platform (via RESTful APIs) to optimize and provision RSVP-TE tunnels based on available bandwidth and user-specified policies. Using the Explorer Suite’s always-current network models and traffic matrices, the application verifies if requested TE tunnels’ bandwidth requirements can be accommodated. If so, it calculates the best paths and provisions the tunnels via the OpenDaylight controller.
The work here is really in the definition of the service to be created. Rather than using turn-key apps, service providers will do much of this work so they can customize the services to create differentiation. Our SDN Platform provides many of the building blocks (micro services) needed to create these apps, and it can also determine the new service’s impact on the network and configure the needed resources automatically.
Clearly, we have a long way to go before SDN becomes mainstream. As Current Analysis vice president Peter Jarich said in a recent interview with RCR Wireless News, it will take more commercial deployments to work through these issues and convince service providers of the ROI.
What are your WAN SDN plans and concerns? Let us know!