RFP Question Set for INT and Path Telemetry

SONiCdata centerAI fabricEthernetautomation

In brief

Engineering guidance on RFP Question Set for INT and Path Telemetry for Australian network operators, covering gNMI, NETCONF/YANG, OpenConfig, telemetry pipelines, and.

Key takeaways

Engineering guidance on RFP Question Set for INT and Path Telemetry for Australian network operators, covering gNMI, NETCONF/YANG, OpenConfig, telemetry pipelines, and.

Why Australian AI Data Center RFPs Need a Telemetry Question Set

Australia’s data center market is accelerating. Hyperscale and colocation operators are planning liquid-cooled, megawatt-per-rack facilities to serve AI training and inference workloads, and enterprise buyers are following suit with on-premises GPU cluster deployments. Yet most networking RFPs for these programs still center on port count, aggregate bandwidth, and latency figures. Few procurement teams include structured questions about in-band network telemetry (INT) or path telemetry — the very capabilities that determine whether operations teams can diagnose congestion, packet loss, and microburst events inside AI fabrics after deployment.

This gap matters because AI training clusters behave differently from traditional cloud or enterprise traffic. Synchronized GPU communication patterns — collective operations like AllReduce — create bursty, latency-sensitive flows that can overwhelm a spine-leaf fabric without warning. When a 400G leaf switch drops packets inside a RoCE v2 RDMA flow, the GPU job stalls. Without INT-level visibility into where in the fabric path the congestion occurred, the operations team is left guessing.

For Australian enterprises and data center operators, the stakes are higher. Sovereign data requirements, limited local engineering talent, and long lead times for imported networking hardware mean that getting the RFP right the first time is critical. A procurement process that omits telemetry requirements may result in a fabric that performs adequately on day one but becomes a troubleshooting black box when AI workloads scale.

This article provides a structured RFP question set that Australian data center teams can adapt when evaluating SONiC-based spine-leaf fabrics for AI infrastructure. It covers INT and path telemetry requirements across hardware, software, integration, and operations dimensions.

What INT and Path Telemetry Actually Do in an AI Fabric

Before writing RFP questions, procurement teams need a clear picture of what they are evaluating.

In-band Network Telemetry (INT) is a data plane capability defined in the P4/INT specification. It allows each switch hop in a packet’s path to embed metadata — such as queue depth, ingress/egress port utilization, timestamp, and congestion status — directly into the packet header as it traverses the fabric. The receiving endpoint or a monitoring appliance extracts this metadata, giving operations teams hop-by-hop visibility into every flow without relying on out-of-band polling or sampling.

Path telemetry extends this concept by tracking the actual forwarding path a packet takes through the fabric, including ECMP (Equal-Cost Multi-Path) load-balancing decisions. In a large AI fabric where thousands of GPU nodes communicate through a multi-tier spine-leaf topology, understanding which path a flow took — and whether that path was congested — is essential for diagnosing tail latency and packet loss.

Together, INT and path telemetry give data center operators three capabilities that traditional SNMP or sFlow monitoring cannot match:

Per-hop queue depth visibility — knowing exactly which switch interface is building up congestion, not just which switch is busy.
Flow-level path tracing — seeing the actual ECMP path a GPU-to-GPU flow took, not just aggregate link utilization.
Real-time congestion notification — feeding telemetry data back into congestion management mechanisms like RoCE v2 ECN and DCBX for faster closed-loop control.

For AI workloads running on SONiC-based switches, these capabilities are what separate a fabric that operators can manage at scale from one that becomes opaque under load. The SONiC open-source NOS, which runs on switches from multiple hardware vendors and ASICs, supports telemetry features through its modular, container-based architecture — but the depth and completeness of INT support varies across hardware platforms and SONiC distributions.

The RFP Question Set: 12 Questions for INT and Path Telemetry Evaluation

