Theory about open networking is abundant. Practical guidance from people who have actually done it is rarer. This guide draws on IP Infusion’s experience across 600+ customer deployments to give operators a grounded, actionable framework for evaluating and executing a disaggregated networking deployment.
Question 1: Are Your Use Cases Actually Supported?
The most important question before any disaggregation project is protocol coverage. OcNOS covers the full SP and DC stack, but the specific features you need should be verified against the OcNOS Feature Matrix and tested in the Demo VM before any procurement decision.
Common use cases that are fully supported and production-proven in OcNOS:
- BGP full table peering (1M+ routes) with FlowSpec DDoS mitigation
- SR-MPLS with TI-LFA fast reroute and Flex-Algo network slicing
- EVPN all service types (E-LINE, E-LAN, E-TREE, L3VPN) over MPLS
- EVPN-VXLAN data center fabric with PFC/ETS lossless transport
- IEEE 1588v2 PTP for 5G timing with hardware timestamping
- IPoDWDM with 100G/400G coherent optics managed via OcNOS CLI
Question 2: Hardware Selection
OcNOS runs on 100+ validated platforms. The right hardware depends on:
| Factor | Guidance |
|---|---|
| Port speed and density | Match silicon generation to your capacity requirements; don’t over-spec |
| Form factor | Fanless options available for outdoor/remote; standard 1U for rack environments |
| Silicon vendor | Broadcom for DC (TH5 for AI fabric); Marvell or Broadcom for SP |
| PTP requirements | Verify hardware timestamping support for 5G timing deployments |
| Transceiver ecosystem | OcNOS supports third-party optics; verify specific transceivers needed |
The Deployment Pattern That Works
The most successful OcNOS deployments follow a consistent pattern:
- Lab validation first — download the OcNOS Demo VM, build your topology in GNS3 or ContainerLab, validate your specific configurations. This identifies any feature gaps or configuration quirks before hardware arrives.
- Pilot on a non-critical segment — deploy 2–4 OcNOS nodes on a lower-risk part of the network first (a new broadband aggregation point, a secondary peering location) to build operational confidence before touching the core.
- Parallel deployment for migration — when replacing legacy hardware, bring OcNOS nodes up in parallel and migrate traffic gradually rather than doing a single cutover.
- Automation from day one — even for small deployments, invest in Ansible or NETCONF templates early. The operational efficiency at scale depends on consistent, automated configuration management.
What Changes Operationally
The biggest operational adjustment for teams coming from proprietary NOS is not the CLI — OcNOS CLI is industry-standard and familiar. It is the hardware independence. When something goes wrong, the diagnostic divide between hardware and software is cleaner — you can swap hardware without affecting software state, and you can update software without hardware maintenance windows. This is a workflow change that teams adapt to quickly once they experience it.
IP Infusion Marketing Team