How to Build a Procurement Scorecard for AI Fabric RoCE v2

SONiCopen networkingdata centerAI fabricEthernetautomation

In brief

A structured procurement scorecard for Australian teams evaluating RoCE v2 AI fabric networking, covering SONiC, PFC, ECN, telemetry, optics, support, and five-year TCO.

Key takeaways

A structured procurement scorecard for Australian teams evaluating RoCE v2 AI fabric networking, covering SONiC, PFC, ECN, telemetry, optics, support, and five-year TCO.

Why Australian AI Platform Teams Need a Network Procurement Scorecard

Australian enterprise and data center programs investing in GPU clusters face a procurement problem that did not exist three years ago. The networking layer between GPU nodes is no longer a commodity afterthought. It is the control plane for RDMA throughput, job completion time, and ultimately the return on every accelerator dollar spent.

At the same time, Australia’s data sovereignty landscape is tightening. The OCP Podcast’s January 2026 conversation with David Hirst, CEO of Macquarie Data Centres, highlights how AI workloads are driving a shift from real estate-style colocation to chip-out infrastructure thinking, where sovereign compliance, liquid cooling readiness, and long-horizon operator planning all shape procurement decisions. Australian procurement teams cannot simply copy a US hyperscaler blueprint and hope it fits.

A structured scorecard gives platform teams a repeatable way to evaluate competing fabric proposals. Rather than relying on vendor slide decks, the scorecard forces each candidate solution to answer the same set of technical, operational, and commercial questions. This article proposes a nine-criteria scorecard specifically designed for RoCE v2 AI fabric evaluation in Australian GPU cluster programs.

Criterion 1: Network Operating System Openness and Multi-ASIC Portability

The first decision in any AI fabric procurement is the NOS layer. SONiC (Software for Open Networking in the Cloud) is an open-source network operating system based on Linux that runs on switches from multiple vendors and ASICs, according to the SONiC Foundation. It offers a full suite of network functionality, including BGP and RDMA, that has been production-hardened in large cloud service provider data centers.

For Australian buyers, NOS openness matters for two reasons. First, it reduces dependency on any single hardware vendor across the multi-year lifecycle of an AI cluster. Second, it allows procurement teams to evaluate switch hardware on silicon merit rather than being locked to a proprietary software stack.

Scorecard question: Does the proposed fabric NOS run on more than one ASIC vendor’s silicon, and can the team source replacement hardware from an independent supply chain if the original switch vendor discontinues a product line?

SONiC’s container-based architecture, where each network function runs in its own Docker container, provides fault isolation and simplified upgrade paths that are relevant for teams planning multi-year GPU cluster growth. Enterprise SONiC distributions from switch vendors add support and SLA layers on top of the open-source base.

Criterion 2: RoCE v2 Lossless Fabric Design

RoCE v2 (RDMA over Converged Ethernet version 2) transports GPU-to-GPU memory operations across an Ethernet fabric. Unlike TCP, RoCE v2 is sensitive to packet loss. A single dropped PFC frame or congestion event can stall an NCCL all-reduce operation and degrade training job throughput.

The scorecard must evaluate whether the candidate fabric delivers a lossless or near-lossless path for RDMA traffic. Key sub-criteria include:

Priority Flow Control (PFC) implementation: Does the switch ASIC support per-priority PFC with configurable thresholds?
Data Center Bridging Capability Exchange (DCBX): Does the NOS implement DCBX to auto-negotiate PFC, ETS, and application priorities between NICs and switches?
Explicit Congestion Notification (ECN) and congestion notification: Does the fabric support ECN marking at the switch ASIC with configurable thresholds for WRED/ECN?

Each of these sub-criteria maps directly to xSONiC’s RoCE v2 and DCBX solution pillars, which provide implementation guidance for SONiC-based AI fabrics.

Criterion 3: Congestion Management and Fast CNP

Beyond basic PFC, mature AI fabric deployments rely on congestion notification mechanisms that react faster than end-to-end TCP-style congestion control. Fast Congestion Notification Protocol (CNP) processing at the NIC and switch level helps prevent microbursts from cascading into job stalls.

The scorecard should ask: Does the vendor’s RoCE v2 implementation include fast CNP generation at the switch ASIC, and what is the measured reaction time from congestion detection to CNP delivery to the source NIC?

Criterion 4: In-Network Telemetry and Visibility