The following question set is organized into four categories: hardware and ASIC capability, software and NOS integration, operational workflow, and Australian market-specific requirements. These questions are designed to be included in an RFP document as mandatory or weighted evaluation criteria for AI data center networking procurements.

Category 1: Hardware and ASIC Capability

Q1. INT Header Insertion and Extraction Does the switch ASIC support INT header insertion at line rate across all ports at the target speed (100G, 400G, or 800G)? What is the maximum number of INT metadata fields supported per hop (e.g., switch ID, ingress/egress port, queue depth, queue occupancy, ingress/egress timestamp, latency)?

Why this matters: Not all switching ASICs support INT natively. Some support a subset of metadata fields, which limits the granularity of per-hop visibility. Buyers should require vendors to specify which INT metadata fields are supported and whether insertion occurs at line rate without impacting forwarding performance.

Q2. INT Sink and Source Mode Does the switch support both INT source mode (inserting INT headers into specified flows) and INT sink mode (extracting INT metadata at the egress)? Can the switch operate as a transit INT hop? What is the maximum INT header stack depth supported?

Why this matters: A fabric-level INT deployment requires every leaf and spine switch to act as a transit hop, inserting its own metadata into the INT header stack. If a switch only supports sink mode, INT data collection is limited to the egress leaf, losing per-hop detail.

Q3. Path Tracing and ECMP Visibility Does the solution support path tracing that records the actual ECMP forwarding path taken by a packet through the fabric? Can the path trace data be correlated with INT metadata to provide both path and per-hop performance data?

Why this matters: In large AI fabrics with 256 or more GPU nodes, ECMP hash collisions and imbalanced path selection can create asymmetric congestion. Path tracing reveals these issues; basic INT alone does not.

Category 2: Software and NOS Integration

Q4. SONiC INT Support and Distribution Is INT functionality natively integrated into the SONiC distribution provided, or does it require custom patches, third-party agents, or additional software modules? What version of SONiC is the baseline, and when was INT support validated?

Why this matters: SONiC is an open-source NOS with a modular, containerized architecture. However, INT feature support depends on both the hardware platform and the SONiC distribution. Buyers should verify that INT is a supported feature in the vendor’s SONiC build, not a roadmap item or a custom fork.

Q5. Telemetry Data Export Formats Does the solution export INT and path telemetry data via standard protocols such as gNMI, gRPC, or IPFIX? Is there native support for streaming telemetry to a time-series database (e.g., Prometheus, InfluxDB) or a network monitoring platform?

Why this matters: Telemetry data is only useful if it can be collected, stored, and visualized. Proprietary export formats create integration risk and vendor lock-in. Open, standards-based export ensures the data can feed into existing Australian enterprise monitoring stacks.

Q6. Automation and Programmability Can INT and path telemetry be configured and managed programmatically via NETCONF/YANG models or REST APIs? Are configuration templates available for common AI fabric telemetry profiles?

Why this matters: Australian data center teams with limited local engineering resources benefit from programmable telemetry configuration. If every INT policy change requires CLI access to individual switches, operational overhead scales poorly.

Category 3: Operational Workflow

Q7. Congestion Correlation with RoCE v2 and DCBX Can INT telemetry data be correlated with RoCE v2 ECN marking and DCBX (Data Center Bridging Exchange) configuration to identify flows that are experiencing congestion-related packet drops or PFC (Priority Flow Control) pauses?

Why this matters: AI fabrics using RDMA over RoCE v2 rely on ECN-based congestion notification and DCBX for lossless or near-lossless transport. INT data that cannot be correlated with these mechanisms gives operators telemetry data but no actionable path to resolution. See the xSONiC INT Telemetry and RoCE v2 solution pillars for integration guidance.

Q8. Baseline and Anomaly Detection Does the solution include or integrate with tools for establishing telemetry baselines and detecting anomalies (e.g., sudden queue depth spikes, path changes, latency deviations) without manual threshold configuration?

