What is the primary advantage of SRv6 uSID over classic SRv6 SIDs?

SRv6 uSID (micro-SID) compresses multiple segment routing instructions into a single 128-bit IPv6 address. This significantly reduces the packet header overhead compared to classic SRv6, where each segment requires a full 128-bit IPv6 address. While the header with uSID is still larger than SR-MPLS, it makes SRv6 a more viable option for performance-sensitive deployments, especially where maximum segment lists are long.

How does Flex-Algo enable network slicing in Segment Routing?

Flexible Algorithms (Flex-Algo) allow the IGP (IS-IS or OSPF) to compute multiple, independent shortest-path topologies over the same physical infrastructure. Each algorithm can be configured with different constraints (e.g., include/exclude certain administrative groups, different metric types). This allows different services or 'slices' (e.g., low-latency for 5G URLLC vs. best-effort for eMBB) to follow distinct paths tailored to their requirements, all while sharing the same physical network.

What role does a PCE like Cisco Crosswork Network Controller play in SR-TE deployments?

A Path Computation Element (PCE) like Cisco Crosswork Network Controller (CNC) with Optimization Engine (OE) provides centralized, intelligent path computation for SR-TE policies. Instead of headend routers autonomously calculating paths, the PCE can compute optimal paths based on global network visibility and complex constraints (latency, bandwidth, SRLG, affinity). It then orchestrates these SR-TE policies to the headend routers via PCEP, simplifying traffic engineering management at scale and ensuring global optimization.

What are common pitfalls when migrating from RSVP-TE to SR-TE on IOS-XR?

Common pitfalls include insufficient testing of SR-TE policies before cutover, misconfiguration of BGP color communities leading to incorrect ODN steering, and ensuring all required attributes (e.g., admin-groups, SRLGs) are correctly translated and applied in the SR domain. A phased, dual-plane migration approach with extensive monitoring and validation is essential to prevent service disruption.

Can SR-MPLS and SRv6 uSID coexist in the same network?

Yes, SR-MPLS and SRv6 can coexist, either as entirely separate control and forwarding planes (dual-plane operation) or through various interworking mechanisms. For example, a single router can be configured for both SR-MPLS and SRv6, advertising SIDs for both. Interworking strategies like SR over MPLS (SRH encapsulation over MPLS), SRv6 over MPLS, or specific gateway functions can bridge the two domains, allowing for graceful migration or hybrid deployments.

How does TI-LFA provide sub-50ms protection in Segment Routing?

TI-LFA (Topology Independent Loop-Free Alternate) pre-computes backup paths for every potential link or node failure in the network. When a failure occurs, the router detecting the failure immediately switches traffic onto a pre-calculated repair segment list (or SRv6 SID list) without waiting for IGP convergence. This repair path is guaranteed to be loop-free relative to the post-failure topology, enabling rapid (sub-50ms) traffic restoration. BFD integration is critical for fast failure detection to trigger TI-LFA promptly.

Cisco IOS-XR Segment Routing Deep Dive: SR-MPLS, SRv6 uSID, SR-TE (2026)

The Cisco ASR 9000, NCS 5500, and 8000 series platforms, running IOS-XR, form the bedrock for most Tier-1 and Tier-2 service provider cores. While MPLS has been the dominant forwarding plane for decades, Segment Routing (SR) has matured into a viable and often superior alternative for traffic engineering, simplified operations, and new service delivery. This deep dive focuses on SR deployments on IOS-XR, dissecting both SR-MPLS and SRv6 with micro-SID (uSID) compression, alongside advanced features like SR-TE, Flexible Algorithms (Flex-Algo), and On-Demand Next-Hop (ODN). We will examine concrete configurations, deployment strategies, and crucial operational considerations that bridge the gap between architectural whitepapers and brownfield reality.

SR-MPLS Fundamentals on IOS-XR

SR-MPLS leverages the existing MPLS forwarding plane but decouples signaling from stateful protocols like RSVP-TE. Instead, it embeds forwarding instructions (segments) directly into the packet header. Each router advertises Segment IDs (SIDs) for its prefixes (Prefix-SIDs) and adjacencies (Adjacency-SIDs) via standard IGPs like IS-IS or OSPF. These SIDs are 20-bit MPLS labels. The global block for Prefix-SIDs, known as the SR Global Block (SRGB), must be consistent across the domain. On IOS-XR, the configuration is straightforward, typically enabled under the IGP instance. For greenfield deployments, ensuring a contiguous SRGB across all participating nodes simplifies label management significantly. Brownfield migrations from traditional MPLS or RSVP-TE often require careful planning around existing label space utilization to avoid conflicts.