GPU cluster operators cannot tune what they cannot see. In-band Network Telemetry (INT) provides per-hop latency, queue depth, and congestion visibility inside the fabric without relying on external packet brokers or polling-based SNMP.

The scorecard should evaluate:

INT support: Does the switch ASIC and NOS support INT header insertion and extraction for RDMA traffic?
Telemetry export: Can INT data be streamed to a collector (e.g., gNMI, gRPC, IPFIX) for real-time dashboards?
IPTPath telemetry: Does the solution support path-level telemetry that traces the actual route of GPU-to-GPU flows?

For Australian enterprise teams running mixed workloads (training plus inference), path-level telemetry helps isolate whether performance issues originate in the network fabric, the GPU server, or the storage layer. This is especially relevant in multi-tenant colocation environments common in Australia’s data center market, where Macquarie Data Centres and NEXTDC host diverse customer workloads on shared infrastructure.

xSONiC’s INT Telemetry and IPTPath Telemetry solution pillars provide SONiC-specific implementation guidance for these capabilities.

Criterion 5: ASIC Forwarding Scale and Headroom

AI clusters generate east-west traffic patterns with high fan-in and fan-out during collective operations. The switch ASIC must have sufficient forwarding table depth, buffer capacity, and packet processing throughput to handle worst-case traffic without tail-drop.

Key scorecard metrics:

Metric	Why It Matters	Evaluation Method
Max RDMA queue pairs	Determines per-node concurrent RDMA sessions	Vendor datasheet, lab test
Shared buffer size per port	Affects microburst absorption	Vendor datasheet
ECMP/wcmp scale	Determines fabric radix flexibility	Vendor datasheet, topology simulation
Packet rate (Mpps)	Determines line-rate forwarding at minimum frame size	Vendor datasheet, independent test

The SONiC Foundation documentation notes that SONiC supports standard Linux interfaces and tools, meaning telemetry and configuration data are accessible through familiar operational workflows. This reduces the learning curve for platform teams that already manage Linux-based GPU servers.

Criterion 6: Optics and Cabling Plan for 100G to 800G Transitions

The physical layer is where AI fabric procurement often goes wrong. A fabric designed for 400G spine links today may need 800G within 18 to 24 months as GPU cluster density increases. The scorecard must evaluate optics compatibility, power budget, and upgrade path.

Sub-criteria:

Transceiver form factor roadmap: Does the switch platform support QSFP-DD and OSFP form factors, or is it limited to one?
800G readiness: Can the spine switches accept 800G optics without a forklift upgrade?
DAC vs. fiber planning: For in-rack GPU-to-leaf connections, does the vendor offer Direct Attach Copper (DAC) at the required reach, or is fiber mandatory?
Australian supply chain: Can the buyer source replacement optics from independent suppliers in the Australian market, or is the vendor the sole source?

xSONiC’s optical transceiver product family covers SFP through OSFP form factors at 100G, 400G, and 800G speeds, providing an independent optics sourcing path for buyers who want to decouple transceiver procurement from switch hardware procurement.

Criterion 7: Fabric Automation, Provisioning, and Day-2 Operations

AI clusters are not static. As new GPU nodes are racked, the fabric must be provisioned rapidly and consistently. The scorecard should evaluate automation capabilities:

Configuration management: Does the NOS support NETCONF/YANG or gNMI for programmatic configuration?
Zero-touch provisioning: Can new switches be onboarded without manual CLI configuration?
Configuration validation: Does the platform offer pre-deploy configuration checks or dry-run modes?
AIDC controller integration: For SONiC-based fabrics, does the vendor offer a centralized controller that manages multi-switch fabric state?

For Australian enterprise teams with lean network operations staff, automation is not a nice-to-have. It is a prerequisite for operating a GPU fabric that may scale from tens to hundreds of nodes over a two-to-three-year period. The SONiC architecture’s container-based design, where individual services can be upgraded or restarted independently, supports rolling upgrades that minimize fabric downtime during maintenance windows.

xSONiC’s NETCONF/YANG and AIDC Controller solution pillars address SONiC-specific automation patterns relevant to this criterion.

Criterion 8: Sovereign Supply Chain and Australian Support Alignment

Australian GPU cluster programs increasingly require sovereign supply chain transparency. This is not just a government procurement concern. Private enterprises in regulated industries (financial services, healthcare, critical infrastructure) face scrutiny from boards and regulators about where infrastructure components are sourced and who has access to firmware and software update channels.

