OCP Global Summit 2026#

Core#

Co-Designing AI Fabrics: Inside Google's Virgo Network and the Campus-as-a-Computer#

Abstract Recording

Sunil Ahluwalia (Google), JK Lee (Google)

• Why: One of the few public looks inside Google's AI fabric — the architectural shift from "data center as a set of servers" to campus-scale supercomputer is the defining physical-networking problem of this cycle, and Google is unusually specific here about the transport and telemetry mechanisms.
• What: Virgo, a megascale multi-plane AI datacenter fabric running open-source SONiC, built for synchronized-burst ML traffic with a stated value proposition of predictable low latency and maximized "goodput" (from abstract only).
• How: Open-source RDMA transport (Falcon), Congestion Signaling (CSIG), and High-Speed Telemetry (HST), on a multi-plane architecture over open standards and merchant hardware ecosystems.
• Where applicable: Google-specific production design, but the constituent technologies (CSIG, HST, Falcon) are being pushed into SONiC/open ecosystems — see the Google SONiC CSIG/HST talk below, which is the deployable version of this story.

MetaRoCE: Rethinking RDMA for the AI presented by Meta#

Abstract Recording

Arvind Srinivasan (Meta), Sandeep Nagaraja (Meta), Balakrishnan Raman (AMD)

• Why: A clean-sheet replacement for RoCEv2 from one of the largest GPU-fleet operators, now being opened as a spec — directly in the PM's lossless-fabrics/RDMA core interest and a candidate competitor/complement to MRC (below).
• What: MetaRoCE, a multipath, out-of-order, receiver-driven RDMA transport that treats Ethernet as lossy by design rather than patching lossless fabrics with more tuning; Meta is publishing the specification for industry adoption (from abstract only).
• How: All transport intelligence is pushed into the NIC; multipath and receiver-driven delivery replace PFC-style losslessness as the reliability model.
• Why it matters for triage: Paired with MRC and SUE-T, this is the third open transport spec from a hyperscaler this cycle — the field's verdict that decade-old RoCEv2 is done at 10k+ GPU scale.
• Where applicable: Meta production (tens of thousands of GPUs); AMD co-presenting suggests NIC-side implementation requirements — adoption depends on NIC vendor support, so watch the ecosystem response.

SUE-T - An Ethernet transport for Scale-Up Networking#

Abstract Recording

Tom Emmons (Arista Networks), Karen Schramm (Broadcom)

• Why: ESUN defines the network requirements; SUE-T defines what actually rides on it — the semantics of moving memory transactions between XPUs over Ethernet. This is the layer where scale-up Ethernet becomes a real RDMA-class competitor.
• What: The Scale-up Ethernet Transport framework: low-latency, high-bandwidth connectivity where a SUE-T instance moves memory transactions between XPUs across rack/multi-rack clusters (from abstract only).
• How: An Ethernet-based transport protocol suitable for deployment over ESUN-defined networks; the session walks the specification and how it meets scale-up's latency and bandwidth demands for next-gen XPU designs.
• Where applicable: General technique (open spec, not operator-specific), but requires XPU and switch support for the transport; relevant to anyone evaluating open alternatives to proprietary scale-up fabrics.

Tahan: An Open, Ethernet-Based Scale-Up Switch for Meta's MTIA Accelerators#

Abstract Recording

Ashutosh Grewal (Meta), Vimal Vasudevan (Meta Platforms inc.)

