Token-Native Scale-Across Networking: Alibaba's SRv6 Architecture

Token-Native Scale-Across Networking: Alibaba’s SRv6 Architecture

The 2026 Open Compute Project (OCP) Global Summit placed Segment Routing over IPv6 (SRv6) at the center of discussions about next-generation AI networking. Multiple networking sessions explored its application to backbone optimization, AI cluster scale-out, scale-up, and scale-across architectures, reflecting the growing importance of programmable forwarding in large-scale AI infrastructure.

One of the most significant presentations, Traffic Engineering in AI DCI/WAN for AI Traffic, brought together Cisco Fellow Clarence Filsfils, a leading figure in Segment Routing, and Alibaba Cloud’s Yuanchao Su. The session examined how SRv6 can extend traffic engineering from individual data center fabrics across the data center interconnect (DCI) and wide area network (WAN), with Alibaba presenting its production-oriented approach to token-native scale-across networking.

The underlying challenge is straightforward: AI infrastructure is running into constraints that cannot be solved by adding more switches or increasing bandwidth within a single facility.

Power availability limits the size of individual clusters. AI training and inference workloads increasingly span geographically distributed compute pools. Meanwhile, inter-region fiber capacity remains scarce, network topologies are asymmetric, and latency requirements can be highly sensitive to path selection.

Alibaba’s architectural response is to establish a dedicated AI eCore WAN and use SRv6 traffic engineering to make the AI job—not merely the packet flow or destination prefix—the primary unit of network scheduling.

This approach represents a broader shift toward token-native networking, in which network policies are aligned with workload requirements such as time to first token (TTFT), time per output token (TPOT), and tokens per second (TPS).

The network becomes more than a transport layer connecting compute resources. It becomes an active participant in delivering predictable AI workload performance.

🌐 1. Why Scale-Out Is No Longer Enough

#

1.1 Power constraints force AI clusters across facilities

#

AI infrastructure continues to scale, but an individual data center or availability zone has finite electrical and cooling capacity.

As a cluster approaches these limits, adding more accelerators to the same facility becomes increasingly difficult. Expanding compute capacity may require deploying additional clusters in other campuses, availability zones, or geographic regions.

This changes the networking problem fundamentally.

Traditional scale-out connects more servers and accelerators within a relatively controlled data center fabric. Scale-across connects multiple independently located clusters over a regional or metropolitan network, potentially spanning multiple administrative and transport domains.

The distinction is not simply the number of GPUs involved. It is the transition from a relatively regular, high-bandwidth fabric to a network constrained by physical distance, existing infrastructure, and uneven link capacity.

1.2 AI workloads increasingly span multiple clusters

#

Scale-across would be less important if every AI workload could remain entirely within one cluster. In practice, modern training and inference architectures increasingly depend on distributed resource pools.

Several examples illustrate the problem:

• Prefill-decode disaggregation: Prompt processing and token generation can run on different compute pools, requiring communication between geographically distributed inference components.
• KV-cache pooling: Sharing or accessing key-value cache resources across compute pools introduces additional data movement and latency requirements.
• Distributed training: Cross-cluster parallelism can require sustained communication between accelerators that participate in the same training job.
• Disaster recovery and workload migration: Critical services may need to move or recover across different locations while preserving acceptable performance and availability.

These patterns make network behavior directly relevant to application performance.

A network path that works well for ordinary cloud traffic may not meet the requirements of a latency-sensitive inference workflow or a tightly synchronized distributed training job.

When workloads span clusters, the network must coordinate those clusters as part of the same logical computing environment.

1.3 Three constraints distinguish scale-across from scale-out

#

The OCP presentation emphasized three characteristics of AI DCI/WAN infrastructure.

Asymmetric topology. A data center scale-out fabric often follows a carefully engineered Clos topology with substantial path symmetry. A regional WAN inherits the shape of existing fiber routes, optical equipment, data center locations, and historical infrastructure investments.

The resulting topology is irregular. Different sites may have different numbers of available paths, different link capacities, and different latency characteristics.

Scarce bandwidth. Within a campus, operators can deploy large numbers of 400G or 800G connections using short-reach optical technologies. Long-haul wavelengths are substantially more constrained by physical infrastructure, optical transmission requirements, and cost.