During a network upgrade involving SR-MPLS, it's common to see a phased approach. Initially, SR is enabled on edge PEs and then extended to the core. A critical field observation is the importance of distributing the SRGB via BGP Link-State (BGP-LS) for multi-domain scenarios or for external path computation engines (PCEs). Without BGP-LS, external systems lack the necessary visibility into the SRGB and topology. Furthermore, the ip explicit-null option under IS-IS or OSPF is vital to avoid penultimate-hop popping (PHP) for Prefix-SIDs, ensuring the destination P node receives the correct service label stack. Failure to configure this can lead to traffic blackholing or incorrect label processing at the egress.


router isis CORE
 is-type level-2
 net 49.0001.0000.0000.0001.00
 address-family ipv4 unicast
  segment-routing mpls
  segment-routing mpls traffic-eng
  ! Enables SR-MPLS and SR-TE capabilities
  metric-style wide
  fast-reroute per-prefix level-2
  fast-reroute per-prefix level-2 ti-lfa
  ! TI-LFA protection enabled
 ! Sets Explicit Null for IP Prefix SIDs
 address-family ipv6 unicast
  segment-routing mpls
  segment-routing mpls ipv6-explicit-null
  metric-style wide
  fast-reroute per-prefix level-2 ti-lfa
 !
interface Loopback0
 address ipv4 10.0.0.1/32
 address ipv6 2001:db8::1/128
 ipv6 enable
 isis enable CORE
 isis circuit-type p2p
 isis passive
 segment-routing mpls
 ! Allocates an IPv4 Prefix SID
 segment-routing mpls prefix-sid index 1
 ! Allocates an IPv6 Prefix SID
 segment-routing mpls prefix-sid ipv6 index 1
!

SRv6 with Micro-SIDs (uSID) on IOS-XR

SRv6 is gaining traction, especially in 5G transport and enterprise data center interconnects, due to its native IPv6 forwarding plane and simplified extensibility. Instead of MPLS labels, SRv6 uses IPv6 addresses as SIDs. Each SID is a 128-bit IPv6 address, which can lead to larger packet headers. To mitigate this, Cisco IOS-XR implements Micro-SIDs (uSID), a compression scheme where multiple SIDs are encoded into a single 128-bit IPv6 address, effectively reducing the header overhead. A uSID is typically 16 bits, allowing for eight uSIDs per 128-bit IPv6 address. This optimizes header size, making SRv6 more palatable for high-scale forwarding. The core concept revolves around an SRv6 Locator block, which is a common IPv6 prefix assigned to a router from which all its SRv6 SIDs are derived.

