Skip to main content

SRv6 DCI Deployment: Three Inter-Domain Deployment Modes Explained

1. Solution Background and Challenges of Traditional DCI Architectures

Figure 1 - painpoint for vxlan and mpls
In traditional enterprise and cloud provider networks, the data center (DC) network, which typically uses a VXLAN overlay, and the external wide area network (WAN), which typically uses SR-MPLS or MPLS L3VPN, are built as separate technology domains. This fragmented architecture faces several technical challenges in the cloud-native and AI era:
  1. DCI Gateway Performance Bottlenecks and High Costs:
    • DCI gateways must perform complex bidirectional protocol translation between VXLAN and SR-MPLS/MPLS L3VPN.
    • DCI gateways must maintain VRF routing state for the entire network, creating scalability bottlenecks and potential single points of failure.
  2. Loss of Metadata and Tenant Context:
    • During protocol translation, security policy tags, network slicing identifiers, and QoS policies are difficult to map natively across domains.
  3. Rigid Service Function Chaining (SFC) Insertion:
    • Inserting security devices such as firewalls and IPS typically relies on complex Policy-Based Routing (PBR) or traffic steering through dedicated VRFs.
    • This often forces firewalls to be deployed at the network edge as large centralized firewall clusters, making multi-node state synchronization and horizontal scaling more difficult.
  4. Significant MTU Overhead:
    • VXLAN encapsulation adds 50 bytes of overhead from the outer IP, UDP, and VXLAN headers.
    • When combined with an outer MPLS label stack, this can easily lead to fragmentation or reduce the effective payload ratio.
To address these challenges, AsterNOS provides comprehensive support for SRv6 DCI inter-domain architectures across Option A, Option B, and Option C. This enables enterprises and service providers to build a resilient, strongly isolated, and high-performance cloud network infrastructure based on a unified IPv6 single-stack architecture.

2. In-Depth Analysis of Three SRv6 DCI Deployment Inter-Domain Mechanisms in AsterNOS

2.1 Option A: Hierarchical VRF Stitching and Service Termination (Segment-by-Segment VRF Stitching)

Core Concept

The ASBRs act as CEs to each other. Inter-domain VPN routes are converted into standard IPv4/IPv6 unicast routes and exchanged between the ASBRs.
The ASBRs in the two ASes are directly connected, and each ASBR also serves as a PE. Each ASBR treats the remote ASBR as its CE and uses a standard eBGP session to exchange IPv4/IPv6 unicast routes without VPN labels.
  • Advantages: Simple to implement. No complex inter-domain signaling extensions or tunnel stitching protocols are required between the two ASBRs. The autonomous systems remain fully decoupled.
  • Disadvantages: Limited scalability. ASBRs must maintain awareness of all tenant services and create a local VPN instance (VRF) for each inter-domain VPN. This results in a large forwarding table. In addition, dedicated physical interfaces or subinterfaces, such as VLAN-based interfaces, must be allocated between ASBRs for each VPN to provide traffic isolation. This places higher requirements on ASBR interface density and hardware capacity.
Figure 2 - SRv6 DCI Deployment Option A Segment-by-Segment VRF Stitching

Prerequisite: Locator Prefix Advertisement

Within each AS, the PE and ASBR devices must use an IGP, such as IS-IS or OSPFv3, to advertise their assigned SRv6 Locator prefixes to all underlying devices in the domain:
  • AS 1: ASBR 1 advertises its local Locator prefix, such as 200:1::/64, through the IGP to the P routers and PE 1 in the domain.
  • AS 2: PE 2 advertises its local Locator prefix, such as 400:1::/64, through the IGP to the P routers and ASBR 2.

Route Advertisement Process