Consequently, WAN bandwidth must be treated as a valuable resource that requires deliberate allocation rather than an effectively interchangeable pool of links.

Strict latency requirements. Distributed training collectives and inference workflows can be sensitive to round-trip time (RTT), jitter, packet loss, and path asymmetry.

Choosing a path solely because it has the correct destination may not be sufficient. Two routes to the same remote cluster can produce significantly different application behavior.

These constraints lead to a central conclusion: scale-across requires explicit traffic engineering rather than relying on ECMP alone.

Equal-Cost Multi-Path (ECMP) remains useful for distributing traffic over eligible paths, but its hash-based decisions do not necessarily align with job-level latency targets, available WAN capacity, or the specific communication patterns of AI workloads.

The objective is to make path selection reflect the requirements of the workload rather than leave critical AI performance to the distribution of individual flows.

🧩 2. Alibaba’s Architecture: Dedicated eCore WAN for AI

#

2.1 Start with what tokens require

#

Alibaba’s approach begins with AI application requirements rather than network topology.

For inference workloads, the network must support the performance and cost characteristics that determine how quickly users receive results and how efficiently the infrastructure can serve requests.

Three commonly used metrics are especially relevant:

• TTFT (Time to First Token): The time between submitting a prompt and receiving the first generated token.
• TPOT (Time Per Output Token): The average time required to generate each subsequent output token.
• TPS (Tokens Per Second): Token-generation throughput, which can describe individual-request speed or aggregate service throughput depending on the measurement methodology.

These metrics are influenced by compute scheduling, model architecture, memory access, batching, and network communication.

Network engineering cannot independently guarantee a particular TTFT or TPOT, but it can reduce avoidable transport latency, congestion, and path instability that contribute to the overall result.

From this perspective, token-native networking means aligning network scheduling and service guarantees with the requirements of AI jobs.

Alibaba’s design principles follow three directions:

1. Dedicated networking: Establish a purpose-built network for hyperscale AI traffic without importing unnecessary complexity from general-purpose cloud networking.
2. A simplified tenant and forwarding model: Use a common SONiC and SRv6 technology stack to reduce the number of distinct mechanisms required for network service delivery.
3. Model-infrastructure co-design: Use per-job traffic engineering to provide predictable network behavior, with the optical layer contributing failure detection and resilience.

These principles connect application-level performance requirements with concrete forwarding and transport decisions.

2.2 Multiple dedicated eCores, one technical stack

#

Alibaba’s WAN architecture is not a single network shared indiscriminately by every service. It comprises multiple dedicated eCore networks that reuse a common architectural and operational foundation.

The presentation described several network domains:

• eCore for AI, targeting scale-across workloads.
• eCore for Peering.
• eCore for Alibaba Group services.
• eCore for Finance.
• eCore for Public Cloud.

These networks share engineering methods and a common technical stack while maintaining distinct service and operational boundaries.

The benefit is that infrastructure can evolve without requiring every network domain to adopt identical policies, failure characteristics, or change schedules.

Public cloud networking prioritizes generality, service diversity, and broad customer requirements. AI scale-across networking instead prioritizes tightly controlled traffic patterns, predictable performance, and rapid iteration around specific workload needs.

Combining them indiscriminately can create competing optimization objectives.

A dedicated AI eCore allows the network team to develop workload-aware scheduling and resilience mechanisms without forcing the same policies onto unrelated services.

2.3 Containing failure domains through multi-domain architecture

#

The presentation also emphasized a multi-domain, multi-space, and multi-plane architecture designed to constrain the impact of individual failures.

A stated design objective was to keep the effective blast radius on the order of ten units, or roughly a dozen depending on how the fault domain is defined.

The purpose is not merely to reduce the probability of failure. It is to limit the scope over which a failure can disrupt traffic or require coordinated recovery.

For a large AI training system, this matters because a network incident can affect more than one application request. A failed communication path can stall synchronized computation, delay an entire training iteration, or reduce accelerator utilization across many servers.

Smaller failure domains make it easier to isolate incidents, execute recovery procedures, and prevent local problems from spreading across unrelated workloads.

The architectural lesson is that isolation and recoverability should be designed into the network topology rather than added only after failures occur.

2.4 A unified SONiC and SRv6 platform

