Software-Defined Networking (SDN) and Network Functions Virtualization (NFV) have been picking up the pace as of late. A high percentage of communication service providers and large data centers have either added these technologies on their roadmaps, or are already doing small-scale Proof-of-Concepts (PoC) in their testbed environments.

The one thing that has insofar received surprisingly little attention is the scalability of these technologies. On paper, the best of the SDN pack are able to scale slightly above 100,000 hosts per SDN Controller. When you compare this number against the backdrop of Internet of Things (IoT) and the proliferation of connected devices, a cool 100k suddenly doesn’t sound like such high a number after all.

To address the issues around scalability, many experts in the space are steering the market towards federation. Within this paradigm, rather than betting the farm on a single SDN Controller, the deployment consists of a number of SDN subsystems run side by side. On paper at least, this model facilitates virtually unlimited scalability. It also makes sense from the risk management perspective, as it isolates possible failures to individual subsystems.

Having said that, there are a number of practical problems with SDN federation that are yet to surface on most organizations’ radars. Here is a laundry list of the three issues likely to emerge next:

1. Managing network blocks. Large organizations have deep silos, and SDN federation allows each silo to select its own favorite SDN controller type. When you couple this multivendor scenario with the legacy networks, one can quickly dream the need for a single authoritative system used to manage the network allocations centrally.

2. Provisioning. Going forward, most applications and services will be built and released by orchestrators that need the appropriate release parameters such as IP addresses and names before releasing an application or a service to production. To enable seamless service automation workflows, these orchestrators need an authoritative provisioning source for all-things-IP, regardless of which legacy network or SDN subsystem a given workload is going to.

3. Visibility and reporting. Once an organization lands with a mix of SDN subsystems, NFV orchestrators, cloud orchestrators and legacy networks, they will soon discover the need for a centralized management system providing real-time visibility and reporting on the network use throughout the organization.

The trump card to these problems is a new, vendor-agnostic layer in the elastic cloud stack that pulls together all network-related pieces of information; assigns networks to different SDN subsystems; and provisions the appropriate release parameters to the various orchestrators.

Addressing these challenges could also be the cure for at least some silo issues. After all, if interoperability between the different orchestrators and/or SDN subsystems is a simple matter of plug-and-play, there is less need to play politics.

For technology reasons, anyway.