The following example uses the advertisement of the CE 2 private route 2.2.2.2/32 to CE 1:
  1. CE 2 ➔ PE 2: CE 2 advertises its local private route 2.2.2.2/32 to PE 2 through BGP.
  2. PE 2 Processing and Advertisement: After learning the private route, PE 2 installs it in the routing table of local VPN instance A. PE 2 adds RD and RT attributes to the route and allocates an End.DT4 SID 400:1::1 from its local Locator. It then forms a VPNv4 route and advertises it to ASBR 2 through MP-iBGP.
  3. ASBR 2 Reception and Route Downgrade: ASBR 2 matches the Route Target (RT) and imports the route into the routing table of local VPN instance A. ASBR 2 then converts the route back to a standard IPv4 unicast route and advertises it to the remote “CE” (ASBR 1) through a standard eBGP session over the inter-domain interface.
  4. ASBR 1 Reception and Re-Labeling: ASBR 1 learns the IPv4 unicast route through the interface bound to VPN instance A and installs it in the routing table of local VPN instance A. ASBR 1 attaches its locally configured RD and RT attributes to the route and allocates a new End.DT4 SID 200:1::1 from its own Locator. It then generates a new VPNv4 route and advertises it to PE 1 through MP-iBGP.
  5. PE 1 Learning and Advertisement: After receiving the VPNv4 route, PE 1 matches the RT and imports the route into the routing table of local VPN instance A. It then converts the route into a standard IPv4 route and advertises it to CE 1.
  6. CE 1 Learning: CE 1 receives the route and installs it in its local IPv4 routing table.

Packet Forwarding Process

The following example shows traffic forwarding from CE 1 to 2.2.2.2:
  1. CE 1 ➔ PE 1: CE 1 sends a native IPv4 packet with destination address 2.2.2.2 to PE 1.
  2. Ingress Encapsulation on PE 1: PE 1 receives the packet through an interface bound to VPN instance A. It looks up 2.2.2.2 in the routing table of VPN instance A and matches the next hop associated with End.DT4 SID 200:1::1. PE 1 encapsulates the packet with an outer IPv6 header:
    • IPv6 Source Address (SA): The IPv6 address configured on PE 1.
    • IPv6 Destination Address (DA): 200:1::1, the End.DT4 SID allocated by ASBR 1.
  3. Forwarding Within AS 1: PE 1 performs a lookup for IPv6 DA 200:1::1 in the global IPv6 routing table and forwards the packet to ASBR 1 over the optimal IGP path within the AS 1 backbone.
  4. ASBR 1 Decapsulation and Inter-Domain Relay:
    • ASBR 1 receives the packet with IPv6 destination address 200:1::1 and matches the corresponding End.DT4 behavior in its local My-SID table.
    • ASBR 1 removes the outer IPv6 header, restores the original IPv4 packet, and performs a route lookup in local VPN instance A based on the SID mapping.
    • After matching the outgoing interface, ASBR 1 sends the packet to remote ASBR 2 through the physical interface/subinterface bound to VPN instance A as a bare IPv4 unicast packet with no tunnel encapsulation.
  5. ASBR 2 Reception and Re-Encapsulation:
    • ASBR 2 receives the bare IPv4 packet through the inter-domain interface bound to VPN instance A and performs a route lookup directly in local VPN instance A.
    • The lookup matches 2.2.2.2 and the associated next hop points to End.DT4 SID 400:1::1.
    • ASBR 2 encapsulates the packet with a new outer IPv6 header:
      • IPv6 Source Address (SA): The IPv6 address configured on ASBR 2.
      • IPv6 Destination Address (DA): 400:1::1, the End.DT4 SID allocated by PE 2.
  6. Forwarding Within AS 2: ASBR 2 performs a lookup for IPv6 DA 400:1::1 in the global IPv6 routing table and forwards the packet to PE 2 over the optimal IGP path within the AS 2 backbone.
  7. PE 2 Termination and Delivery: PE 2 receives the packet and matches End.DT4 SID 400:1::1 in its local My-SID table. It removes the outer IPv6 header and performs a route lookup for the exposed original IPv4 packet in VPN instance A. The packet is then forwarded to the destination CE 2.

2.2 Option B: Relay Lookup and SID Translation (Relay SID & Transit Rewrite)

Core Concept

  • Strict Underlay Isolation: The IGP within each AS advertises only the Locator prefixes of its own domain. Locator routes are never propagated across AS boundaries.
  • No User VRFs on ASBRs: ASBRs do not create any tenant-specific VRFs. They maintain only the global BGP VPNv4 routing table. The ASBRs establish a single-hop MP-eBGP session. While performing next-hop-self, each ASBR dynamically allocates an inter-domain relay SID based on its local Locator, using the End.T behavior to replace the SID in the original route.
  • Hop-by-Hop SID Swap: When an ASBR receives a packet, it does not decapsulate the inner IP packet. Instead, it performs a lookup in a dedicated BGP Transit table and rewrites (swaps) the outer IPv6 DA in place, allowing the packet to be relayed hop by hop across domains.