#

Alibaba’s eCore architecture uses a common SONiC and SRv6 technology stack across its network domains.

The platform is designed to run on switch systems with different capacities, including 12.8T and 51.2T configurations, with 102.4T-class systems identified as a future progression in the supplied roadmap.

A unified software stack reduces the need to maintain separate implementations for every network domain. It can also improve operational consistency across configuration management, telemetry, forwarding policies, and failure handling.

SRv6 provides a programmable forwarding architecture based on IPv6 Segment Identifiers (SIDs), allowing ingress devices or controllers to associate traffic with explicit forwarding policies.

SONiC supplies the open network operating-system foundation through which supported routing and forwarding functions can be integrated into switch platforms.

The combination is especially valuable for scale-across because it extends familiar data center networking mechanisms into the DCI/WAN environment without requiring a completely separate control model for the regional network.

The objective is not to eliminate all differences between data center and WAN networking. It is to reuse a consistent engineering foundation while applying policies appropriate to each environment.

🏗️ 3. Scale-Across Topology: Fewer Layers, Larger Port Granularity

#

Alibaba’s topology design reuses concepts from its public cloud network while adapting them to the capacity and traffic characteristics of AI scale-across.

The objective is to preserve operational familiarity while simplifying the architecture and increasing the capacity of individual links.

3.1 Reusing the public cloud architecture

#

The presented comparison distinguishes a conventional public cloud topology from the scale-across design.

Here, EAR and CEAR refer to network roles used in the presented architecture. The precise expansion of these labels depends on Alibaba’s topology definitions.

The key architectural change is the collapsed core layer in the scale-across design.

Instead of introducing an entirely new topology, Alibaba reuses familiar tiering semantics and operational practices while reducing the number of layers required for the specialized network.

This provides several engineering advantages.

First, existing automation, troubleshooting procedures, and operational knowledge can be reused rather than rebuilt around a wholly different architecture.

Second, reducing the number of tiers can simplify path selection and network operations where the workload and topology permit it.

Third, a common architectural foundation makes it easier to develop consistent policies across data center and WAN environments.

3.2 Trading port count for larger bandwidth granularity

#

The port configurations illustrate another important design choice.

A switch using 128 × 400G ports provides:

A switch using 64 × 800G ports provides the same nominal aggregate port capacity:

The comparison highlights the difference between total switching capacity and individual-link granularity.

The 800G configuration achieves the same nominal aggregate bandwidth using half as many ports, with twice the bandwidth per port.

This can be attractive for AI traffic because a small number of large flows often dominate communication patterns. Larger links may provide greater capacity per path and reduce the number of physical connections required to carry a given aggregate load.

However, fewer ports do not automatically produce better hashing.

ECMP distribution still depends on the number of independent flows, hash entropy, flow size, traffic symmetry, and the mapping between flows and physical paths. A small number of elephant flows can remain difficult to distribute evenly even when link speeds increase.

The benefit of larger granularity therefore comes from a combination of factors: higher capacity per link, fewer physical connections, and a traffic-engineering strategy designed around the workload.

Alibaba’s approach is to combine these physical design choices with explicit per-job path selection, rather than assuming that port count or hash behavior alone will produce the desired distribution.

3.3 Designing the WAN for AI from the beginning

#

Traditional long-haul networks often contain a mixture of older and newer optical capacity. Large-scale AI scale-across introduces a more concentrated demand for high-capacity connectivity between selected sites.

The presented architecture favors 400G and 800G connectivity for its targeted AI transport paths instead of simply inheriting the lower-speed link profiles commonly found in older WAN installations.

This does not imply that every existing optical path can be upgraded immediately. Fiber availability, reach, optical margins, equipment constraints, and deployment cost remain important considerations.

It does, however, establish a clear design priority: allocate scarce high-capacity resources around the communication requirements of AI clusters.

🎯 4. Per-Job Traffic Engineering: Making the AI Job the Scheduling Unit

#

The most distinctive element of Alibaba’s scale-across architecture is its use of per-job traffic engineering.

Traditional network policies commonly classify traffic using addresses, ports, protocols, or other packet and flow attributes. Such mechanisms are effective for many services, but they do not necessarily capture the relationship between a network flow and the larger AI job it supports.