Why this matters: AI workloads are bursty by nature. Manual threshold tuning creates alert fatigue. A solution that can baseline normal INT telemetry patterns and flag deviations reduces the mean time to detect (MTTD) for fabric issues.

Q9. Day-2 Operations Documentation and Support Does the vendor provide operational runbooks, telemetry dashboard templates, and escalation procedures specific to INT and path telemetry troubleshooting? Is local or APAC-based support available during Australian business hours?

Why this matters: INT and path telemetry are relatively new operational capabilities. Australian buyers should require vendors to demonstrate not just feature availability, but day-2 operational readiness including documentation, training, and support coverage.

Category 4: Australian Market-Specific Requirements

Q10. Sovereign Data and Telemetry Storage Where is INT and path telemetry data stored and processed? Can telemetry data be configured to remain within Australian jurisdiction to comply with sovereign data requirements?

Why this matters: Australian government agencies and regulated industries (financial services, healthcare, critical infrastructure) have data sovereignty obligations. Telemetry data that is exported to offshore processing or storage may create compliance risk.

Q11. Local Supply Chain and Spares What is the lead time for switch hardware delivery to Australian data center sites? Are local spares pools maintained in Australia for rapid replacement?

Why this matters: Australia’s geographic distance from major hardware manufacturing hubs means lead times for networking equipment can be weeks or months. A telemetry-rich fabric that cannot be quickly repaired due to supply chain delays undermines operational resilience.

Q12. Proof of Concept and Validation Is the vendor willing to conduct a proof-of-concept (PoC) deployment at an Australian site with INT and path telemetry enabled, demonstrating end-to-end telemetry data collection, visualization, and congestion correlation on a representative AI fabric topology?

How to Weight INT and Path Telemetry in Your Evaluation Matrix

The RFP process should balance telemetry requirements against other evaluation criteria such as port density, latency, power consumption, and total cost of ownership. The following weighting framework is a starting point for Australian data center operators evaluating AI fabric proposals. It is not prescriptive — procurement teams should adjust weights based on their specific workload profile and operational maturity.

Evaluation Category	Suggested Weight	Notes
Hardware performance (port count, speed, latency)	25-30%	Baseline table stakes for any AI fabric RFP
INT and path telemetry capability	15-20%	The questions in this article map to this category
RoCE v2 / RDMA / DCBX support	10-15%	Critical for GPU backend fabric workloads
NOS flexibility (SONiC distribution, programmability)	10-15%	Open-source alignment reduces vendor lock-in risk
Operational readiness (docs, support, automation)	10-15%	Day-2 operational viability for Australian teams
Supply chain and local support	5-10%	Lead times and spares availability in Australia
Total cost of ownership	10-15%	Include ongoing telemetry infrastructure costs

A common procurement mistake is to assign telemetry 0-5 percent weight and then struggle to diagnose fabric congestion after deployment. Assigning INT and path telemetry 15-20 percent of the evaluation score sends a clear signal to vendors that observability is a first-class requirement, not an afterthought.

For Australian programs evaluating SONiC-based fabrics specifically, the weighting above also encourages vendors to demonstrate telemetry maturity in their SONiC distribution, not just advertise raw ASIC capabilities that may not be exposed through the NOS.

Engineering FAQ

What should telemetry prove beyond SNMP polling? Telemetry should prove queue behaviour, interface errors, optics health, route state, congestion signals, drops, and config drift at a useful interval. AI and high-speed fabrics often need streaming data rather than periodic polling.

How should gNMI, NETCONF, and YANG be evaluated? Evaluate model coverage, authentication, collector compatibility, update frequency, failure behaviour, and how data maps into the NOC, SIEM, or automation system. Protocol support alone does not prove operational value.

What makes telemetry useful for incident response? Useful telemetry is timestamped, correlated across devices, retained long enough for investigation, and tied to known topology and change events. It should help answer what changed, where congestion occurred, and which tool owns the next action.

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.