Figure 3 - SRv6 DCI Deployment Option B Relay SID & Transit Rewrite

Route Advertisement Process

The following example shows how the CE 2 private route 2.2.2.2/32 is advertised to CE 1:
  1. CE 2 ➔ PE 2: CE 2 advertises the private route 2.2.2.2/32 to PE 2.
  2. PE 2 Route Tagging and Advertisement: PE 2 installs the route in VPN instance A, adds RD/RT attributes, and allocates a service SID, End.DT4 400:1::1, on the local node. PE 2 then forms a VPNv4 route and advertises it to ASBR 2 through MP-iBGP.
  3. ASBR 2 Inter-Domain Redistribution and Advertisement:
    • ASBR 2 receives the VPNv4 route and installs it in the global BGP VPN table. The route is not imported into a user VRF.
    • ASBR 2 forwards the route to ASBR 1 through MP-eBGP. It sets the next hop to its directly connected local address and allocates a new relay SID, End.T 300:1::T2, from its local Locator (300:1::/64). This SID replaces the original 400:1::1.
  4. ASBR 1 Intra-Domain Redistribution and Advertisement:
    • ASBR 1 receives the VPNv4 route from ASBR 2 and installs it in the global BGP VPN table.
    • ASBR 1 forwards the route to PE 1 through MP-iBGP. It sets the next hop to its local address and allocates a new relay SID, End.T 200:1::T1, from its local Locator (200:1::/64). This SID replaces the original 300:1::T2.
  5. PE 1 Learning and Advertisement: PE 1 receives the VPNv4 route with ASBR 1 as the next hop and 200:1::T1 as the destination SID. Based on the RT, PE 1 imports the route into local VPN instance A and advertises it to CE 1 as a standard IPv4 route.
  6. CE 1 Learning: CE 1 learns the route to 2.2.2.2/32.

Packet Forwarding Process

The following example shows packet forwarding from CE 1 to 2.2.2.2:
  1. CE 1 ➔ PE 1: CE 1 sends a native IPv4 packet with destination address 2.2.2.2 to PE 1.
  2. Ingress Encapsulation on PE 1: PE 1 performs a lookup in the routing table of VPN instance A and matches the SID associated with the outgoing next hop: 200:1::T1. PE 1 encapsulates the packet with an outer IPv6 header:
    • IPv6 DA: 200:1::T1, the relay SID allocated by ASBR 1.
  3. Forwarding Within AS 1: P routers in AS 1 use the Locator prefix 200:1::/64 associated with the IPv6 DA and forward the packet to ASBR 1 along the shortest IGP path.
  4. ASBR 1 Lookup and First SID Swap:
    • The packet matches the End.T 200:1::T1 behavior in ASBR 1’s local My-SID table.
    • ASBR 1 does not remove the outer IPv6 header. Instead, it performs a lookup in the associated global BGP Transit table.
    • The lookup identifies ASBR 2 as the next hop, with 300:1::T2 as the outgoing SID.
    • ASBR 1 performs the SID swap by rewriting the IPv6 DA to 300:1::T2 and sends the packet to ASBR 2 over the inter-domain link.
  5. ASBR 2 Lookup and Second SID Swap:
    • The packet matches the End.T 300:1::T2 behavior in ASBR 2’s local My-SID table.
    • ASBR 2 performs a lookup in the BGP Transit table and identifies PE 2 as the next hop, with 400:1::1 as the outgoing SID.
    • ASBR 2 performs the SID swap by rewriting the IPv6 DA to 400:1::1 and forwards the packet into AS 2.
  6. Forwarding Within AS 2: P routers in AS 2 use the 400:1::/64 prefix to forward the packet to PE 2.
  7. PE 2 Termination and Delivery: PE 2 receives the packet with 400:1::1 as the outer DA and matches the local End.DT4 behavior. It removes the outer IPv6 header and exposes the original bare IPv4 packet sent by CE 1. PE 2 then performs a lookup in VPN instance A and forwards the packet to CE 2.

2.3 Option C: End-to-End Seamless SRv6 DCI Deployment

Deployment Model