Alibaba’s approach moves the scheduling decision toward the workload itself.

4.1 Why schedule jobs instead of individual flows?

#

An AI job may produce many network flows between multiple endpoints. Those flows are not independent from the application’s perspective.

A distributed training job may require communication between multiple groups of accelerators. If one critical path becomes congested or fails, the resulting delay can affect the completion time of the entire iteration.

Likewise, a disaggregated inference job may involve communication between prefill workers, decode workers, and shared cache resources. The application cares about the end-to-end behavior of that inference workflow rather than the isolated performance of any one five-tuple.

Scheduling each flow independently can therefore miss the service-level objective that matters to the workload.

Per-job traffic engineering attempts to bridge this gap by identifying the job, associating it with an applicable network policy, and steering its traffic through a path designed to satisfy the job’s requirements.

The network’s service objective becomes more closely aligned with the upper-layer scheduler.

This is the essential idea behind token-native networking: network decisions are informed by the computational task that generates the traffic.

4.2 From the AI platform to the forwarding plane

#

The architecture described in the presentation uses a three-stage information chain.

Stage 1: Job information enters the network service platform.

The AI infrastructure service platform communicates job-related information, including the BTH-associated task identifier, to the network service platform.

The goal is to let the network associate a particular AI workload with a suitable forwarding policy.

Stage 2: The task identifier is carried in packet metadata.

The presentation describes using a reserved bit or field in the RDMA Base Transport Header (BTH) to convey task-identification information at the data plane.

The exact field usage is implementation-specific. BTH is part of the InfiniBand transport format used in RDMA environments, and using reserved fields for additional classification requires explicit coordination between the NIC, network devices, and supported protocol implementation.

Stage 3: Edge devices map the identifier to an SRv6 policy.

Scale-across edge devices identify the supported task metadata and steer the corresponding traffic through an associated SRv6 policy.

This creates a mapping between an application-level job and a network-level forwarding decision.

The result is the ability to create multiple logical traffic treatments over shared physical infrastructure without requiring each job to have an entirely separate physical network.

The policy can reflect factors such as available path capacity, latency requirements, and the intended isolation between workloads.

4.3 Logical slices with workload-specific behavior

#

The architecture’s logical slicing does not necessarily imply strict bandwidth reservation or hard isolation for every job.

Those properties depend on the specific enforcement mechanisms implemented by the network.

For example, associating traffic with different SRv6 policies can steer jobs along different paths. However, if those paths share a congested physical link, the mapping alone does not prevent contention.

Predictable performance therefore requires the complete system to account for link capacity, competing demand, path selection, failure behavior, and whatever scheduling or resource-control mechanisms the deployment supports.

The value of per-job traffic engineering is that it creates a clear place to connect these mechanisms to application intent.

Instead of optimizing forwarding independently of the AI scheduler, the system can treat job requirements as inputs to network policy.

🧭 5. SRv6 Control Plane: Translating Job Intent into Paths

#

After identifying the scheduling unit, the network needs a mechanism to distribute the relevant information and install the associated paths.

Alibaba’s approach uses SRv6 and BGP extensions to connect job-related metadata with forwarding policy.

5.1 Carrying job information through BGP

#

The presentation describes introducing a new BGP Network Layer Reachability Information (NLRI) format to carry the relevant BTH-associated information into the routing system.

Associated communities or other attributes can convey policy-related metadata, including a Binding SID (BSID) used to reference an SRv6 policy.

The purpose is to expose workload information to the network control plane in a structured manner.

The exact NLRI format and attribute encoding are implementation-specific extensions rather than generic properties of ordinary BGP operation. They require compatible implementations and a defined information model across the relevant network components.

Once the task information enters the control plane, the network can associate the job with the corresponding SRv6 policy.

5.2 Mapping BSIDs to SRv6 policies

#

A Binding SID provides an identifier for a policy or forwarding treatment.

Instead of requiring the job classifier to express a complete path on its own, the network can map the selected BSID to an installed SRv6 policy.

The supplied design describes a primary path represented by the SIDs <uA, uN>, together with a backup path using an eAR anycast GRT SID.

The SID notation and exact forwarding behavior depend on the deployment’s SRv6 implementation.