The SRv6 architecture relies heavily on specific SID behaviors: End (routing to a node), End.X (routing to an adjacency), End.T (table lookup), End.DT4/DT6/DT46 (decapsulation to specific forwarding tables for VPN service chaining). For uSID, the critical aspect is how the local router parses the uSID arguments/blocks within the segment list. This allows a single 128-bit address to represent multiple forwarding instructions. Interoperability between different SRv6 implementations (e.g., standard 128-bit SIDs from other vendors vs. Cisco's uSID) requires careful consideration of SID encoding and processing capabilities. This is a common point of failure observed in multi-vendor SRv6 deployments, where disparate implementations of the same BCP can lead to blackholing. It's crucial to validate the SRv6 header processing path with traffic generators.


segment-routing
 srv6
  locators
   locator MAIN ipv6 2001:db8:c15c::/48
    algorithm 0
    ! Defines the main SRv6 locator block
    source-address 2001:db8::1
    ! Source address for SRv6 packets originating from this node
   !
  !
 !

router isis CORE
 is-type level-2
 net 49.0001.0000.0000.0001.00
 address-family ipv6 unicast
  segment-routing srv6
  segment-routing srv6 locator MAIN
  ! Advertises SRv6 capability with the defined locator
  metric-style wide
  fast-reroute per-prefix level-2 ti-lfa
 !
interface Loopback0
 address ipv4 10.0.0.1/32
 address ipv6 2001:db8::1/128
 ipv6 enable
 isis enable CORE
 isis passive
 segment-routing srv6 prefix-sid end index 1
 ! Allocates an SRv6 End SID for Loopback0
!
interface GigabitEthernet0/0/0/0
 address ipv4 10.0.1.1/24
 address ipv6 2001:db8:1::1/64
 ipv6 enable
 isis enable CORE
 isis network point-to-point
 segment-routing srv6 adjacency-sid end.x
 ! Allocates an SRv6 End.X SID for this adjacency
!

SR Traffic Engineering (SR-TE) Policies

SR-TE policies provide programmable control over traffic paths, replacing the complex mess of RSVP-TE LSP configurations. They can be defined as explicit segment lists for stringent path control or dynamically computed by a Path Computation Element (PCE) based on various constraints. IOS-XR supports both. The power of SR-TE policies lies in their ability to steer traffic based on application requirements (e.g., low-latency for 5G fronthaul, high-bandwidth for CDN traffic) without requiring per-flow state on transit routers. A key differentiator here is the `color` attribute, which allows a controller or BGP-LU to signal traffic that requires a specific SR-TE policy. This significantly simplifies L3VPN or EVPN service binding to engineered paths, as specified in RFC 9256 (for SR-MPLS) and RFC 9256bis (for SRv6).

Cisco Crosswork Network Controller (CNC) with its Optimization Engine (OE) serves as a robust PCE, providing centralized path computation and policy instantiation. The interaction mechanism uses PCEP (Path Computation Element Protocol). During a large-scale deployment, it's critical to validate PCEP session establishment and policy push from CNC to the XR headend routers. A common pitfall is misconfigured PCEP authentication or incorrect policy precedence, leading to policies not being activated or traffic flowing suboptimal paths. Monitoring show segment-routing traffic-eng policy and ensuring the operational state aligns with design intent is paramount. The binding-sid for SR-TE policies is also crucial for internal steering, allowing a top-of-stack label (for SR-MPLS) or a specific IPv6 address (for SRv6) to reference an entire SR-TE policy. This simplifies embedding complex policies into outer segment lists.


segment-routing
 traffic-eng
  policy DUAL-PATH-LOW-LATENCY
   color 100 endpoint ipv4 10.0.0.10
   source-address ipv4 10.0.0.1
   candidate-paths
    preference 200
     dynamic
      metric type latency
      pce
       stateful
       affinity
        include-all name GOLD
        exclude-any name RED
       !
     !
    preference 100
     explicit segment-list SEGMENTLIST-EXPLICIT
    !
   !
  !
  segment-list name SEGMENTLIST-EXPLICIT
   index 10 mpls label 16010
   index 20 mpls label 16020
   index 30 mpls label 16030
  !
 !

Flexible Algorithm (Flex-Algo) for Network Slicing

Flexible Algorithm (Flex-Algo), defined in RFC 9350, is a game-changer for network slicing and service differentiation in SR domains. It allows the IGP (IS-IS or OSPF) to compute multiple independent topologies (algorithms) over the same physical network. Each algorithm can use a different set of constraints (e.g., specific link affinities, metrics) to calculate shortest paths. For example, Algo 128 could be a low-latency path avoiding specific congested links, while Algo 0 (the default IGP shortest path) serves general-purpose traffic. This is critical for 5G xHaul transport, where network slices demand guaranteed latency or bandwidth for URLLC (Ultra-Reliable Low Latency Communications) traffic, separate from eMBB (enhanced Mobile Broadband) traffic.

Implementing Flex-Algo requires defining the algorithm under the IGP and then advertising per-prefix SIDs for each algorithm. The Prefix-SID for a specific algorithm is known as a Flex-Algo Prefix-SID. On IOS-XR, you define the algorithm and its constraints (e.g., `include-any`, `exclude-any` link attributes) under the IS-IS or OSPF instance. Then, you assign the Flex-Algo to interfaces or specific loopbacks. The complexity arises in managing link attributes consistently across a large network and ensuring that the desired algorithms are computed uniformly. Debugging scenarios where a specific Flex-Algo path is not computed as expected often boils down to misconfigured link attributes or incorrect algorithm definitions. The show isis segment-routing flex-algo detail command is your best friend here, providing per-node algorithm state and reasons for non-participation.


router isis CORE
 is-type level-2
 flex-algo 128
  metric-type igp
  exclude srlg
  ! Excludes links belonging to any SRLG defined, for path diversity
  include-any admin-group GOLD
  ! Includes links with GOLD admin-group for low-latency paths
 !
 address-family ipv4 unicast
  segment-routing mpls
  segment-routing mpls flex-algo 128
  ! Activates flex-algo 128 for SR-MPLS
  ...
 !
 interface GigabitEthernet0/0/0/0
  isis network point-to-point
  admin-group
   group GOLD
   group SILVER
  !
 !
interface Loopback0
 address ipv4 10.0.0.1/32
 address ipv6 2001:db8::1/128
 ipv6 enable
 isis enable CORE
 isis passive
 segment-routing mpls prefix-sid index 1
 segment-routing mpls flex-algo 128 prefix-sid index 12801
 ! Assigns a Flex-Algo 128 Prefix SID
!

On-Demand Next-Hop (ODN) for L3VPN/EVPN Auto-Steering

On-Demand Next-Hop (ODN) automates the steering of prefixes (e.g., L3VPN routes, EVPN Type 5 routes) over SR-TE policies. Instead of statically configuring each VPN route to use a specific SR-TE policy, ODN uses a local policy template that matches incoming BGP routes based on their color extended community. When a BGP route with a specific color is received, the headend PE automatically instantiates an SR-TE policy if one doesn't exist, using the remote PE as the endpoint and applying constraints defined in the ODN template. This is transformative for large-scale VPN deployments, dramatically reducing operational overhead associated with provisioning and managing hundreds or thousands of VPN services.

The interaction between BGP-LU (for advertising router loopbacks within the segment routing domain), BGP carrying VPN routes, and ODN is critical. Ensure BGP-LU is enabled and established to allow the SR-TE endpoint to be reachable via the SR domain. A common misconfiguration seen in production is a mismatch between the BGP color community advertised by the remote PE and the color configured in the ODN policy template on the local PE. This results in VPN traffic failing to steer over the intended SR-TE policy, often falling back to IGP best path, which may not meet service-level agreements. Verifying that the BGP routes are received with the correct color community (show bgp ipv4 mvpn all detail or show bgp vpnv4 all detail) and observing the instantiated SR-TE policies (show segment-routing traffic-eng policy) are essential troubleshooting steps.


segment-routing
 traffic-eng
  on-demand color-template
   color 100
    ! Template for color 100 services
    dynamic
     metric type latency
     pce
      stateful
      affinity
       include-all group GOLD
      !
    !
   !
  !
 !

router bgp 65000
 address-family ipv4 vpn
  retain route-target all
  ! Ensures all VPNv4 routes are retained
 !
 address-family vpnv4 unicast
  neighbor 10.0.0.2
   remote-as 65000
   update-source Loopback0
   address-family vpnv4 unicast
    send-community extended
    ! Essential for advertising color communities
    route-policy ODN-COLOR-MATCH out
   !
  !
 !

route-policy ODN-COLOR-MATCH
 set extcommunity color 100
 end-policy
!

TI-LFA Protection

Topology Independent Loop-Free Alternate (TI-LFA) provides sub-50ms protection for SR-MPLS and SRv6 paths, akin to MPLS Fast Reroute (FRR) but without per-LSP state. TI-LFA computes a pre-calculated backup path (a repair tunnel segment list) for every potential link or node failure in the network. When a failure occurs, the local router immediately switches traffic to the repair tunnel, ensuring rapid convergence. On IOS-XR, TI-LFA is enabled under the IGP with simple commands. The intelligence behind TI-LFA lies in its ability to compute paths that are guaranteed to be loop-free relative to the post-failure topology, using techniques like PQ-node and Q-space computation.

While generally robust, TI-LFA implementation on brownfield networks requires careful validation. Common issues include incorrect link failure detection, leading to delayed repair path activation or, in rare cases, micro-loops if the post-failure topology is not correctly modeled. Ensure that Bidirectional Forwarding Detection (BFD) is enabled on all links for rapid failure detection, which feeds into the IGP and subsequently triggers TI-LFA. Additionally, when using Flex-Algo, TI-LFA can compute repair paths individually for each algorithm, ensuring that service-specific path constraints are maintained even during failure. This feature is crucial for maintaining SLA guarantees during network events. Validating TI-LFA involves simulating link failures and measuring convergence times with traffic generators or network performance monitoring tools. A typical lab test involves injecting a full line-rate traffic flow and pulling a fiber to confirm protection works as expected on NCS 5500 with 100GE interfaces.


interface GigabitEthernet0/0/0/0
 description LINK_TO_PEER_A
 ...
 bfd fast-detect
 ! Strongly recommend for rapid failure detection in conjunction with TI-LFA
 isc-isis enable CORE
 isc-isis network point-to-point
!

router isis CORE
 ...
 address-family ipv4 unicast
  segment-routing mpls
  fast-reroute per-prefix level-2 ti-lfa
  ! Enables TI-LFA protection for IPv4 unicast traffic
 !
 address-family ipv6 unicast
  segment-routing srv6
  fast-reroute per-prefix level-2 ti-lfa
  ! Enables TI-LFA protection for IPv6 unicast traffic with SRv6
 !

SR-MPLS vs. SRv6 uSID: Design Choices

Choosing between SR-MPLS and SRv6 (especially with uSID) is a significant architectural decision for 2026 and beyond. SR-MPLS is more mature, enjoys broader vendor support for legacy integrations, and typically has a lower initial CPU/ASIC overhead due to the 20-bit label processing. It's often the preferred choice for organizations with existing MPLS deployments or those hesitant to fully transition to IPv6. However, SR-MPLS still relies on MPLS headers, which can sometimes be incompatible with certain cloud environments or restrictive firewalls that are strictly IPv6-only.

SRv6, especially with uSID, is fundamentally cleaner as it's purely IPv6-based, simplifying network architecture by eliminating the MPLS shim header. This aligns well with IPv6-only environments, cloud-native principles, and future service demands that increasingly leverage IPv6. The extensibility of SRv6 makes it highly flexible for new behaviors and service chaining. The main trade-off is header size (even with uSID, it's larger than SR-MPLS in simple cases) and potentially higher ASIC resource consumption on older platforms. For greenfield 5G transport, data center interconnects, or networks fully committed to IPv6, SRv6 uSID on platforms like the NCS 5500 or 8000 series offers a superior long-term strategy. For multi-domain interconnect, SRv6 simplifies inter-AS connectivity by removing the need for label translation often seen with MPLS backbones. Refer to /blog/cisco/iosxr-8000-series-platform-sizing/ for platform-specific hardware considerations.