• Why: The best "show me the hardware" talk on scale-up Ethernet: a first-generation open scale-up switch with real numbers, and a rare case of one NOS (FBOSS) and one transport (RoCE) spanning both scale-out and scale-up.
• What: Tahan, Meta's first scale-up switch for MTIA 300 accelerators: 6.4 Tbps per accelerator over 8× 800GbE passive copper links, 16 accelerators per liquid-cooled rack interconnected via 4 switches in a non-blocking topology, on merchant 25T/51.2 Tbps silicon running FBOSS (from abstract only).
• How: Reuses the scale-out network's lossless RoCE transport (routed IPv6, PFC, AI-tuned QoS) on the scale-up fabric, eliminating separate software stacks and operational silos; next-gen targets 8 switches on 102.4 Tbps silicon, 72 accelerators per rack, adopting OCP ESUN as the dataplane.
• Where applicable: Meta-specific (MTIA, FBOSS, in-rack passive copper reach), but the architecture pattern — unifying scale-up/scale-out under one Ethernet transport and NOS — is broadly instructive; note the passive-copper choice constrains it to in-rack distances.

Meta 102.4T Ethernet Switch#

Abstract Recording

Rongchun Zhou (Meta), Reza Niazmand (Meta)

• Why: The switch platform that much of Meta's next-gen AI fabric story runs on — a concrete OCP hardware contribution on the newest merchant silicon, directly in the PM's physical switching interest.
• What: IceCube, a 102.4T non-blocking Ethernet switch on the Broadcom TH6C ASIC running FBOSS: 2OU form factor, 64× OSFP-RHS user ports, liquid-cooled; IecPack is an ORv3-HPRv1 rack integrating eight IceCube blades plus servicing equipment for versatile switch roles (from abstract only).
• How: Standard OCP open-hardware contribution model — merchant silicon + open NOS + open rack; engineering focus is reliability, power efficiency, and NPI velocity.
• Where applicable: Meta-specific platform but fully OCP-documented; requires TH6C-class silicon and liquid-cooled racks. Pair with the integrated-optics talk for where this platform line is heading optically.

Integrated Optics at Scale for AI Infrastructure: From 51.2T CPO Validation to Meta's 102.4T Integrated Optics Switch#

Abstract Recording

Granthana Rangaswamy (Meta), Siamak Amiralizadeh (Meta), Xu Wang (Meta Platforms, Inc.)

• Why: The strongest quantified case at this conference for integrated optics over pluggables — real power and reach numbers from a platform moving from 51.2T validation into a 102.4T product, at the exact 200G/lane inflection point where pluggables struggle.
• What: A 1.5OU, 100% liquid-cooled, fanless blade with 64 optical ports via 16 four-port MMC interfaces and 16 ELSFP external-laser modules, delivering ~60% optics power reduction, ~30% system power reduction, and 500m reach versus pluggables (from abstract only).
• How: Optical engines placed on (CPO) or near (NPO) the ASIC substrate, eliminating pluggables; decoupling the laser lifecycle from the ASIC via ELSFP external lasers; fanless liquid cooling to reduce fiber contamination risk.
• Where applicable: Meta platform, but the power/reach trade-offs and the laser-decoupling architecture are broadly applicable to any operator weighing CPO/NPO at 102.4T; built on prior-generation 51.2T validation, so the numbers have production lineage.

Operating Linear Pluggable Optics at Hyperscale: From Link Management to Production Reliability#

Abstract Recording

Amin Yekani (Meta), Qing Wang (Meta)

• Why: LPO removes the DSP and shifts equalization to the host ASIC — an architecture any PM evaluating power-vs-reliability in optical links must judge. This is one of the few talks with fleet-scale production data rather than lab claims.
• What: Meta's operational experience with LPO across link management, link-health monitoring, and production results: a large-scale live-traffic deployment with tens of millions of accumulated link-hours, including failure-rate, signal-quality, power, and thermal measurements (from abstract only).
• How: Host- and module-side signal conditioning maintained fleet-wide (since no DSP auto-adapts), plus multi-layer monitoring covering signal quality, error metrics, and early detection of lane-level degradation.
• Where applicable: Explicitly framed as applicable to any DSP-free optical architecture; the operational framework (not just the modules) is the transferable artifact. Constrained by host-ASIC equalization capability — not a drop-in for any switch.

Lessons learned from GW-scale AI deployments#

Abstract Recording

Mark Filer (Oracle)

