SONiC Switch RFP Questions Every Australian Data Center

SONiCopen networkingdata centerAI fabricEthernetautomation

In brief

A practical SONiC switch RFP framework for Australian data center buyers, covering AI fabric readiness, support SLAs, lifecycle risk, telemetry, and open NOS validation.

Key takeaways

A practical SONiC switch RFP framework for Australian data center buyers, covering AI fabric readiness, support SLAs, lifecycle risk, telemetry, and open NOS validation.

Why Australian Data Center Operators Need a Dedicated SONiC RFP Framework

The Australian data center market is entering a period of rapid structural change. AI training and inference workloads are reshaping rack density assumptions, sovereign data requirements are narrowing the field of acceptable vendors, and liquid cooling is moving from optional to mandatory at new-build facilities. Against this backdrop, the Open Compute Project Podcast’s January 2026 episode with David Hirst, CEO of Macquarie Data Centres, offers a revealing window into how Australian operators think about infrastructure procurement.

Hirst described a market where AI behaves differently from traditional cloud workloads, where compliance is emerging as a market advantage rather than a cost center, and where long-term operators differ sharply from short-term developers in their procurement approach. These dynamics make the standard, generic RFP template insufficient for SONiC-based switch procurement.

SONiC (Software for Open Networking in the Cloud) is an open-source network operating system hosted under the Linux Foundation through the SONiC Foundation. It runs on switches from multiple hardware vendors and ASICs, offering a full suite of network functionality including BGP and RDMA that has been production-hardened in hyperscale data centers. The SONiC architecture is container-based, with each network function running in its own Docker container, which provides fault isolation, simplified upgrades, and enhanced scalability compared to monolithic switch software.

For Australian enterprise and data center buyers evaluating open networking, the RFP question set must go beyond port counts and price-per-Gbps. It must address sovereignty, multi-vendor support, containerized NOS architecture, production readiness, and the specific demands of AI fabric deployments. This analysis provides a source-backed framework for building that question set.

RFP Structure: What the Procurement Framework Tells Us About SONiC Buying

Before diving into SONiC-specific questions, it is worth grounding the RFP structure in established procurement best practices. A well-documented RFP framework, as outlined by Invensis Technologies in their RFP process guide, identifies five phases: need identification, RFP drafting, vendor distribution and engagement, systematic evaluation, and vendor selection with onboarding.

Several findings from this framework apply directly to SONiC switch procurement:

Evaluation criteria must be weighted before proposals arrive. The Invensis framework emphasizes that evaluation criteria and their weightings (for example, technical merit versus cost) should be defined in writing before the RFP is released. For SONiC procurement, this means Australian buyers should decide in advance how much weight to assign to multi-vendor ASIC support, containerized architecture maturity, community versus commercial SONiC distribution, and post-deployment support models.

Vague RFPs yield poor results. The source explicitly warns that RFPs lacking a clear scope of services or clear objectives frustrate vendors and make it hard to compare proposals. In the SONiC context, this is particularly relevant: vendors offering SONiC-compatible hardware may interpret loosely worded requirements differently, leading to proposals that range from bare-metal switches with community SONiC images to fully supported enterprise distributions with SLAs.

Post-award contract management is where most RFPs fail. This insight applies strongly to SONiC deployments, where the relationship between hardware vendor, NOS distribution, and ongoing software support is more complex than in traditional single-vendor switch procurement. Australian operators should build post-award KPIs and governance structures into the RFP itself, not treat them as afterthoughts.

The lowest bid does not represent the best value. As procurement consultant Yves Laffiche is quoted in the Invensis guide: ‘An RFP allows you to weigh expertise, compliance, and innovation — things that cannot always be quantified by price alone.’ This principle is foundational for open networking procurement, where total cost of ownership over three to five years depends on software support, community health, and hardware refresh flexibility rather than initial switch port pricing.

The SONiC Technical Baseline: What the Open Source Platform Offers

Understanding what SONiC actually delivers is a prerequisite for writing useful RFP questions. The SONiC Foundation and the project’s GitHub repository describe a platform with several defining characteristics that should appear in any buyer’s evaluation criteria.

Multi-vendor and multi-ASIC support. SONiC runs on switches from multiple hardware vendors and uses the Switch Abstraction Interface (SAI) to decouple hardware from software. This is architecturally significant: it means an operator can evaluate bare-metal switch hardware independently from the network operating system, breaking the traditional coupling between vendor-specific hardware and vendor-specific NOS.