PEs in different ASes establish multi-hop MP-eBGP sessions. Routes are advertised directly between the PEs through these sessions.
Figure 4 - SRv6 DCI Deployment Option C End-to-End Seamless SRv6

Core Concept

  • End-to-End Underlay Connectivity: Locator prefixes of all PEs are advertised across AS boundaries. As a result, all nodes in the network, including ASBRs and PEs, have native IPv6 routes to each other’s Locators.
  • End-to-End Control Plane: PEs establish multi-hop MP-eBGP sessions directly, or exchange routes through inter-domain route reflectors (RRs), to advertise VPNv4 routes end to end. ASBRs are completely unaware of VPN services. They do not create VRFs or allocate or replace SIDs, making them fully stateless.
  • Single-Pass Data-Plane Forwarding: The ingress PE encapsulates packets with the final service SID of the remote PE. The entire network performs hardware-based forwarding based on the outer IPv6 DA. No decapsulation or SID swap occurs along the path.

Prerequisite: Inter-Domain Locator Reachability

The following example shows how the Locator of PE 2 in AS 2 (400:1::/64) is advertised into AS 1:
  1. PE 2 ➔ ASBR 2: PE 2 advertises its local Locator prefix 400:1::/64 to ASBR 2 through the intra-domain IGP.
  2. ASBR 2 ➔ ASBR 1: ASBR 2 establishes a standard BGP IPv6 unicast session with ASBR 1 and advertises the 400:1::/64 route to ASBR 1.
  3. ASBR 1 ➔ PE 1: After learning the route, ASBR 1 advertises it to PE 1 through BGP IPv6 or redistributes it into the local IGP.
  4. PE 1 and ASBR 1 can now reach 400:1::/64 through native IPv6 routing, with the next hop pointing toward the appropriate path egress.

Route Advertisement Process

The following example shows how the CE 2 private route 2.2.2.2/32 is advertised to CE 1:
  1. CE 2 ➔ PE 2: CE 2 advertises the private route 2.2.2.2/32 to PE 2 through IGP or BGP.
  2. PE 2 Route Tagging and End-to-End Advertisement:
    • PE 2 learns the route and installs it in local VPN instance A.
    • PE 2 adds RD and RT attributes to the private route and allocates a local service SID, End.DT4 400:1::1, to form a VPNv4 route.
    • PE 2 sends the VPNv4 route directly to PE 1 through multi-hop MP-eBGP, or through an RR. The BGP next hop and End.DT4 SID remain unchanged end to end.
  3. PE 1 Learning and Advertisement:
    • PE 1 receives the VPNv4 route and imports it into local VPN instance A based on the RT.
    • PE 1 converts the route into a standard IPv4 route and advertises it to CE 1.
  4. CE 1 Learning: CE 1 learns the route to 2.2.2.2/32.

Packet Forwarding Process

The following example shows packet forwarding from CE 1 to 2.2.2.2:
  1. CE 1 ➔ PE 1: CE 1 sends a native IPv4 packet with destination address 2.2.2.2 to PE 1.
  2. Single-Pass Encapsulation on PE 1:
    • PE 1 performs a lookup in VPN instance A and matches the associated End.DT4 SID 400:1::1.
    • PE 1 encapsulates the packet with an outer IPv6 header:
      • IPv6 SA: The IPv6 address configured on PE 1.
      • IPv6 DA: 400:1::1, the service SID of the remote PE 2.
  3. Forwarding Within AS 1: PE 1 looks up 400:1::/64 in the global IPv6 routing table and forwards the packet toward ASBR 1 along the shortest path.
  4. Pure IPv6 Forwarding on ASBR 1:
    • ASBR 1 receives the packet and does not remove the outer IPv6 header, perform a VRF lookup, or rewrite the SID.
    • It performs a lookup only on the outer IPv6 DA in the IPv6 routing table and forwards the packet directly to ASBR 2 over the inter-domain link.
  5. Pure IPv6 Forwarding on ASBR 2:
    • ASBR 2 likewise operates as a pure IPv6 transit router.
    • It looks up the outer IPv6 DA and forwards the packet toward PE 2 along the shortest path within AS 2.
  6. PE 2 Termination and Delivery:
    • PE 2 receives the packet with 400:1::1 as the outer IPv6 DA and matches the local End.DT4 400:1::1 behavior.
    • PE 2 removes the outer IPv6 header and injects the exposed original IPv4 packet into VPN instance A for route lookup. It then forwards the packet to the destination CE 2.

