Cluster basis
GPU or accelerator count, NIC profile, traffic pattern, growth plan and failure tolerance drive the fabric requirement.Fabric basis
Leaf and spine counts, port maps, line rate, oversubscription, optics reach and cabling are documented together.Control basis
RoCE v2, queue, PFC, ECN, DCBX, telemetry, automation and rollback assumptions are explicitly reviewed where required.Supply basis
Destination, end user, end use, required documents, delivery terms, support and export review remain order-specific.
Evidence boundary
An 800G chassis image does not prove an AI fabric.
The representative product image does not establish cluster performance, lossless behaviour, interoperability, validation or shipment eligibility. Those conclusions require the selected end-to-end stack and recorded test conditions.
What establishes a project-specific claim
- The cluster, NIC, topology, port-map, optics, cabling, capacity and failure assumptions
- The named software, RoCE or congestion-control settings, telemetry and rollback ownership where required
- Recorded validation outcomes, exceptions and the separate export-review decision for the order
Start with workload and failure assumptions
A fabric brief should explain the workload communication pattern and acceptable failure behaviour before selecting switch speed. This allows topology, bandwidth, congestion controls, telemetry and recovery expectations to be sized around a real operating requirement.
- Accelerator nodes, NICs per node, interface speed and expected scale stages
- Training, inference, storage and management traffic assumptions
- Oversubscription target, failure domains, maintenance and growth method
- Performance indicators and evidence needed for an approval decision
Lock the physical and lossless-Ethernet boundaries
Switch ports, optics, cabling, lane rate, FEC, thermals and spares affect whether links can be operated reliably. Where RoCE is required, queue and congestion-control assumptions also need named owners and measurable validation conditions.
- Leaf and spine port maps, line rate, breakout and oversubscription
- Optics form factor, connector, reach, lane rate, FEC and environment
- RoCE v2, PFC, ECN, DCBX, queue and telemetry requirements where applicable
- Rollback, failure response, exception records and support ownership
Use sources as planning anchors, not proof of a deployment
These sources describe public SONiC, telemetry, Ethernet development and Australian export frameworks. They do not prove that a particular fabric is compatible, accepted or eligible for shipment.
AI fabric brief
What must be known before a 400G or 800G quote is defensible
Is GPU count enough to size the network?
No. Include NIC profile, traffic pattern, topology, growth, oversubscription, failure domains, optics reach and operating requirements.
Are RoCE, PFC and ECN required for every AI workload?
No blanket rule applies. State the workload and host-network requirements, then validate the necessary queue and congestion-control behaviour for the selected stack.
What evidence can be requested before shipment?
Depending on the agreed scope, request a port and optics matrix, version record, link or telemetry observations, representative test results, exceptions and rollback notes.
Does a validated fabric automatically qualify for export?
No. Technical acceptance and export review are separate gates. Destination, end user, end use and product scope still require order-specific review.