Container-based modular architecture. Each SONiC network function runs in its own Docker container. The GitHub repository describes this as providing better fault isolation, easier debugging and troubleshooting, simplified upgrades and maintenance, and enhanced scalability. For RFP purposes, this means buyers can ask pointed questions about container upgrade paths, rollback mechanisms, and the ability to update individual network functions without full switch reboots.

Production-hardened in hyperscale environments. SONiC’s origin as a Microsoft Azure project and its subsequent adoption by other large cloud service providers means the NOS has been validated at scale. The SONiC Foundation states that SONiC offers a full suite of network functionality, including BGP and RDMA, that has been production-hardened in the data centers of some of the largest cloud service providers.

Open source with an active community. The GitHub repository shows 2,800+ stars, 1,300+ forks, and nearly 3,000 commits, indicating active development. SONiC is licensed under the Apache License 2.0. For Australian buyers, the open-source nature of SONiC raises specific RFP questions about enterprise support options, security patching SLAs, and the distinction between community SONiC and commercial enterprise distributions.

JSON-based configuration and programmatic management. SONiC supports both CLI and programmatic configuration methods using JSON-based configuration files. This is relevant for operators building automation pipelines and should be addressed in RFP questions about Day 2 operations tooling.

The Australian Context: Sovereignty, AI Workloads, and Market Specifics

The Australian data center market has characteristics that make a generic global RFP template inadequate. The OCP Podcast Episode 18, recorded in January 2026, captures several of these dynamics through a conversation with David Hirst, CEO of Macquarie Data Centres.

Data sovereignty is a procurement differentiator. Hirst described a market where compliance is not merely a cost but a market advantage. Australian government and critical infrastructure operators face specific data sovereignty requirements that affect networking equipment procurement. Any SONiC RFP for the Australian market should include questions about the provenance of NOS distributions, the location of support operations, and the ability to audit source code — an advantage that open-source SONiC provides over proprietary alternatives.

AI workloads change infrastructure assumptions. Hirst noted that AI behaves differently from cloud workloads, describing a shift from ‘real estate’ thinking to ‘chip-out’ thinking in data center design. For switch procurement, this translates to RFP questions about RDMA over Converged Ethernet (RoCE v2) support, lossless fabric capabilities, Data Center Bridging Capability Exchange (DCBX), congestion notification (Fast CNP), and in-band network telemetry (INT). These are not optional features for AI fabric deployments; they are baseline requirements.

Liquid cooling is blurring boundaries. Hirst discussed how liquid cooling and megawatt-per-rack designs are reshaping Australian data center planning. While cooling is not a direct switch procurement concern, it affects cabling, airflow, and form factor decisions that should appear in SONiC switch RFP questions — particularly around rear-to-front versus front-to-rear airflow options, compact form factors, and power draw specifications.

Long-term operators differ from short-term developers. Hirst drew a distinction between long-term data center operators and short-term developers in the Australian market. For operators planning seven-to-ten-year infrastructure lifecycles, SONiC’s open-source model offers a path to avoid end-of-life lock-in. RFP questions should address SONiC version lifecycle policies, long-term support (LTS) commitments, and hardware compatibility across NOS generations.

Australia-specific power and community challenges. Building in dense cities and working with communities was flagged as a specific Australian challenge. This affects procurement timelines and should be reflected in RFP lead time and delivery schedule questions.

SONiC Switch RFP Scoring Matrix

The RFP should force comparable answers. A weak RFP asks for “400G SONiC support” and receives ten vendor brochures. A useful RFP asks for a nominated switch SKU, ASIC, SONiC image, optics list, telemetry method, support boundary, and acceptance test evidence. The following matrix is written for Australian data center buyers who need engineering evidence before commercial award.