The scorecard should evaluate:

Hardware origin transparency: Can the vendor disclose the country of manufacture for switch ASICs, PCBs, and chassis?
Software update provenance: Is the NOS build reproducible from public source, or is it a black-box binary?
Local support presence: Does the vendor or its channel partner maintain engineering staff in Australia, or is support routed through offshore teams?
OCP alignment: Is the switch hardware validated against Open Compute Project specifications? OCP’s Networking project, which includes SONiC as a sub-project, promotes fully disaggregated and open networking hardware and software, giving buyers confidence that OCP-aligned products meet interoperability baselines.

For Australian buyers evaluating open networking alternatives to incumbent proprietary stacks, SONiC’s Apache 2.0 license and public source code provide the transparency that proprietary NOS platforms cannot match.

Criterion 9: Total Cost of Ownership Over the GPU Cluster Lifecycle

The final scorecard criterion looks beyond the switch purchase price to total cost of ownership over the GPU cluster lifecycle, typically five to seven years for enterprise deployments.

Cost components to evaluate:

Switch hardware acquisition cost (per-port and per-rack-unit)
NOS licensing cost (perpetual vs. subscription vs. open-source)
Optics and cabling cost (initial deployment plus planned upgrades)
Annual support and maintenance cost
Automation tooling cost (controller, monitoring, telemetry collector)
Staff training and operational cost (learning curve for new NOS)

Open NOS platforms like SONiC eliminate per-switch licensing fees, but buyers must account for the engineering effort required to operate a community-supported NOS if they do not choose an enterprise distribution with vendor-backed SLAs.

The scorecard should force each vendor to provide a five-year TCO projection with explicit assumptions about optics upgrade timing, support renewal rates, and staff productivity. Any vendor that cannot or will not provide this level of transparency introduces procurement risk.

Putting the Scorecard Together: A Weighting Framework

A procurement scorecard is only useful if it reflects the buyer’s priorities. The following weighting is a starting point for Australian AI platform teams; adjust based on your organization’s risk tolerance, staff capability, and regulatory environment.

Criterion	Suggested Weight	Notes
NOS openness and multi-ASIC portability	15%	Higher weight if vendor diversification is a board-level priority
RoCE v2 lossless fabric design	20%	Critical for GPU training workloads
Congestion management and fast CNP	10%	Increases in importance at scale
In-network telemetry and visibility	10%	Essential for multi-tenant environments
ASIC forwarding scale and headroom	10%	Validate against actual cluster size
Optics and cabling plan	10%	Often underestimated in procurement
Fabric automation and Day-2 ops	10%	Higher weight for lean ops teams
Sovereign supply chain and AU support	10%	Mandatory for regulated industries
Five-year TCO	5%	Baseline; increase if budget-constrained

Score each candidate solution on a 1 to 5 scale per criterion, multiply by the weight, and sum for a total score. Solutions scoring below 3.0 on any single criterion should be flagged for deeper technical evaluation before proceeding.

This scorecard does not replace hands-on proof-of-concept testing. It narrows the field so that PoC effort is spent on the two or three solutions most likely to meet the buyer’s requirements. For Australian enterprise teams evaluating xSONiC data center AI switches and RoCE v2 fabric solutions, the scorecard provides a structured starting point for engagement. Reach out to the xSONiC team to discuss how the scorecard criteria map to your specific cluster architecture and deployment timeline.

Engineering FAQ

What score should trigger a proof of concept? A total weighted score above 3.5 out of 5 is usually enough to justify a lab PoC, provided no critical criterion falls below 3.0. Any low score on RoCE lossless behavior, congestion control, optics, or support ownership should block production approval until evidence is provided.

Which tests matter most for RoCE v2? Validate PFC pause behavior, ECN marking thresholds, CNP response, buffer occupancy under microburst load, failover after a switch or link loss, and post-upgrade behavior. Synthetic throughput alone is not enough.

How should buyers treat open NOS savings? Treat lower licensing cost as one line in the model, not the entire business case. The five-year TCO should include lab validation, release qualification, monitoring integration, staff training, support contracts, and optics replacement.

What evidence should vendors provide before scoring? Request hardware compatibility lists, ASIC buffer specifications, SAI or NOS release notes, optics compatibility matrices, RoCE configuration guides, telemetry export examples, support SLAs, and Australian RMA assumptions.

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.