3. Comparison Matrix and Selection Guide for the Three SRv6 DCI Deployment

3.1 Comparison of the Three SRv6 DCI Inter-Domain Modes

Evaluation DimensionOption A (Hierarchical VRF Stitching)Option B (SID Relay and Rewrite)Option C (End-to-End Seamless SRv6)
Control-Plane StateVery high: ASBRs must be aware of all tenants and maintain a separate VRF instance for each tenantModerate: ASBRs maintain a global BGP Transit table without maintaining tenant-specific VRFsNo service state: ASBRs run only native IPv6 unicast routing, while all VPN state resides on the PEs
Signaling Protocol InteractionASBRs act as CEs to each other and run standard eBGP over interfaces/subinterfacesASBRs establish single-hop MP-eBGP sessions and allocate and exchange End.T relay SIDsPEs establish end-to-end multi-hop MP-eBGP sessions, or use inter-domain RRs; ASBRs do not participate in VPN signaling
Underlay IsolationFull isolation: Locator routes from each AS never leave the local domainLogical isolation: only the ASBR Locator is exposed to the remote domain, while PE Locators remain hiddenFull connectivity: Locators of all PEs must be reachable through native IPv6 routing across the entire network
Data-Plane ForwardingDecapsulates to the bare IP packet at each domain boundary, performs a VRF lookup, and re-encapsulates the packet for the next domainPreserves the outer IPv6 header and rewrites the DA (SID Swap) based on a lookup at each domain boundaryNo decapsulation or header-field rewrite across the path; ASBRs perform LPM forwarding based only on the outer IPv6 DA
Packet Processing OverheadTwo decapsulation/encapsulation operations and multiple lookups at domain boundaries, resulting in the highest MTU overhead and latencyOnly performs in-place SID rewriting, with no decapsulation or re-encapsulation; lower latency and overheadSingle-pass encapsulation across the entire path with hardware-based line-rate lookups, resulting in the lowest forwarding latency
End-to-End SFC / Network SlicingNot supported: inter-domain decapsulation causes embedded slicing identifiers, service-chain information, and security tags to be lostSupported with limitations: requires boundary devices to remap and stitch policies across domainsNative support: the packet header can carry the complete Segment List, enabling end-to-end service chaining and network slicing
ASBR Hardware ConstraintsLimited by VRF instance scale, subinterface density, and multi-tenant route FIB capacityLimited by global BGP VPN route capacity and the size of the End.T SID mapping tableLimited primarily by the underlying Layer 3 IPv6 FIB capacity, without requiring high-end service-specific line cards

3.2 Inter-Domain Mode Selection Guide in AsterNOS

3.2.1 Prefer Option C: New Full-Stack IPv6 Data Centers, AI Clusters, and Latency-Sensitive Scenarios

  • Selection Rationale: Option C represents an end-to-end SRv6 inter-domain architecture. ASBRs operate as pure Layer 3 IPv6 routers, minimizing control-plane and data-plane processing overhead.
  • Typical Use Cases:
    • AI / LLM Compute Front-End Networks: Require deterministic interconnect latency at the nanosecond or microsecond level and avoid decapsulation or SID rewrite operations at DCI gateways.
    • Unified Network Operations: Inter-domain networks belong to the same organization or highly trusted entities that can accept end-to-end PE Locator reachability.
    • Agile Cloud-Native Traffic Engineering: Require end-to-end Service Function Chaining (SFC) and native network slicing across multiple data centers.

3.2.2 Prefer Option B: Inter-AS Connectivity, Large-Scale Public Clouds, and Neutral Multi-Tenant Backbones

  • Selection Rationale: Option B provides a balance between performance and isolation. It avoids the large-scale VRF resource requirements of Option A while avoiding the need to expose PE Locators across domains as required by Option C.
  • Typical Use Cases:
    • Multiple Network Operators: Data centers are managed by different teams or connected through a third-party provider backbone. Security and compliance requirements prohibit exposing internal PE topology.
    • Large-Scale Multi-Tenant Services: Tenant counts reach thousands or more, making it impractical for boundary gateways to allocate dedicated subinterfaces and independent VRF resources for every tenant.