SR-MPLS vs. SRv6 uSID Comparison for SP Core (2026)
Feature	SR-MPLS (IOS-XR)	SRv6 uSID (IOS-XR)	Considerations for 2026 SP Core
Forwarding Plane	MPLS (20-bit labels)	IPv6 (128-bit addresses, uSID compression 16-bit blocks)	SRv6 aligns with IPv6-only future. uSID mitigates header bloat but still larger than MPLS in simple cases.
Maturity & Deployment	High, widespread adoption, robust vendor support, easier brownfield migration from existing MPLS.	Medium-High, rapidly maturing, increasing adoption especially in greenfield and 5G.	SR-MPLS is safer for conservative upgrades; SRv6 for visionary greenfield or IPv6-centric domains.
Header Overhead	Lower (1-3 labels, 4-12 bytes)	Higher (1-2 IPv6 Extension Headers, 40-80 bytes typical for uSID segment list)	Header size matters for MTU, especially in datacenter or access networks. uSID significantly better than full 128-bit SIDs.
Multi-Domain Interop	Needs BGP-LU for SRGB, BGP-LS for PCE, complex inter-AS options (Option A/B/C).	Native IPv6 simplifies inter-domain routing; leverages BGP-LS for SRv6 SIDs; conceptually cleaner ASBR functions.	SRv6 has a clear advantage for large-scale multi-domain deployments.
Service Chaining	Possible with elaborate label stacks or service function chaining features.	Native to SRv6 with specific behaviors (End.S, End.PSP, End.DTx) for flexible service chaining.	SRv6 is superior for complex in-network service insertion and manipulation.
ASIC/HW Support	Well-supported on all modern Cisco XR platforms (ASR 9000, NCS 5500, NCS 8000).	Excellent on modern Cisco XR platforms (NCS 5500, NCS 8000), requires newer hardware for optimal performance.	Older ASR 9000 models might process SRv6 in software for some functions if not upgraded to newer line cards, impacting performance. Validate with `show platform`.

