A typical network service spans many layers up and across the network stack including data center access, data center core, edge, campus, branch/CPE, and wide area networking (WAN). But software-defined networking (SDN) controllers generally do not have visibility across the entire stack. While software-defined wide area networking (SD-WAN) solutions automate the CPE functionality, they don’t cover the rest of the network that extends into a large campus/LAN involving routing, security, switching, wireless etc. To further complicate the situation, the technology stack consists of multi-vendor networks. So in this paradigm, network administrators have to manually configure multiple network elements including SDN controllers, OpenStack, virtualized network functions (VNFs), PNFs, servers, and storage.

Before you deploy SDN, consider asking these questions:

1. Does an SDN controller take care of all subdomains of network provisioning?

Answer: No. SDN controller addresses the automation of the access layer. A network service typically spans well beyond the access layer where provisioning needs to extend to data center edge, core, and WAN. An orchestration platform provides a more overarching service view while the SDN controller drives the automation of a subdomain.

2. Does an SDN controller manage hybrid networks consisting of legacy physical, underlay, NFV, and SDN?

Answer: No. The SDN controller will not provision anything on the legacy network. An orchestrator will be helpful to create VLANs and/or VXLAN in legacy physical network (PNFs) as well as any other configurations required for the service. An orchestrator acts as a bridge between legacy and SDN infrastructure.

3. Does an SDN controller really avoid all manual configurations?

Answer: In a data center environment, the SDN controller is responsible for deploying the tenant services such as L2/L3 creation, spawning VNFs, service chaining, quality-of-service (QoS), security, and overlay for East-West and North-South traffic. However, an SDN controller has to be manually configured to perform the policy enforcement.

Typically, SDN controller has a three tier architecture:

  • Service directory (policy engine), where service policy is configured
  • Actual controller
  • Underlay infrastructure, such as hypervisors where service is deployed.

Let us consider a simple use-case to create a virtual DC container with a three tier application policy (Web, App, DB) with VNFs (FW and LB). The network admin has to manually create service policies in the SDN controller for multiple virtual networks (one each for Web, App and DB), and the VNFs (LBs, Perimeter FW and Application FW).

Further, the administrator has to manually configure the traffic redirection policy, security, and QoS policy in the SDN controller service directory (policy engine). When the service is instantiated, the policy engine will communicate the policy to the SDN controller, which will enforce the policy in the data center infrastructure using Open Flow or other protocols.

An orchestrator integrates with the SDN controller API and helps administrators model multiple workflows and avoid all the manual configurations.

4. Does an SDN controller take care of service verification and validation?

Answer: No. Service verification and validation goes beyond configuring multiple end points.

Service verification –An orchestrator can verify the service using multiple options including ping test, validating traffic flows, etc.

Service validation –An orchestrator has the accurate view of capacity and mapping between service and resources that are spread across multiple network domains. Based on this information, the orchestrator validates that the service is deployable at any given time and estimates the number of services possible.

5. Does an SDN controller offer service assurance that involves working with external service assurance platforms?

Answer: No. The service assurance involves modeling key performance indicators (KPI) using metrics across various network elements in multiple networking domains. Some of these collectors could be external systems that are specialized to perform a particular role.

An orchestrator provides a way to model KPIs that can be described together as part of a state machine to monitor key data points on multiple end points and then take corrective action. Actions themselves can be defined as services that solve a particular SLA/KPI violation.

6. Does an SDN controller support multi-vendor VNFs and provision the VNFs such as firewalls, load balancers, and WAN Optimizers?

Answer: No, some of the leading SDN controllers have very limited VNF vendor support with limited features.

An orchestrator would be effective to provision the VNFs for Day 0 (during service deployment) and any Day 1-N configurations for any MAC operations (such as firewall policy, ACL, and VIP creation in Load Balancer).

7. Does an SDN controller have complete integration with OpenStack where the cloud service is deployed?

Answer: SDN controllers should have complete plug-in support for OpenStack. When policy is provisioned in the SDN controller, it has to be provisioned in OpenStack automatically. But that’s not the case now. Currently, the administrator has to provision few policies in OpenStack manually. For example, creation of networks has to be performed in the SDN service directory as well as in OpenStack. An orchestrator would be effective in such cases of split configurations where a single service needs to be deployed in both the SDN controller and OpenStack.