3.2.3 Prefer Option A: Heterogeneous Network Migration, Small-Scale Existing DCI, and Strictly Isolated Dedicated Services

  • Selection Rationale: Option A has the most straightforward operational model. The two domains remain physically and logically decoupled in both the control and data planes, without requiring a unified architecture on the remote network.
  • Typical Use Cases:
    • Gradual Migration Across Vendors or Legacy Architectures: One side has migrated to AsterNOS SRv6, while the other side still uses a traditional Layer 3 or heterogeneous network. Traffic can be terminated at the gateway and delivered as native IP unicast.
    • Strict Isolation in Financial and Government Networks: Compliance requirements may require sensitive traffic tunnels to terminate at the autonomous system boundary, with the original plaintext packet restored for fine-grained interface-level security filtering.
    • Controlled Tenant Scale: The number of inter-domain VPN instances is typically limited to tens or hundreds, keeping ASBR resource usage within hardware limits.

4. Typical Industry Applications and Deployment Examples

4.1 Alibaba eCore: An Option A-Style Inter-Domain Architecture

Figure 5 - Alibaba eCore option A SRv6 DCI Deployment
Two Decapsulation and Lookup Operations in the Data Plane (Bidirectional End.DT46):
  • UNI-Side Access: Hosts connect to eSR through an IPinIPv6 access tunnel using endpoint-network coordination. The packet destination matches the UNI-SID (End.DT46) allocated by eSR. The End.DT46 behavior removes the outer IPv6 header and sends the inner IPv4/IPv6 packet to the specified VRF for route lookup.
  • NNI-Side Encapsulation: After routing and SLA policy matching in the VRF, eSR encapsulates the traffic again with an outer SRv6 header. The destination SID is the remote eSR’s NNI-SID: End.DT46. The packet is then forwarded into the backbone.
  • Conclusion: This forwarding model—decapsulate into the local VRF → perform a local VRF lookup → re-encapsulate into a new tunnel for transmission—is characteristic of Option A’s segmented service termination and stitching model.
Independent Service State Maintained at the Gateway (Virtual Node – VRF):
  • eSR does not simply maintain a global Transit table as in Option B, nor is it completely service-unaware as in a pure Option C architecture.
  • Instead, eSR instantiates multiple Virtual Node – VRF (Tenant + SLA based) instances and maintains independent forwarding entries at the edge based on tenant and SLA slices.
Strict Tunnel Segmentation and Isolation:
  • The DC compute side uses a lightweight IPinIPv6 access tunnel.
  • The WAN side uses an SRv6 VPN Overlay Tunnel.
  • The two tunnels do not extend across each other. They are logically stitched within eSR through VRF instances.

4.2 Nebius: An Option C-Style Inter-Domain Architecture

Figure 6 - Nebius option C SRv6 DCI Deployment
Control Plane: End-to-End Inter-Domain Connectivity Between PEs
  • Direct BGP VPNv4 Connectivity Across Domains: A BGP VPNv4 session is established directly between the DC gateway CGW (DC PE) and the WAN border router BR (WAN PE).
  • End-to-End Preservation of Route Attributes:
    • Routes advertised by BR to CGW, with next hop NH=fc00:0:6::1 and SID=fc00:0:6:e000::, are propagated without modification.
    • Routes advertised by CGW to BR, with next hop NH=fc00:0:1::1 and SID=fc00:0:1:e001::, are likewise preserved end to end.
  • No Service State on Transit Devices: The intermediate DCI, Leaf, Spine, and P routers do not participate in BGP VPN route exchange. They maintain no tenant VRFs and perform no SID translation.