Migration from RSVP-TE to SR-TE

Many legacy service providers still rely heavily on RSVP-TE for path engineering. Migrating from RSVP-TE to SR-TE is a crucial brownfield scenario. The recommended strategy involves a dual-plane approach. First, enable SR-MPLS (or SRv6) alongside RSVP-TE. Then, establish SR-TE policies that mirror existing RSVP-TE LSPs. Once SR-TE policies are validated and operational, L3VPN/EVPN services or other traffic flows are slowly migrated from referencing RSVP-TE LSPs to referencing SR-TE policies (e.g., via BGP color communities and ODN). The final step is to decomission RSVP-TE. This phased approach minimizes service disruption.

A critical challenge during migration is ensuring the new SR-TE paths replicate the desired traffic engineering characteristics of the old RSVP-TE LSPs, especially for strict latency or bandwidth constraints. This often requires meticulous configuration of admin-groups/affinity bits and path computation metrics. Monitoring tools capable of visualizing both planes simultaneously (e.g., Cisco Crosswork) are invaluable. Neglecting to set up granular monitoring during a migration of this scale increases the risk of undetected path deviations and SLA violations. Field engineers have reported instances where RSVP-TE was prematurely disabled, leading to service outages because an equivalent SR-TE policy was either not active or incorrectly configured. Testing at pre-scheduled maintenance windows with actual customer traffic (even if minimal) before cutting over is non-negotiable.