RFP Domain	Minimum Vendor Response	Buyer Acceptance Test	Suggested Weight
NOS and hardware compatibility	Exact SONiC distribution, release branch, ASIC family, SAI dependency, ONIE recovery steps	Boot 2 switches from the quoted image, reload 3 times, verify LLDP, BGP, optics, fans, PSU telemetry, config persistence, and rollback	20%
AI fabric and RoCE readiness	PFC, ECN, DCBX, QoS, buffer profile, RoCE v2 support, 100G/400G/800G port options	Run traffic at production-equivalent speed, record ECN marks, PFC pause frames, CNP events, frame drops, and recovery after link failure	20%
Automation and observability	CLI, JSON config, NETCONF/YANG, gNMI/OpenConfig, syslog, SNMP, streaming telemetry support	Push a golden config, collect counters for 24 hours, restore from backup, and prove alert mapping into the buyer’s NMS	15%
Security and compliance	Secure boot position, image signing where available, patch cadence, CVE handling, account model, audit logs	Review a sample critical CVE response, confirm upgrade path, and validate RBAC and log export during pilot	15%
Operations support	APAC escalation hours, 24x7 critical incident process, RMA terms, spares, L3 ownership across hardware/NOS/optics	Open a pilot support ticket, measure response time, and confirm named escalation ownership	15%
Lifecycle and commercial control	36-month and 60-month support pricing, optics policy, roadmap, end-of-sale/end-of-support terms	Compare total cost including optics, spares, training, support renewals, and migration effort	15%

The scoring model should be frozen before proposals arrive. If the buyer changes weights after seeing price, the RFP becomes a negotiation exercise rather than an engineering selection process. For regulated or sovereign workloads, increase the weight of security, support jurisdiction, and auditability. For AI training clusters, increase the weight of RoCE, congestion control, telemetry, and 400G/800G validation.

RFP Questions That Should Be Answered in Writing

Use direct, testable questions. The aim is to make every answer either verifiable during a pilot or contractually enforceable after award.

Question Area	Exact Question	Why It Matters
SONiC version	Which SONiC branch, kernel, container versions, and vendor patches are included in the quoted release?	”Supports SONiC” is not enough; operational behaviour changes by release and distribution.
ASIC and SAI	Which ASIC family and SAI version are used, and which features depend on vendor SDK behaviour?	Open NOS does not remove hardware dependencies; it makes them visible.
AI fabric	What are the tested PFC, ECN, DCBX, buffer, and telemetry settings for RoCE v2 workloads?	GPU fabrics fail in congestion edge cases, not in idle feature demos.
Optics	Which 25G, 100G, 400G, and 800G optics have been validated, and what is the policy for third-party transceivers?	Optics are a common source of hidden lock-in and post-award disputes.
Upgrade and rollback	What is the tested rollback path if an upgrade fails inside a 2-hour maintenance window?	A data center RFP must evaluate recovery, not only installation.
Support boundary	Who owns L1, L2, and L3 escalation for failures involving switch hardware, SONiC, optics, and automation?	Disaggregated networking needs clear accountability across layers.

Pilot Runbook Before Final Award

Shortlist vendors should pass a production-representative pilot before contract signature. The pilot should include at least 2 leaf switches, 2 spine-facing links, representative optics, the buyer’s monitoring stack, and the same configuration method planned for production. A 48-hour run is often enough to expose weak documentation, telemetry gaps, and support ambiguity.

Acceptance evidence should include configuration files, version output, interface counters, optics diagnostics, BGP session logs, telemetry samples, failure injection notes, and rollback results. Reject or rework the proposal if the supplier cannot reproduce the configuration without manual console work, cannot explain PFC or ECN thresholds, or cannot provide a credible escalation path during Australian operating hours.

Engineering FAQ

Should price per port be the primary RFP metric? No. Price per 100G or 400G port is useful, but it should sit behind support ownership, validated feature depth, optics policy, lifecycle risk, and recovery evidence. The cheapest quote can become expensive if the buyer inherits integration work.

What is the most common SONiC RFP mistake? Asking for generic SONiC support instead of the exact release, ASIC, feature profile, telemetry interface, and rollback procedure. Open networking is only valuable when the buyer can validate the actual operating stack.

How should AI fabric requirements be separated from ordinary data center requirements? Put RoCE v2, PFC, ECN, DCBX, buffer profile, CNP visibility, and lossless telemetry into a separate scored section. AI fabrics have congestion behaviour that ordinary leaf-spine routing tests will not reveal.

What should xSONiC buyers request before purchase? Request the nominated switch SKU, SONiC image, validated optics list, support workflow, pilot acceptance plan, and written rework criteria. A serious supplier should be comfortable proving the stack before the buyer commits to volume.

Sources Reviewed

Product fit

Where xSONiC fits

xSONiC can help validate the switch, optics, software image, telemetry, and support assumptions against the actual deployment before a production order is released.