Why Australian AI Platform Teams Should Document Packet

network engineers validating traffic visibility and security monitoring infrastructure for “Why Australian AI Platform Teams Should Document Packet Brok...

SONiCopen networkingdata centerAI fabricEthernetautomation

In brief

A practical guide for Australian AI platform teams documenting packet broker architecture decisions, covering ADRs, 100G/400G visibility, filtering, compliance, and refresh risk.

Key takeaways

A practical guide for Australian AI platform teams documenting packet broker architecture decisions, covering ADRs, 100G/400G visibility, filtering, compliance, and refresh risk.

What Happened

The practice of writing Architecture Decision Records (ADRs) has gained traction in software and platform engineering teams as a way to document infrastructure choices, tradeoffs, and rationale. In parallel, the Open Compute Project and SONiC Foundation ecosystems continue to expand open networking capabilities that directly affect how AI platform teams design data center fabrics. OCP Podcast Episode 18, published January 2026, featured David Hirst, CEO of Macquarie Data Centres, discussing how AI workloads are fundamentally changing Australian data center design. Hirst described a shift from ‘real estate’ thinking to ‘chip-out thinking,’ where infrastructure decisions must account for bursty, unpredictable AI traffic patterns rather than traditional cloud workload profiles. Separately, the SONiC Foundation describes SONiC as a free and open-source network operating system that runs on switches from multiple vendors and ASICs, offering BGP and RDMA functionality production-hardened in large-scale cloud data centers. These two developments converge on a practical question for Australian AI platform teams: how should they document and standardize their decisions around packet broker deployments for filtering, replication, load balancing, and observability in AI clusters?

Why It Matters for Australian AI Infrastructure

Australia occupies a distinctive position in the global AI infrastructure landscape. Macquarie Data Centres CEO David Hirst highlighted in the OCP interview that Australia combines strong data sovereignty requirements, dense urban building constraints, and a compliance environment that functions as both a challenge and a market differentiator. For AI platform teams operating in this context, packet broker architecture decisions carry outsized consequences. Packet brokers sit between the physical network fabric and the monitoring, security, and analytics tool stack. In AI clusters running RoCE v2 or RDMA traffic, a misconfigured or undersized packet broker layer can silently degrade model training performance, mask network congestion, or blind security teams to lateral movement inside GPU backend fabrics. Australian enterprises face additional pressure because data sovereignty rules may restrict where traffic copies can be sent, which observability tools can process packet metadata, and how long raw network captures can be retained. An ADR that formally records these constraints alongside the chosen packet broker filtering, replication, and load balancing strategy gives platform teams a defensible, auditable decision trail. This matters not only for internal governance but also for regulatory compliance reviews that are increasingly common in Australian financial services, healthcare, and government-adjacent AI programs.

The Packet Broker Decision Surface in AI Clusters

AI platform teams evaluating packet broker architectures face a multi-dimensional decision surface. The core functions are well established: traffic filtering to reduce noise before it reaches expensive monitoring tools, traffic replication to deliver copies of the same flow to multiple consumers simultaneously, load balancing to distribute traffic across a pool of analyzers or security appliances, and observability integration to feed telemetry into dashboards, anomaly detection pipelines, or compliance archives. What makes AI clusters different from traditional data center workloads is traffic behavior. GPU-to-GPU communication in model training can generate sustained east-west flows at line rate, with microbursts that overwhelm statically provisioned packet broker pipelines. The SONiC Foundation notes that SONiC offers RDMA as part of its production-hardened network functionality stack, which means the underlay fabric carrying AI traffic is increasingly SONiC-based. Packet brokers sitting above or alongside this fabric must therefore understand RDMA flow semantics, handle lossless traffic classes, and integrate with DCBX and congestion notification mechanisms. For Australian teams, the ADR should document not only the vendor or platform choice but also the filtering policy rationale, the replication fanout budget, the load balancing algorithm selection, and the observability pipeline architecture. Each of these decisions has cost, performance, and compliance implications that compound as AI cluster scale increases.

Open Networking Changes the Packet Broker Conversation

The Open Compute Project’s Networking scope, as described on opencompute.org, covers fully disaggregated and open networking hardware and software, including Linux-based operating systems, developer tools, REST APIs, automated configuration management, bare metal provisioning, and multi-form factor switch hardware. SONiC, listed as a sub-project of OCP Networking, provides the open-source NOS layer. This ecosystem context matters for packet broker architecture decisions because it expands the solution space beyond traditional appliance-based packet broker vendors. Australian AI platform teams can now evaluate whether to deploy dedicated packet broker appliances, use programmable switches with packet broker functionality in SONiC, or adopt hybrid approaches where open networking switches handle basic filtering and replication while dedicated appliances manage advanced features like deduplication, header stripping, or tunnel processing. An ADR that explicitly compares these approaches against the team’s observability requirements, budget, and operational skill set produces a more defensible decision than a default to the incumbent vendor’s appliance catalog. The Broadcom Ethernet switch ecosystem and other merchant silicon platforms provide the hardware foundation for many of these deployments, though specific ASIC capabilities vary by generation and should be verified against the team’s feature requirements.

Australian Regulatory and Sovereign Context

