Wiki source code of SRv6 Flexible Algorithm

Show last authors
1 (% class="row" %)
2 (((
3 (% class="col-xs-12 col-sm-7 test-report-content" %)
4 (((
5 ----
6
7 SRv6 Flexible Algorithm (Flex-Algo) allows operators to define custom routing paths based on classic constraints like link metrics and administrative groups and new constraints like minimum bandwidth, maximum delay, and reverse affinity. This feature optimizes path selection in light of different service requirements.
8 Our test verified Flex Algorithm over SRv6, using two key metrics: Delay metric (FA 128) and Traffic Engineering (TE) metric (FA 129). To measure link delay dynamically, certain nodes were equipped with TWAMP (Two-Way Active Measurement Protocol), while others relied on statically configured delay values.
9
10 During testing, we encountered cases where a node did not act as a TWAMP sender, but its connected peer was still able to respond to TWAMP probes, allowing for successful delay measurement. However, the response mechanism failed in other scenarios because some TWAMP receivers required a fixed source port for TWAMP responses, which is not RFC 5357 compliant and thus not always provided by RFC 5357 compliant TWAMP implementations at TWAMP sources.
11
12 Another issue observed was that some nodes failed to compute a route to a PE because the PE did not advertise its IPv6 neighbor address. In SRv6-based path calculation — including scenarios that use Flex-Algo — the Extended IS Reachability IPv6 Neighbor sub-TLV (#13), defined in RFC 6119, is mandatory to enable TE-based computations. Without this advertisement, nodes lack the necessary IPv6 neighbor information to establish a valid constraint-based path, leading to routing failures.
13 This requirement is particularly important in the context of Flex-Algo, which can be considered a distributed form of Traffic Engineering. As described in RFC 9350 (Section 1):
14 "It allows the operator to define constraint-based routing computations (using metrics and link attributes) without relying on complex, centralized Traffic Engineering controllers."
15 Therefore, although explicit SR policies or manual TE paths were not deployed, the use of Flex-Algo involves TE-like computations based on constraints and link attributes.
16
17 [[Figure 96: Flexible Algorithm over SRv6>>image:433995712301432833_Flex Algo over SRv6.png||alt="Figure 96" width="550"]]
18
19 **Channelized Sub-Interfaces Mapped to Flexible** **Algorithms**
20
21 Channelized sub-interfaces are logical segments created from a single physical interface, each assigned dedicated bandwidth and resource isolation. This configuration allows operators to build hard slices within the network, ensuring predictable traffic handling and strict service guarantees.
22 In this demonstration, channelized sub-interfaces were configured between two Huawei DUTs, each with a different bandwidth allocation — one sub-interface provisioned with higher bandwidth and another with lower bandwidth.
23 These sub-interfaces were then added into Flex-Algo topologies to validate the isolation and resource assurance mechanisms. Flex-Algo 128 was calculated based on the delay metric and mapped to the lower-bandwidth, low-delay sub-interface. Flex-Algo 129 was calculated using the TE metric and mapped to the higher-bandwidth sub-interface.
24 Congested traffic was introduced on the physical links between DUTs to test performance under stress. Traffic streams were sent over both algorithms, with multiple egress PEs involved. During the test, Flex-Algo 129 consistently delivered traffic without impact, demonstrating the guaranteed resource allocation. In contrast, traffic mapped to Flex-Algo 128 experienced congestion and packet loss as the streams exceeded the sub-interface’s lower bandwidth capacity.
25
26 [[Figure 97: Hard-slice interfaces with mapped flex algorithms over SRv6>>image:435010398518312961_Channalized Sub interfaces.png||alt="Figure 97" width="550"]]
27
28 {{container cssClass="tc-role-table"}}
29 (% class="table-bordered" %)
30 |=PE|=Traffic Generator
31 |(((
32 Ciena 5134,
33 Ciena 8140 Coherent Metro Router,
34 H3C CR16000-M1A,
35 H3C CR16003E-F,
36 Huawei ATN 910D-A,
37 Huawei NetEngine A821,
38 Juniper MX204,
39 Juniper MX304,
40 Juniper PTX10002-36QDD,
41 Keysight IxNetwork,
42 Nokia 7250 IXR-e2,
43 Nokia 7750 SR-1
44 )))|Keysight IxNetwork
45
46 Table 51: SRv6 Flexible Algorithm - µSID
47 {{/container}}
48
49 {{container cssClass="tc-role-table"}}
50 (% class="table-bordered" %)
51 |=PE|=Traffic Generator
52 |(((
53 Huawei ATN 910D-A,
54 Huawei NetEngine A821
55 )))|Keysight IxNetwork
56
57 Table 52: SRv6 Flexible Algorithm - µSID-Channelized Sub-Interface
58 {{/container}}
59 (% id="prev-next-links" %)
60 |[[< Previous>>doc:SRv6 Unreachable Prefix Announcement]]|[[Next ~>>>doc:Resource guarantee Slicing over Srv6]]
61 )))
62
63 (% class="col-xs-12 col-sm-5 test-report-sidebar" %)
64 (((
65 {{box}}
66 {{include reference="Main.Multi-Vendor MPLS & SDN Interoperability Test Report 2025.Sidebar Nav"/}}
67 {{/box}}
68 )))
69 )))