Conceptually, the primary path expresses the intended forwarding sequence, while the backup path provides an alternative that can be reached through an anycast routing identity.

This approach separates two responsibilities:

• Job classification: Determine which policy applies to the traffic.
• Path execution: Forward the traffic according to the policy and its available protection mechanisms.

Separating these functions makes it easier to evolve path selection without requiring the AI application to manage the details of every physical route.

5.3 Why an explicit policy is valuable

#

A policy reference lets the network change how a workload reaches its destination without changing the workload’s logical identity.

For example, a job can continue using the same policy identifier even when the network changes the underlying Segment List or selects a backup path.

This is a useful abstraction for large deployments because applications should not need to understand every router, link, or optical transport detail between clusters.

The network can expose a stable service interface while managing the physical implementation independently.

However, this abstraction depends on consistent policy distribution, correct SID installation, and reliable mapping between task identifiers and policies.

Errors in those mappings can lead to misclassification or unexpected traffic steering, so observability and validation remain essential.

🛡️ 6. Primary-Backup Paths: Containing Failures at the SID Layer

#

Per-job steering is only useful if the associated paths remain reliable.

Alibaba’s architecture combines a primary SRv6 path with fast detection and an anycast-based fallback to reduce the impact of network failures.

6.1 Fast detection using echo BFD

#

The primary path uses an echo Bidirectional Forwarding Detection (BFD) mechanism to detect connectivity degradation or failure quickly.

BFD is designed for rapid detection of forwarding-path problems. Its actual detection time depends on the configured intervals, multiplier, implementation, and conditions along the monitored path.

The presentation describes millisecond-scale failure detection as part of the design objective.

Rapid detection allows the network to respond before a fault produces prolonged disruption to an AI workload.

This matters particularly for synchronized training and latency-sensitive inference, where extended packet loss or path interruption can create delays beyond the affected link itself.

6.2 Anycast GRT SID as the backup

#

The backup path uses an eAR anycast GRT SID as the alternative forwarding target.

An anycast SID allows multiple eligible devices to advertise or support the same logical destination. The underlying routing system selects a reachable instance according to the configured routing behavior.

In this architecture, the anycast mechanism provides an alternative ingress or forwarding point without requiring the upper-layer job to understand the physical location of that point.

The intended behavior is to move traffic onto a viable path when the primary path becomes unavailable or degraded.

The backup path still depends on the availability of a functioning alternative route and correctly installed forwarding state. Anycast does not, by itself, guarantee capacity, latency, or loss-free recovery.

6.3 Isolating path failures from application logic

#

The design goal is to contain failures at the forwarding-policy or SID layer.

The AI job continues to use its logical network service while the infrastructure handles path changes underneath it.

This is an important separation of concerns.

The workload scheduler determines where computation should run. The network translates workload intent into forwarding policies. The SRv6 infrastructure and optical transport provide the actual connectivity and recovery mechanisms.

When this separation works correctly, an individual path failure does not necessarily require the AI application to be reconfigured or rescheduled.

Nevertheless, a stable logical service does not guarantee that the application will never observe the failure. Packet loss, congestion, recovery delay, and transport-level retransmissions can still affect performance.

The objective is to reduce the duration and scope of disruption while preserving a consistent policy interface for the workload.

🔦 7. Optical-Layer Resilience: Full Spectrum Transponder and LD/RD

#

SRv6 traffic engineering controls how packets traverse the IP network, but scale-across also depends on the optical transport underneath it.

When an optical link begins to degrade, the IP layer needs timely information to avoid sending latency-sensitive traffic through a path that is becoming unreliable.

Alibaba’s approach combines high-density optical transport with mechanisms for propagating link degradation across the optical and IP layers.

7.1 Full Spectrum Transponder: High-density optical transport

#

For large-scale cross-data-center connectivity, Alibaba developed a Full Spectrum Transponder (FST) approach.

The design objective is to simplify high-capacity optical deployment by concentrating multiple wavelengths within a compact chassis.

The supplied specification describes:

• A 2RU transponder chassis.
• Integration of 32 wavelengths.
• Up to 25.6 Tbps of aggregate capacity per chassis over a fiber pair.
• ELSFP pluggable external laser source modules.
• Eight fixed-wavelength distributed-feedback (DFB) lasers per source module, with internal wavelength multiplexing and demultiplexing.