Underlay Foundation: End-to-End Locator Reachability
    • Locator Advertisement: The CGW side advertises fc00:0:1::/48 into the network, while the BR side advertises fc00:0:6::/48 across the inter-domain network.
    • All nodes in the network, including DC devices, DCI devices, and WAN P routers, only need to maintain native IPv6 unicast routing in the underlay. The key requirement is end-to-end reachability to the Locator prefixes of both PEs.

    Data Plane: Single-Pass Forwarding with the DCI Performing Pure Hardware LPM Forwarding

      • Single-Pass Ingress Encapsulation: When a VM accesses an external network, the CGW performs a lookup in local vrf BLUE, matches the BR-assigned SID fc00:0:6:e000::, and directly encapsulates the packet with an outer IPv6 header.
      • No Decapsulation or Rewriting Along the Path: As the packet traverses Leaf ➔ Spine ➔ Leaf ➔ DCI ➔ P, intermediate devices perform only longest-prefix matching (LPM) on the outer IPv6 DA and forward the packet as a standard IPv6 packet. No decapsulation or re-encapsulation occurs.
      • Single Termination at the Destination: The packet reaches BR with its original encapsulation intact, matches the uDT4 SID (e000) in the local My-SID table, and BR removes the outer IPv6 header. It then performs an inner IPv4 route lookup and forwards the packet to the ISP.

      5. DCI Differentiated Services and Traffic Engineering

      5.1 Entropy Injection and Line-Rate Multipath Load Balancing

      • Eliminating Hash Polarization: Cross-DC encapsulation can make outer IP addresses highly similar, which may cause uneven backbone link utilization. The ingress PE extracts the inner packet’s five-tuple, calculates a 20-bit hash value, and injects it directly into the Flow Label field of the outer IPv6 header.
      • Stateless ECMP in the Transit Network: Transit/P nodes do not need deep packet inspection or SRH traversal. They can perform per-flow load balancing based only on {IPv6 SA, IPv6 DA, Flow Label}. This provides high-entropy hashing, prevents packet reordering, and maintains line-rate forwarding.

      5.2 SLA-Driven SRv6 TE Policy and Path Orchestration

      • Three-Tuple Identification and Weighted Path Sharing: A policy is uniquely identified by {Headend, Color, Endpoint}. A single Policy can maintain multiple Candidate Paths with different priorities and weighted Segment Lists. This enables dynamic ECMP/UCMP traffic distribution across optimal physical paths.
      • Distributed Path Computation with Flex-Algo: IGP Flex-Algo divides the logical topology into routing slices. Combined with link affinity attributes, available bandwidth, and measured delay metrics, it automatically computes optimal loop-free explicit paths that meet specific SLA requirements.
      • Automatic Traffic Steering and BSID Stitching: Overlay service routes are automatically associated with the corresponding Policy based on the BGP Color attribute. At inter-domain or aggregation boundaries, a Binding SID (BSID) can expand the downstream sub-paths on demand. This avoids pushing excessively long Segment Lists at the ingress and reduces header overhead and MTU tax.

      5.3 Cross-Domain High Availability (HA) and Self-Healing

      • Millisecond-Level Local Protection with TI-LFA: Backup Segment Lists are precomputed and include PQ node SIDs. When a link fails, the hardware triggers local fast reroute directly, enabling <50ms protection. If an intermediate node fails, the packet automatically advances the SID pointer and bypasses the failed node.
      • End-to-End Hot Standby and Fallback Protection:
        • Hot-Standby / VPN FRR: Primary and backup Candidate Paths are pre-installed in the FIB. Combined with BFD detection, this enables millisecond-level end-to-end failover.
        • BE Fallback: If all constrained explicit Candidate Paths become unavailable, traffic smoothly falls back to SRv6 BE forwarding based on global IGP shortest paths. This preserves basic connectivity for cross-domain services.

      6. Evolution Roadmap

      With full-stack support for Option A, Option B, and Option C, AsterNOS enables customers to avoid being locked into a single architecture:
      1. Short Term (Existing-Network Modernization / Strict Isolation): Adopt Option A / Option B to protect existing network investments while providing inter-domain route hiding and security boundaries.
      2. Long Term (Cloud-Native / IPv6-Only): As the WAN evolves, transition seamlessly to Option C (uSID / gSID) to benefit from end-to-end stateless forwarding, lower MTU overhead, and unified BGP-SRv6 automation.

      7. References

      1. SRv6 Converged DC Frontend and WAN
      2. SRv6 End-to-End DC Frontend and WAN
      3. SRv6-based Adaptive Load Balancing for AI DCI
      4. SRv6 uSID DC Frontend to Peering
      5. Cisco. SRv6
      6. Lead operators present at the SRv6 workshop
      7. Advanced Innovations in SRv6 uSID and IP Measurements

      Ready to Implement?

      Explore our detailed implementation guides to turn these white paper insights into real-world networking solutions. From RoCE to Zero-Touch Provisioning, we’ve got you covered.

      Explore Configuration Guides