Segment Routing - SRv6

1

(% class="row" %)

2

(((

3

(% class="col-xs-12 col-sm-8 test-report-content" %)

(((

----

The rapid expansion of AI workloads is transforming the AI ecosystem, including backend networks, data center interconnects, and service provider transport infrastructures. Currently, this traffic spans multiple network layers, each with distinct performance and reliability requirements. The increasing volume and diversity of such traffic show that no single networking approach addresses all operational requirements. In this context, SRv6 provides explicit mechanisms for traffic steering and forwarding control that can be applied where traditional approaches are insufficient.

8

9

SRv6 interoperability testing is conducted annually to validate multi-vendor support and consistent behavior of SRv6 features across different implementations. This recurring testing also provides regression coverage by comparing results with previous test iterations, and we have already observed real maturity on several levels.

10

11

The testing scope includes standard SRv6-based VPN services such as L3VPN, EVPN ELAN single-homing and multi-homing, and EVPN RT5. Resiliency and convergence mechanisms, including UPA, PIC, and S-BFD, were evaluated alongside routing and scalability functions such as Global Routing Table operation, route summarization, and Flex Algorithm. Traffic engineering capabilities were also used to validate constrained and optimized forwarding behavior.

12

The test setup used a dual-ring topology with multiple IS-IS levels, enabling validation of SRv6 behavior across hierarchical routing domains and a range of realistic failure and convergence scenarios. The topology was deployed as an IPv6-only environment, with no IPv4 connectivity present, ensuring that all control-plane and data-plane operations relied exclusively on IPv6.

13

For SRv6 addressing, this year’s testing followed operational guidance from the IETF SRv6 addressing draft draft-horn-srv6ops-srv6addressing. We used a dedicated SRv6 SID address block (5f00::/48), which provided a distinct and easily identifiable address space for SRv6 locators and SIDs and avoided overlap with general IPv6 infrastructure prefixes. Node loopback addresses were assigned from the same locator space, allowing reachability to the node and its SRv6 SIDs to be covered by a single prefix advertisement. This simplified IGP flooding and enabled locator-based hierarchy and summarization at routing-domain boundaries.

14

Link-local addressing was used for point-to-point adjacencies to prevent infrastructure link prefixes from being advertised in the IGP, reducing routing state. This approach was adopted by the majority of participating vendors, including Arista, Cisco, Ericsson, HPE, Keysight, Nokia, Raisecom, and ZTE, reflecting a common implementation choice in IPv6-only deployments. Together, these design decisions supported hierarchical and summarizable locator allocation while limiting the number of globally advertised prefixes.

15

The topology operated within a single autonomous system and included three Route Reflectors (RRs). Each RR establishes iBGP sessions with the PE routers, while a full-mesh iBGP peering is maintained among the RRs to ensure consistent route propagation. In addition, multiple Area Border Routers (ABRs) are deployed to handle route leaking and redistribution between the different IS-IS levels

16

17

[[~[~[Figure 79:SRv6 General Topology~>~>image:486179564590137345_SRv6 General Topology.png~|~|alt="Figure 79"~]~]>>attach:486179564590137345_SRv6 General Topology.png||target="_blank"]]

18

19

The following test cases have been executed for this test area:

(% id="prev-next-links" %)

26

|[[< Previous>>doc:Main.EANTC Transport & Cloud Networks Interop Test Report 2026.SR-MPLS.TI-LFA with IPv6 SRLG]]|[[Next ~>>>doc:L3VPN over SRv6]]