• Why: An end-user case study with production statistics on one of the world's largest 800G 2xDR4 LPO deployments — exactly the real-numbers, real-failure-mode content this PM values over vendor demos.
• What: Hard-won operational learnings from OCI's deployments supporting top AI customers at 10,000+ GPU scale, where single link flaps stall multi-million-dollar training jobs; includes production statistics on the LPO deployment and how the experience translates to 1.6T (from abstract only).
• How: Operational discipline at "laws of large numbers" scale — treating per-link instability as the primary availability adversary, with forward-looking paths to uptime/resilience in massive distributed systems.
• Where applicable: OCI-specific production data, but the failure-mode taxonomy and the 800G→1.6T extrapolation are relevant to any operator of GPU backbones; pairs naturally with the LPO talk above as the customer-side view.

Large-Scale Deployment of 800Gb/s Active Electrical Cables (AEC) in Meta Data Centers for AI Applications#

Abstract Recording

Jingyu Yu (Meta), Abhijit Chakravarty (Meta)

• Why: Cabling is a first-order cost/power lever in AI clusters and rarely gets a full methodology talk; this covers multi-vendor qualification to volume production, which is the hard part.
• What: Meta's qualification, validation, and deployment methodology for 800 Gb/s AECs (112 Gb/s/lane) in large-scale GPU clusters, spanning component characterization, environmental reliability, multi-vendor interoperability, system-level traffic validation, and manufacturing readiness across multiple suppliers and production sites (from abstract only).
• How: Lab plus in-cluster validation of link stability, packet integrity, latency, and firmware compatibility; the program resolved signal-integrity, manufacturing-consistency, and firmware-interoperability issues to reach multi-sourced volume adoption.
• Where applicable: Meta AI clusters but the qualification framework is general; AECs apply to short-reach in-cluster interconnect (rack-to-rack distances), as a power- and cost-efficient alternative to optics and passive DAC at 800G.

Srv6 powered backbone networks#

Abstract Recording

Jasmeet Bagga (Facebook), Andrey Golovanov (Meta)