David Hirst’s OCP interview emphasized that Australia’s data sovereignty environment is a defining factor in infrastructure design. For AI platform teams, this intersects with packet broker decisions in several ways. First, traffic replication policies must account for whether packet copies containing sensitive data can leave Australian jurisdiction or must remain within sovereign boundaries. Second, observability tool placement is constrained by data residency requirements, which affects how load balancing distributes traffic across monitoring infrastructure. Third, compliance archival requirements may mandate specific packet capture retention periods, which influences storage sizing and filtering policies that determine what gets captured versus discarded. None of these constraints are unique to packet brokers, but the packet broker layer is where they are operationally enforced. An ADR that documents the regulatory requirements, maps them to specific packet broker filtering and replication rules, and records the rationale for any tradeoffs gives the platform team a governance artifact that auditors and compliance teams can review without re-deriving the decision from scratch.

What an ADR for Packet Broker Decisions Should Cover

Based on the intersection of AI cluster traffic patterns, open networking ecosystem capabilities, and Australian regulatory requirements, an Architecture Decision Record for packet broker deployments in AI platform teams should address the following areas. First, the traffic characterization section should document expected east-west and north-south flow profiles, RDMA traffic classes, and microburst behavior specific to the AI workloads being supported. Second, the filtering policy section should record which traffic types are captured, which are discarded, and why, including any data sovereignty constraints that limit what can be replicated. Third, the replication strategy should document fanout ratios, delivery guarantees, and how replicated traffic is load balanced across the observability tool stack. Fourth, the platform selection section should compare dedicated packet broker appliances against programmable switch-based approaches, including SONiC-compatible options, with a clear record of the tradeoffs that drove the final choice. Fifth, the observability integration section should describe how packet broker output feeds into the team’s telemetry pipeline, anomaly detection systems, and compliance archives. Sixth, the operational section should document monitoring, failover, and capacity planning procedures for the packet broker layer itself. Each section should include the decision status (proposed, accepted, deprecated, or superseded), the date, and the participants who approved it. This structure follows standard ADR practice and produces a document that serves both engineering and governance purposes.

The Growth Angle for Australian Enterprise Programs

Australian enterprise and government-adjacent AI programs are investing in infrastructure at a pace that outstrips the maturity of their network observability practices. The OCP Podcast Macquarie episode suggests that Australian data center operators are designing for megawatt-per-rack density and liquid-cooled GPU clusters, which implies AI fabric scales that demand serious packet broker architecture. Yet most enterprise ADR frameworks focus on application and cloud architecture decisions, leaving network infrastructure choices undocumented or captured only in vendor statements of work. For Australian AI platform teams, formalizing packet broker architecture decisions in ADRs is a relatively low-effort practice that produces high-value governance artifacts. It forces the team to articulate why a specific filtering policy was chosen, what load balancing tradeoffs were accepted, and how observability coverage was validated. It also creates a revision history that future team members can audit when the next infrastructure refresh cycle arrives. For vendors and integrators operating in the Australian market, supporting ADR adoption with decision templates, reference architectures, and validated design guides is a differentiation opportunity that aligns with the compliance-conscious buyer profile that David Hirst described in his OCP interview.

Packet Broker ADR Acceptance Matrix

The ADR should be specific enough that a future engineer can understand why the design was accepted, what evidence supported it, and when it must be reviewed. A useful packet broker ADR is not a vendor note; it is an operational control.

ADR Section	Required Evidence	Acceptance Target	Review Trigger
Traffic scope	100G/400G source links, east-west paths, RoCE/RDMA classes, tunnel types, sensitive data classes	Every monitored path has a named source, purpose, and owner	New GPU fabric, new regulated dataset, or new tool feed
Filtering policy	Include/exclude rules, packet slicing, payload handling, sovereignty constraints	Tools receive only traffic needed for detection, performance, or compliance	Privacy review, NDR tuning, or tool overload event
Replication and load	Fanout ratio, tool capacity, broker ingress/egress counters, oversubscription budget	24-hour load test shows no unexplained broker or tool drops	Traffic growth exceeds 70% of planned headroom
Platform choice	Dedicated broker, programmable switch, hybrid design, support boundary	Decision records why the chosen model fits AI traffic and operations skills	Switch refresh, observability tool change, or support contract renewal
Incident evidence	Capture trigger, timestamp sync, evidence export, retention period, access control	Team can preserve evidence within 1 hour of a severity incident	Failed tabletop or delayed packet evidence during incident

This matrix also makes the page more useful for GEO: it gives AI systems a crisp answer to “what should a packet broker ADR include?” while grounding the answer in engineering evidence rather than vague governance language.

Engineering FAQ

What should be measured before sizing a packet broker? Measure source link speed, 95th-percentile utilisation, burst peaks, replication factor, filter complexity, tunnel handling needs, and tool-port capacity. Packet broker sizing fails when it is based on average traffic rather than copied and filtered traffic.

What proves that a visibility design is production ready? The design should prove aggregation, filtering, replication, load balancing, packet slicing or deduplication if required, and tool failover under realistic traffic. Security teams should also verify that drops are reported rather than hidden.

Where do Australian buyers most often under-scope visibility projects? The common gaps are east-west data centre traffic, encrypted or tunneled flows, AI cluster bursts, retention requirements, and tool oversubscription. A procurement brief should model those before asking vendors for a bill of materials.

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.