The capacity follows from the aggregate of multiple wavelength channels. The precise per-channel rate, supported reach, and operating configuration depend on the actual optical implementation.

A denser transponder architecture can reduce front-panel cabling complexity and simplify installation at large scale.

This is particularly useful in AI DCI/WAN environments because deploying dozens or hundreds of high-capacity links creates significant operational overhead if every wavelength and optical connection must be managed independently.

However, higher optical density does not eliminate the need for careful engineering of optical margins, fiber characteristics, signal quality, and equipment compatibility.

7.2 LD/RD: Detecting degradation before complete failure

#

Traditional failure handling often reacts after a link becomes unavailable. AI workloads benefit from earlier detection because a degrading path can cause packet loss and retransmissions before it is formally declared down.

The LD/RD mechanism described in the presentation addresses this problem.

• LD (Local Degrade): Indicates that a local optical or transport component has detected degraded link conditions.
• RD (Remote Degrade): Communicates degradation information toward the remote side so that the condition can influence IP forwarding decisions.

One example is a transmission system or optical module detecting that pre-forward error correction (Pre-FEC) bit error rate has crossed a configured degradation threshold.

The optical layer can then communicate that condition to the IP layer.

When the implementation supports the relevant signaling and policy integration, the IP device can remove the degraded path from the eligible ECMP group or otherwise steer traffic away from it before the link experiences a complete outage.

This changes the failure response from reactive recovery to proactive avoidance.

The exact behavior depends on how degradation events are generated, propagated, correlated with physical paths, and consumed by routing or forwarding policy.

7.3 Coordinating optical and IP traffic engineering

#

The combined architecture creates a feedback loop across layers.

The optical layer monitors transmission quality and identifies deteriorating physical links. The IP layer receives that information and adjusts the set of paths eligible for traffic.

SRv6 policies then provide a means of directing traffic through an alternative route when the primary path is no longer appropriate.

For loss-sensitive RDMA workloads, this coordination can reduce the risk of sending traffic through a degraded link and help maintain more predictable communication behavior.

The key principle is that optical resilience and IP traffic engineering should not operate as independent mechanisms.

A physically impaired link can remain logically reachable for some time, so ordinary reachability alone may be insufficient to determine whether it is suitable for latency-sensitive AI traffic.

By incorporating transport-health information into forwarding decisions, the network can respond to degraded conditions before they become complete failures.

🔄 8. From Network-Centric to Token-Native Operations

#

Alibaba’s scale-across architecture represents a broader change in how AI infrastructure networks are designed and operated.

Traditional network control planes generally focus on reachability, topology, routing policy, and link state. Application scheduling systems separately decide where workloads should execute.

That separation remains useful, but it becomes increasingly limiting when distributed AI workloads require predictable performance across multiple regions.

Token-native networking introduces a more direct relationship between application intent and forwarding behavior.

8.1 Connecting network policy to AI service objectives

#

An inference platform may prioritize TTFT for interactive requests, while a batch workload may prioritize aggregate TPS. Distributed training may instead emphasize synchronized communication and the time required to complete each iteration.

Those objectives can lead to different choices of acceptable path latency, capacity, and resilience.

Per-job traffic engineering provides a mechanism for associating network policy with those differences.

It does not mean that the network can directly guarantee a model’s token-generation performance. Compute placement, accelerator utilization, batching, memory bandwidth, and model execution remain major contributors.

Rather, it provides a means of making network-related decisions consistent with the service objectives that the application actually cares about.

8.2 Model-infrastructure co-design

#

The architectural implication is that AI infrastructure and network infrastructure need to exchange more meaningful information.

An AI platform knows which jobs exist, which compute pools participate, and which service objectives matter. The network knows the available links, path characteristics, transport state, and forwarding options.

A workload-aware architecture connects these information domains so that the network can select a suitable forwarding treatment for each job.

The network remains responsible for packet delivery and path resilience, but its policies are no longer determined solely by generic routing metrics.

This is the essence of model-infrastructure co-design: application requirements influence infrastructure scheduling, while network capabilities constrain or enable the application-level design.

8.3 Why SRv6 fits this architecture

#

SRv6 provides a useful mechanism for expressing forwarding behavior through IPv6 SIDs and associating traffic with defined paths or service functions.