Verifying SR Components on IOS-XR

Operational verification is key to a stable SR deployment. Here are essential `show` commands:


RP/0/RSP0/CPU0:PE1#show segment-routing mpls
RP/0/RSP0/CPU0:PE1#show segment-routing mpls forwarding
RP/0/RSP0/CPU0:PE1#show segment-routing mpls fib summary
RP/0/RSP0/CPU0:PE1#show segment-routing srv6 locators detail
RP/0/RSP0/CPU0:PE1#show segment-routing srv6 sid-table
RP/0/RSP0/CPU0:PE1#show segment-routing traffic-eng policy
RP/0/RSP0/CPU0:PE1#show segment-routing traffic-eng policy DUAL-PATH-LOW-LATENCY detail
RP/0/RSP0/CPU0:PE1#show segment-routing tunnel
RP/0/RSP0/CPU0:PE1#show isis segment-routing srv6 locators detail
RP/0/RSP0/CPU0:PE1#show isis segment-routing flex-algo detail
RP/0/RSP0/CPU0:PE1#show bgp ipv4 unicast labels
RP/0/RSP0/CPU0:PE1#show bgp vpnv4 unicast labels
RP/0/RSP0/CPU0:PE1#show mpls forwarding-table
RP/0/RSP0/CPU0:PE1#show ipv6 traffic-eng

These commands provide visibility into the SR control plane (IGP advertisements, BGP-LS), the SR forwarding plane (MPLS/SRv6 FIB entries), SR-TE policy states (active, preferred, policy ID, binding-SID), and TI-LFA protection status. In complex multi-domain SR deployments where BGP-LS and PCEP (to CNC) are used, validating the BGP-LS advertisement of SIDs and checking PCEP sessions and delegated LSPs is equally critical. For example, show pce peer and show pce lsp detail help confirm controller-initiated LSPs. For detailed troubleshooting of SRv6 uSID, capturing packets (e.g., with monitor traffic interface Gi0/0/0/0 link-type ethernet raw size 1500 match 'ipv6 and proto 41') and examining the SRH (Segment Routing Header) is often required to verify correct SID stacking and processing.

Verdict

For greenfield service provider cores or new 5G transport networks prioritizing IPv6 and future-proofing, SRv6 with uSID on Cisco NCS 5500 or 8000 series platforms is the architectural winner. The native IPv6 forwarding, simplified service chaining, and extensibility offer significant long-term advantages, albeit with careful initial planning around header overhead. For existing brownfield MPLS networks requiring a more conservative upgrade path or environments not yet ready for a full IPv6 transition, SR-MPLS remains the pragmatic choice. Its maturity, lower header overhead for simple cases, and broader legacy interoperability minimize migration risk while still delivering advanced traffic engineering via SR-TE and Flex-Algo. Regardless of the SR flavor, the combination of SR-TE, Flex-Algo, ODN, and TI-LFA on IOS-XR provides a powerful, programmable, and resilient network infrastructure for 2026 demands.