• Why: Meta WAN/backbone architecture is squarely in the PM's DC/WAN-interconnect core interest, and this is an unusually internals-heavy talk: SRv6 for traffic engineering, shallow-buffer switches for long-haul, and real SAI/FBOSS experience.
• What: RBB (Regional Backbone), a newly designed inter-region connectivity network running in parallel to Meta's express backbone (EBB), motivated by the cost of replicating latency-sensitive core services into every region as region count grows (from abstract only).
• How: Traffic-engineered SRv6 over shallow-buffer switches for long-haul backbone links — a counterintuitive choice the talk explains — with SRv6 SAI support and deployment experience on FBOSS OCP switches.
• Where applicable: Meta-specific WAN, but the design pattern (parallel TE'd backbone with SRv6, shallow buffers for long-haul) and the SAI/SRv6 standardization feedback are broadly relevant to multi-region operators.

Traffic Engineering in AI DCI/WAN for AI Traffic#

Abstract Recording

Yuanchao SU (Alibaba Cloud), Clarence Filsfils (Cisco)

• Why: Geo-distributed AI training is now the driving WAN workload; this pairs the SRv6 inventor with a hyperscaler that has actually deployed it, covering both the problem framing and two real deployments.
• What: The traffic-engineering problem and requirements for AI DCI/WAN connecting geographically distributed training data centers — how it was solved for legacy non-AI traffic, why that solution falls short for synchronized, elephant-heavy AI flows, and the AI-specific solution including the data and telemetry collection needed to drive it (from abstract only).
• How: TE over the WAN for AI job traffic (presumably SRv6-based given the co-author); the abstract emphasizes required telemetry and two real deployment case studies rather than architecture alone.
• Where applicable: Alibaba Cloud production deployments — org-specific specifics expected; the requirement analysis (bursty synchronized traffic over constrained DCI) generalizes to any multi-DC training operator. Pairs with the scale-across panel below.

Beyond Traditional BGP: Decoupling Route Distribution for Large-Scale AI Clusters at Alibaba#

Abstract Recording

Eddie Ruan (Alibaba), Dennis Cai (Alibaba)

• Why: Directly in the PM's BGP/datapath-internals interest: a concrete alternative to Microsoft's Fairwater host-SRv6 approach for AI-cluster routing scale, from a provider that can't mandate host-side changes — a real architectural debate with numbers attached.
• What: An architectural decoupling of service route distribution from infrastructure route distribution: regular BGP continues to carry infrastructure routes within spine/leaf, while service routes are redistributed among leaf switches by multiple route reflectors, recursively resolved over the loopback of the anchoring leaf switch (from abstract only).
• How: A "Group RR" concept coordinates multiple RRs to provide Graceful Restart capability and high availability for critical service prefixes, so service routes survive RR cluster outages; positioned explicitly against Fairwater's <1,000-route / 256-way-ECMP host-SRv6 model from OCP 2025.
• Where applicable: Alibaba-specific architecture for multi-tenant clouds that cannot impose host changes — broadly applicable to any provider facing the same constraint; BGP-only, no host or silicon requirements.

Software-Assisted Congestion Signaling and Sub-Millisecond Telemetry in SONiC#

Abstract Recording

Arpitha Raghunandan (Google), Shane Gao (Google)

• Why: The deployable half of the Virgo story: how Google gets microsecond-scale telemetry and per-packet congestion signaling into SONiC — and, crucially, onto older ASICs that don't support it in hardware.
• What: A SONiC architecture proven at Google scale with two components: HST (High-Speed Switch Telemetry) — lightweight digests and high-resolution traces enabling microsecond-scale per-device profiling — and CSIG (Software-Assisted Congestion Signaling), which updates packet signals with real-time switch state to give end hosts high-frequency per-packet telemetry (from abstract only).
• How: Sub-millisecond runtime write-backs of per-port metrics via the HST framework, and reuse of unused match-action table resources in the ASIC pipeline to implement custom signal types the hardware doesn't natively support — enabling CSIG on existing networks with older silicon.
• Where applicable: Google-proven but designed for upstream SONiC; the "software-assisted on older ASICs" angle makes this broadly applicable to brownfield fabrics, not just new AI builds.

Open, Trusted, and Secure SONiC at Scale presented by Cisco#

Abstract Recording

Will Eatherton (Cisco), Dina Papagiannaki (Microsoft)

• Why: SONiC security posture is becoming an adoption gate as it moves into enterprise and AI infrastructure, and this lays out an end-to-end framework — FIPS, attestation, and eBPF-based live patching — that touches the PM's security and eBPF interests directly.
• What: An end-to-end SONiC security framework spanning supply-chain integrity, verified software authenticity, secure build pipelines, FIPS-ready hardware with a platform root of trust, confidential networking (protecting data and network state), and Day-2 monitoring with integrated CVE intelligence (from abstract only).
• How: eBPF-based runtime protections enable rapid mitigation and live patching without reboots — protect immediately, apply permanent patches in a planned window, revalidate; hardware/firmware/software integrity validated across the system lifecycle.
• Where applicable: General SONiC security architecture rather than a single deployment; note this is a vendor-led expo-hall session, so expect framework-level content without deployment metrics — the eBPF live-patch workflow is the concrete piece to take away.

An Introduction to Attesting Hitlessly Updatable Systems#

Abstract Recording

Matt King (NVIDIA)

• Why: A sharp conceptual contribution to the PM's identity/attestation interest: hitless firmware updates break the standard attestation model, because the platform can change between evidence production and relying-party use.
• What: An analysis of what attestation must become for platforms that update firmware while tenant workloads run: conventional measurements of the TCB that has run are insufficient; the relying party must also assess whether future updates could compromise the properties it depends on (from abstract only).
• How: Combine three evidence classes — current TCB measurements, the history of prior updates, and the policy governing future updates — so a relying party can make an informed decision about a system that changes while it runs.
• Where applicable: General technique for any attested platform doing hitless updates (switches, NICs, BMCs, accelerators); an introductory/conceptual talk, but it defines the problem shape the DMTF/OCP attestation work will have to address. Pairs with the SPDM provisioning talk below.

OCP Device Identity Provisioning over SPDM#

Abstract Recording

Fabrizio Damato (AMD), Xiaoyu Ruan (Intel)

• Why: Directly in the PM's workload-identity core interest at the hardware layer: operator/tenant-owned PKI enrollment for fleet devices, standardized over SPDM instead of per-vendor proprietary flows.
• What: The OCP Device Identity Provisioning specification: an Attested CSR that cryptographically binds a newly generated device keypair to the device's attested identity and measured state, plus a keypair-discovery flow so enrollment authorities can enumerate the identity keys a device exposes (from abstract only).
• How: Flows currently ride on SPDM vendor-defined messages for early deployment, while OCP drives the capability into DMTF SPDM (anticipated in SPDM 1.5); open-source RoTs such as Caliptra are expected to adopt it.
• Where applicable: Broadly applicable — this is a standardization talk, not an operator case study; the constraint is that full benefit requires RoT/BIOS support (Caliptra adoption is the open-source path) and SPDM-capable devices.

Adjacent#

Achieving AI Cluster Reliability at Scale: Lessons in Reducing Workload Interruptions#

Abstract Recording

Bob Wang (Meta), Ramachandra Reddy Kallam (Meta)

• Why: Not a networking talk per se, but network events are one of the correlated signals — and the root-cause methodology (attributing every interruption across host, firmware, network, and workload telemetry) is reusable by anyone operating large fabrics.
• What: A framework for diagnosing AI workload interruptions at 32K→100K+ GPU scale, built on root-cause classification via Perfetto time trees correlating host telemetry, firmware logs, network events, and workload signals; key contributors include NVLink failures, HBM fragmentation, thermal failures, silent data corruption (SDC), and firmware bugs (from abstract only).
• How: Data-driven root-cause analysis feeds back into next-gen hardware requirements, including vendor decisions on error reporting, fault isolation, and resilience; the diagnostic framework is being offered to the broader OCP community.
• Where applicable: Meta GBx00 clusters — org-specific failure data, but the methodology (correlated time-tree attribution) and the hardware-requirements feedback loop generalize well.

Wildcard#

From Fleet to Firmware: Bringing AI-Native Security to Open Hardware with Project Equilibrium presented by Google#

Abstract Recording

Andres Lagar-Cavilla (Google)

• Why: AI turned on the systems that run AI — a genuinely novel direction: autonomous, continuous security for open-source firmware that outpaces what periodic audits and static scanning can do as frontier models accelerate vulnerability discovery.
• What: Google's Project Equilibrium, an AI-native security architecture pairing live, repo-colocated threat models with autonomous pre-submit scanning and automated patching — catching deep bugs and cutting false positives before merge — plus a path to extend the workflow from fleets to bare-metal firmware via open security cookbooks (from abstract only).
• How: Threat models live next to the code they describe; autonomous pre-submit analysis and patching run against the millions of lines of low-level code in OpenBMC, Caliptra, CXL, and NVMe.
• Where applicable: Open-hardware ecosystem broadly (cookbooks are explicitly meant as a shared baseline); currently a Google internal capability being externalized, so treat maturity accordingly — but for anyone whose supply chain includes open firmware, this is where the field is heading.

Mitigating AI Training Power Oscillations: Utility Requirements and In-Rack Power Filtering#

Abstract Recording

Bo Wen (Microsoft), Xianyong Feng (Microsoft)

• Why: A surprising cross-domain result: synchronized GPU compute/communication phase transitions at cluster scale overlap with sensitive utility-grid frequency bands, creating forced-oscillation and impedance-stability risks — power design is becoming a networking-adjacent constraint on cluster architecture.
• What: A framework connecting grid-side power-transient requirements (power-change and oscillation limits, ramp-rate expectations, synchronized monitoring from utility interconnect down to rack level) with practical in-rack mitigation, including PSU + CBU filtering concepts, frequency-sweep test methods, attenuation analysis, and verification results (from abstract only).
• How: Rack-level buffering (PSU plus CBU) measurably reduces upstream power ripple; measurement and modeling align AI rack power design with utility requirements.
• Where applicable: Relevant to any operator at multi-hundred-MW AI scale interacting with utilities; Microsoft-specific verification data, but the utility constraints are universal for large campuses.

Clock-Aligned Telemetry for AI Clusters: From BMC to GPU to Fleet#

Abstract Recording

Ahmad Byagowi (TBD), Lukas Landgraf (turbalance)

• Why: The observability gap this addresses — many dashboards, no common evidence model — sits exactly at the junction of the PM's telemetry and Kubernetes/eBPF interests, and clock alignment as the basis for cross-machine trust is an idea worth stealing.
• What: A lab-built reference architecture for clock-aligned AI telemetry: a source-bundle contract, live agents, a conservative benchmark ladder, a Redfish/BMC lane, and a lakehouse path that preserves provenance and never synthesizes unsupported metrics; links DCGM/NVML, host counters, Prometheus, Kubernetes, Redfish, eBPF/OTel evidence, and PTP/NTP clock state (from abstract only).
• How: Per-datacenter ingestion without global shared state feeds one Iceberg layer over cold and fresh stores; a six-level benchmark ladder (metric to global baseline), auto-discovery, credential-gated agents, 1s freshness, and capability labels — PTP/NTP state as a first-class signal changes what cross-machine comparison can be trusted.
• Where applicable: Prototyped on a heterogeneous lab fleet (not hyperscale production yet), with an open-source repo and a proposed OCP collaboration path — early-stage, which is exactly why it's a wildcard rather than core.

Themes#

• Ethernet is eating the AI cluster bottom-up: with ESUN (operator requirements), SUE-T (memory-transaction transport), and Tahan (a real scale-up switch), open Ethernet now claims scale-up alongside scale-out — the last proprietary interconnect domain (in-rack XPU fabrics) is being standardized in the open, ratified in months with 170+ contributors.
• RoCEv2's successor wars have begun — in the open: MetaRoCE, OpenAI/Broadcom's MRC, Google's Falcon, and SUE-T are four open transport specs from hyperscalers in one cycle, all converging on multipath + receiver-driven/host-NIC intelligence and abandoning PFC-tuned losslessness as the model. Expect consolidation fights in 2026–27.
• The WAN is now part of the AI fabric: scale-across panels, Alibaba's AI DCI/WAN TE, and Meta's SRv6 RBB all treat inter-DC links as a continuation of the training fabric rather than classical DCI — coherent ZR/ZR+ pluggables, deep buffering, and TE for synchronized bursts are the new WAN requirements.
• Deterministic, microsecond-scale telemetry is the new control loop: HST/CSIG in SONiC, Clustermapper's SRv6 ground-truth probing, and clock-aligned evidence models share one thesis — statistical inference is being replaced by deterministic measurement as the basis for diagnosis and congestion control.
• SONiC is maturing on three axes at once: performance (6–12x route programming via ZMQ/tcmalloc, upstreamed), portability (software-assisted CSIG on older ASICs), and trustworthiness (FIPS, attestation, eBPF live patching) — it is consolidating its position as the open NOS for AI-era fabrics.
• The physical layer is being decided empirically: LPO fleet-hours, AEC multi-vendor production data, CPO power deltas, and Oracle's 800G→1.6T field experience mean optics and cabling choices are now driven by measured failure rates and power, not vendor spec sheets — and power oscillation constraints from utilities are becoming a cluster-architecture input.