Combined with compatible control-plane extensions, it can provide a policy interface between job classification and path execution.

For example, a task identifier can be mapped to a policy reference, and that policy can select a primary path with an available backup.

This model supports separation between the job-level intent and the actual route through the network.

Its effectiveness still depends on reliable classification, consistent control-plane state, and coordination with physical transport and failure-detection mechanisms.

The architecture is therefore not simply an SRv6 deployment. It is a coordinated system in which workload metadata, network policy, packet forwarding, and optical resilience work together.

For broader background on SRv6-based AI networking and multipath transport, see KAD’s article, RFC 9800 Compressed SRv6: The Hidden Engine Behind AI Superclusters, which discusses how compressed Segment Routing can support large-scale AI communication architectures.

📐 9. Engineering Considerations and Limitations

#

Although token-native scale-across offers a compelling architectural model, its practical success depends on several engineering details.

9.1 Metadata must be trustworthy and consistently interpreted

#

Using a BTH-associated task identifier requires agreement among the AI platform, network service platform, NICs, and forwarding devices.

If the identifier is missing, incorrectly encoded, or interpreted differently by different components, traffic may be assigned to the wrong policy.

Reserved-field use must also be compatible with the actual protocol implementation. It should not be assumed that arbitrary hardware or generic RDMA software can support the mechanism without specific enablement.

9.2 Per-job traffic engineering does not automatically reserve bandwidth

#

Associating a job with an SRv6 policy makes traffic steering more explicit, but steering alone does not guarantee bandwidth.

If several jobs share the same constrained link, they can still compete unless the architecture provides suitable capacity planning, admission control, scheduling, or other resource-management mechanisms.

Predictable performance requires the control plane to consider the capacity and constraints of the available paths, not merely identify the desired destination.

9.3 Failure recovery must be validated end to end

#

A working BFD session and configured anycast backup are not sufficient to prove that the workload will recover within its performance target.

The complete system must be tested for:

• Detection of link and path degradation.
• Correct removal or avoidance of impaired paths.
• Availability of a usable backup path.
• Correct SRv6 policy and SID installation.
• Behavior under multiple simultaneous failures.
• Application-level effects, including packet loss, latency, and recovery time.

These tests should cover both complete link failures and degraded optical conditions, because the two events may trigger different recovery mechanisms.

9.4 Token-level objectives require application-level telemetry

#

TTFT, TPOT, and TPS are end-to-end metrics. The network cannot reliably optimize them using link utilization and packet loss alone.

Useful operations therefore require correlation between AI job identifiers, network policies, path-level telemetry, transport events, and application performance measurements.

Without such correlation, a network team may observe a healthy link while the application experiences poor latency for unrelated reasons—or may attempt to correct a network problem that actually originates in compute scheduling or memory access.

The broader operational challenge is to make workload and network telemetry comparable enough to support root-cause analysis and informed policy adjustments.

🌌 Conclusion: Building a Network That Understands AI Workloads

#

The 2026 OCP Global Summit highlighted SRv6 as an important tool for extending programmable forwarding across AI data center and WAN architectures.

Alibaba’s token-native scale-across design takes this concept further by connecting network traffic engineering with the jobs that generate the traffic.

A dedicated AI eCore provides separation from general-purpose cloud services. A simplified SONiC and SRv6 stack provides a common engineering foundation. Per-job traffic engineering maps workload metadata to forwarding policies, while primary-backup paths and optical-layer degradation signaling help maintain connectivity when transport conditions change.

The larger architectural shift is the move from device- and link-centric operations toward workload-aware networking.

In this model, the network does not merely forward packets toward a destination. It helps the AI infrastructure deliver an appropriate communication service for each job, within the capabilities and constraints of the underlying physical network.

That distinction becomes increasingly important as AI workloads span multiple data centers, inference architectures disaggregate compute stages, and large training jobs depend on sustained, predictable communication between distributed resources.

Token-native scale-across is not a replacement for sound routing, capacity planning, or transport engineering. It is a way to connect those disciplines to the performance objectives of AI applications.

The long-term direction is clear: networking will become an increasingly active participant in AI system design, with job intent, path selection, and physical-layer resilience coordinated as parts of a single infrastructure.