Loading learning content...
Selecting an SDN controller is one of the most consequential architectural decisions in network transformation. The controller you choose shapes your network's capabilities, operational model, and evolution trajectory for years. A well-matched controller accelerates SDN benefits; a mismatched choice creates friction, workarounds, and eventual replacement costs.
This page synthesizes everything we've learned about SDN controllers into a systematic selection methodology. We'll move beyond feature comparisons to examine how organizational context, operational capabilities, and strategic direction should influence controller choice.
By the end of this page, you'll have a repeatable framework for evaluating SDN controllers against specific deployment requirements—transforming controller selection from intuition and vendor influence into structured decision-making.
By the end of this page, you will understand how to structure controller selection as a systematic evaluation process, the key decision criteria that differentiate controllers for different use cases, common selection mistakes and how to avoid them, and evaluation techniques including proof-of-concept design and total cost analysis.
Controller selection is challenging because it involves multiple stakeholders, competing priorities, and long-term implications. Understanding these dynamics helps structure a successful selection process.
Why Selection Is Difficult
Multi-Dimensional Trade-offs: No controller optimizes everything. Scalability may trade against simplicity. Multi-vendor support may trade against deep integration. Open source may trade against commercial support.
Organizational Politics: Different stakeholders have different priorities. Network operations wants simplicity. Security wants policy enforcement. Development wants programmability. Leadership wants cost containment.
Incomplete Information: Vendor claims exceed real-world performance. Feature comparisons don't capture quality. Lab tests don't replicate production complexity.
Long-Term Lock-In: Switching controllers is painful and expensive. Today's choice constrains tomorrow's options. Strategic implications extend beyond technical fit.
Rapid Evolution: The SDN market continues evolving. Today's leader may become tomorrow's legacy. Investment in a declining ecosystem creates risk.
| Mistake | Consequence | Avoidance Strategy |
|---|---|---|
| Feature-list shopping | Selecting for unused capabilities | Prioritize actual requirements over theoretical needs |
| Ignoring operations | Controller too complex for team | Evaluate operational requirements honestly |
| Vendor-driven selection | Mismatch with actual environment | Lead with requirements, not vendor relationships |
| Under-testing | Production surprises | Comprehensive POC before commitment |
| Cost tunnel vision | Total cost surprises | Calculate complete TCO including integration and operations |
| Ignoring ecosystem | Integration difficulties | Evaluate controller in context of full stack |
The Selection Process Overview
Structured selection follows defined phases:
Each phase has specific deliverables and decision points. Skipping phases introduces risk; thorough execution builds confidence.
Organizations sometimes persist with poor controller choices because of prior investment. This is sunk cost fallacy. If a controller isn't working, the cost of continuing (operational friction, missed opportunities, eventual replacement) often exceeds the cost of switching sooner. Build in evaluation checkpoints to catch mismatches before they compound.
Requirements definition is the most important selection phase. Well-defined requirements enable objective evaluation; vague requirements allow subjective bias to dominate.
Categories of Requirements
Functional Requirements — What the controller must do:
Scale Requirements — How large the controlled network:
MoSCoW Prioritization
Not all requirements have equal weight. Use MoSCoW to classify:
Example Requirement Categories
Must Have:
Should Have:
Could Have:
Quantifying Requirements
Wherever possible, quantify:
Bad: "Must scale to large network"
Good: "Must support 500 switches with 50,000 flows per second"
Bad: "Must be highly available"
Good: "Must provide sub-5-second failover with 99.99% annual uptime"
Quantified requirements enable objective evaluation and form acceptance criteria for proof of concept.
Different stakeholders contribute different requirements. Network ops cares about manageability. Security cares about policy enforcement. DevOps cares about automation APIs. Finance cares about TCO. Ensure all stakeholders contribute requirements—and that trade-offs between stakeholder priorities are explicitly resolved.
Beyond matching requirements, evaluation should assess criteria that determine long-term success. These criteria apply across controller options.
Technical Architecture Criteria
Scalability Architecture
High Availability Design
Extensibility Design
| Category | Key Questions | Evaluation Method |
|---|---|---|
| Protocol Support | Which southbound protocols? Which versions? | Documentation review, lab testing |
| Scale Limits | Max devices? Max flows? Max flow rate? | Documented limits + load testing |
| Availability | Cluster modes? Failover time? Recovery? | Failure injection testing |
| Performance | Flow install latency? Path compute time? | Benchmarking under load |
| Security | AuthN/AuthZ? Encryption? Audit? | Security review, compliance check |
| Integration | API quality? SDKs? Ecosystem? | Integration testing, dev experience |
| Operations | Upgrade process? Monitoring? Logging? | Operational walkthrough |
| Community/Support | Activity level? Issue resolution? Roadmap? | Community engagement, support trials |
Operational Criteria
Day 1 (Deployment)
Day 2 (Operations)
Ecosystem and Community Criteria
For Open Source:
For Commercial:
Nothing substitutes for talking to actual users. Request references from vendors or find community members with production experience. Ask specifically: What problems did you encounter? How responsive was support? What would you do differently? References reveal realities that documentation and demos hide.
Different deployment scenarios favor different controllers. Understanding use case alignment accelerates shortlist development.
Data Center SDN
For traditional or greenfield data centers managing leaf-spine fabrics:
Key Needs:
Strong Candidates:
Campus and Enterprise
For enterprise campus and branch networks:
Key Needs:
Strong Candidates:
| Use Case | Primary Needs | Strong Candidates | Considerations |
|---|---|---|---|
| Carrier Access | Scale, resilience, P4 programmability | ONOS (SEBA) | Carrier-grade operations required |
| Service Provider WAN | Traffic engineering, multi-domain | ONOS, ODL with PCEP | BGP-LS, Segment Routing support |
| Enterprise Data Center | Virtualization integration, security | VMware NSX, Cisco ACI | Vendor alignment important |
| Multi-Tenant Cloud | Tenant isolation, API-first | OpenStack Neutron + ODL, NSX-T | Cloud platform integration |
| Research/Academic | Experimentation, customization | ONOS, Ryu, Faucet | Community support essential |
| SD-WAN | Branch connectivity, optimization | Vendor SD-WAN solutions | End-to-end solution often beats DIY |
Service Provider and Carrier
For telecommunications operators:
Key Needs:
Strong Candidates:
Multi-Cloud and Hybrid
For environments spanning on-premises and cloud:
Key Needs:
Strong Candidates:
Each controller has a 'center of gravity'—a primary use case where it excels. Forcing a carrier controller into an enterprise data center (or vice versa) creates friction. Choose controllers that naturally align with your primary use case, even if they lack features for secondary scenarios.
A well-designed proof of concept (POC) validates controller suitability before production commitment. POCs should be rigorous enough to reveal problems while scoped to complete in reasonable time.
POC Design Principles
Representativeness
Focus on Risk
Objectivity
123456789101112131415161718192021222324252627282930313233343536373839404142434445
# SDN Controller POC Test Plan ## 1. Environment Description- Topology: 3 spine, 12 leaf switches (OpenFlow 1.3)- Controller: 3-node cluster on VM (8 vCPU, 32GB RAM each)- Integration: VMware vCenter 7.0, Grafana 9.0 ## 2. Test Categories ### 2.1 Functional Tests| Test ID | Description | Success Criteria ||---------|-------------|------------------|| F-001 | Topology discovery | All 15 switches discovered < 60s || F-002 | Path provisioning | Path created via API, traffic flows || F-003 | Policy enforcement | ACL blocks specified traffic | ### 2.2 Performance Tests| Test ID | Description | Success Criteria ||---------|-------------|------------------|| P-001 | Flow installation rate | > 500 flows/second sustained || P-002 | Path computation time | < 100ms for 500-node topology || P-003 | API response time | < 50ms for topology query | ### 2.3 Resilience Tests| Test ID | Description | Success Criteria ||---------|-------------|------------------|| R-001 | Controller failover | Traffic continues < 5s interruption || R-002 | Switch reconnection | Switch reconnects < 30s || R-003 | Split-brain handling | No conflicting rules installed | ### 2.4 Integration Tests| Test ID | Description | Success Criteria ||---------|-------------|------------------|| I-001 | vCenter sync | VM events reflected in controller || I-002 | Grafana dashboards | Metrics visible in dashboards | ## 3. Issue Tracking| Issue | Severity | Resolution | Notes ||-------|----------|------------|-------|| | | | | ## 4. Final Evaluation- All Must-Have criteria met: [ ] Yes [ ] No- Blocking issues: (list)- Recommendation: (proceed/reject/conditional)POC Duration and Resources
Common POC Mistakes
Comparative POC
When shortlist contains multiple strong candidates:
POC success doesn't guarantee production success. Production brings scale, operational pressure, and edge cases that POCs cannot fully replicate. Use POC to eliminate clearly unsuitable options and validate core functionality—but plan for production surprises even with successful POC.
Controller selection must consider total cost of ownership (TCO), not just license fees. Open-source controllers may cost more than commercial alternatives once integration and operations are factored in—or vice versa.
TCO Components
Direct Costs
Indirect Costs
| Cost Category | Open Source Controller | Commercial Controller |
|---|---|---|
| Software License | $0 | $200,000/year × 3 = $600,000 |
| Support Contract | $50,000/year (optional) | Included or additional |
| Controller Hardware | $30,000 (3 servers) | $30,000 (3 servers) |
| Integration Development | $200,000 (engineering time) | $50,000 (pre-built) |
| Training | $30,000 | $20,000 |
| Operational Overhead | $80,000/year (internal support) | $40,000/year (vendor-assisted) |
| 3-Year TCO | $550,000 | $870,000 |
Note: The example above shows open source as cheaper, but this varies dramatically by organization. An organization with strong engineering capability may extract significant value from open source, while one requiring vendor hand-holding may find commercial options more economical.
Hidden Cost Factors
Skill Availability: If controller requires scarce skills, hiring and retention add cost.
Integration Complexity: Deep integrations (orchestration, security, monitoring) require engineering time proportional to complexity.
Upgrade Disruption: Difficult upgrades mean operational windows, testing time, and potential rollback.
Lock-In Switching Cost: If you later need to change controllers, what's the migration cost?
Downtime Cost: What's the business cost of controller-caused outages? This varies enormously by organization.
Opportunity Cost: Time spent fighting controller issues is time not spent on innovation.
TCO is one input to selection, not the only one. A controller that costs more but enables capabilities your competitors lack may be strategically worth it. A controller that costs less but creates operational friction may be false economy. Balance cost against value delivery.
Controller selection concludes with a formal decision and governance structure for ongoing evaluation.
The Decision Process
Stakeholder Alignment
Before finalizing, ensure alignment across stakeholders:
Decision Documentation
Document the decision thoroughly:
This documentation serves multiple purposes: justification for stakeholders, reference for future decisions, and foundation for post-implementation review.
Post-Selection Governance
Selection isn't the end—ongoing governance ensures continued fit:
Regular Reviews
Exit Criteria
Define conditions that would trigger reconsideration:
Migration Planning
Even with a good selection, plan for potential future migration:
Controller selection is not a one-time decision but an ongoing commitment. Markets evolve, requirements change, and experience reveals realities invisible during selection. Build in governance mechanisms that enable course correction without requiring crisis-driven change.
We've developed a comprehensive framework for SDN controller selection—from requirements definition through ongoing governance. Let's consolidate the key insights:
Module Complete
This concludes our exploration of SDN Controllers. You now understand:
With this knowledge, you're equipped to evaluate, select, and work with SDN controllers in production environments.
You've completed the SDN Controllers module, gaining comprehensive understanding of controller architecture, types, APIs, major implementations, and selection methodology. This knowledge forms the foundation for designing, deploying, and operating SDN infrastructure. The next module explores Network Function Virtualization (NFV) and its relationship with SDN.