1.1. Flex-Algo Demystified: Rethinking Traffic Engineering Beyond RSVP & SR-TE

Introduction
For years, Interior Gateway Protocols (IGPs) like OSPF and IS-IS have relied on a single metric-based calculation to determine the shortest path. While this worked, it also meant that all traffic followed the same metric logic, regardless of service type or intent.
Traffic Engineering (TE) evolved to address this:
• RSVP-TE introduced explicit paths but came with high signaling and state
overhead.
• SR-TE simplified this using Segment Routing but still relied heavily on
head-end policies.

Flex-Algo: The Next Step-
Flex-Algo is the next step, an intent-based, distributed approach that allows you to create multiple separate logical topologies and calculate paths in an IGP. These all-logical topologies coexist inside the same IGP domain, without per-flow signaling or head-end complexity. A Flex-Algo provides a simple solution with separated routing planes, constrained TE paths, and low-delay routes, meeting differentiated requirements of various services in single Network in the modern era.

Why Do We Need Flex-Algo?
Today the new Era of networks must support multiple service types simultaneously — high-bandwidth video, ultra-low latency financial trading, mission-critical enterprise VPNs. A single SPF metric cannot capture all of these intents.

• Traditional IGP → single SPF metric, same path for all traffic.
• RSVP-TE → flexible but heavy on state and complexity.
• SR-TE → simpler, but still dependent on head-end policy definitions

 Flex-Algo integrates constraint-based SPF directly into IGPs, delivering
Traffic Engineering capabilities natively.

Flex Algo can work only with Segment-routing and To understand Flex-Algo, we must first recap the forwarding instruction of IGP Prefix-SIDs in SR Nodes.

Recap of IGP Prefix-SID
IGP prefix-SIDs are global segments means forwarding instruction for a prefix-SID will be installed by all nodes in the IGP domain. The instruction to forward the packet towards a prefix-SID depends on the “algorithm” associated with it.

There are two well-known standard algorithms-
1. Algo 0 (SPF) – SPF (default shortest-path calculation).
2. Algo 1 (strict-SPF) – Strict-SPF (SPF calculation without local policy
overrides)

Algo 0 (SPF):
Algo 0 called default Algo forwards packet along ECMP aware shortest path towards the destination.
– Default IGP shortest path (Dijkstra algorithm)
– ECMP-aware (can use multiple equal-cost paths)
- Paths can be overridden by local policies (e.g., SR-TE or RSVP-TE autoroute)

For ex: If node advertises a loopback prefix “P” with an algo of “0” means, each node in the IGP domain installs ECMP aware shortest path forwarding entry towards “P”. Such kind of path is calculated using well known Dijkstra SPF algorithm. Dijkstra algorithm uses metric to find the best path towards the destination.



Algo 1 (strict-SPF):
Algo (1) is like Algo0 (Dijkstra shortest path) algorithm. Only difference is that forwarding entry installed to a prefix-SID with Algo1 cannot be overwritten by any local policy on any node in the Path from source to destination. Packet follows unaltered IGP shortest path towards the destination.

– Like Algo 0 but non-overridable
– Ensures that traffic strictly follows IGP-calculated paths


Locally configured policy overwriting the Algo0 path

– A single prefix can be advertised with multiple Prefix-SIDs, each tied to a
different algorithm. For ex: 100.0.0.5/32 in R5 can be configured with
prefix-SID index 5 for algo0 and 55 for algo1

What is Flex-Algo?
Flex-Algo (Flexible Algorithm) is an IGP extension that allows operators to define custom path computation rules within the IGP itself. Each Flex-Algo is identified by an ID (128–255 for user-defined) and represents a different intent — such as low-latency routing or excluding specific links.

Instead of relying on a single SPF metric for all traffic, Flex-Algo enables the network to create multiple logical topologies (or slices) on the same physical network, each optimized for different service needs.

What Do We Mean by Intent?
• Low-latency intent → minimize end-to-end delay.
• Policy intent → exclude RED links.
• Resiliency intent → avoid SRLGs.
• Cost intent → minimize TE metric for bandwidth optimization.

– Intent = the operator’s goal expressed as SPF rules. Flex-Algo
translates these intents into distributed IGP computations so that all
routers calculate consistent paths.

From Intent to FAD-
Now that we know Flex-Algo is about expressing different intents, the IGP needs a way to encode and share those rules. That’s what the Flex-Algo Definition (FAD) provides. Each FAD specifies:

• How should the SPF run? “Calculation Type”
• Which metric should be minimized? “Optimization Objective”
• Which links are allowed or excluded? “If any constraints”

–These rules are bundled together into the FAD, and all routers
participating in that Flex-Algo must agree on the same definition.

Each Flex-Algo Definition (FAD) specifies:
1. Calculation Type → SPF(0) or Strict-SPF(1)
2. Optimization Objective → IGP metric, TE metric, or Delay metric
3. Constraints (Optional) → Affinity (link colors), SRLGs, inclusion/exclusion
rules
Together, these create a logical topology that nodes use when calculating paths for Prefix-SIDs tied to that algorithm.
Example:
– Algo 128 = IGP metric shortest path, exclude links with RED affinity
– Algo 129 = Minimize Delay metric paths

1. Calculation Type- defines the SPF method a node must use when computing
paths towards a destination. In other words, it specifies the type of
shortest path algorithm to run within the topology. Only two options exist:
SPF(0): Standard shortest path calculation
SPF(1): Strict-SPF calculation

-> Cisco XR support only SPF (0) for Flex Algo.

2. Optimization Objective- specifies the metric type (IGP Metric, TE Metric, or
Delay Metric) that should be minimize when calculating the best path. This
determines what “optimal” means for the algorithm. The name “Optimization”
for this component is being used because “metric type” helps to calculate
best optimized path (minimization of a specific metric type) among the
available one.

-> If the objective is IGP metric (default), nodes compute the lowest-
cost path using standard IGP metrics.
-> If set to Delay, nodes try to find the path with minimal end-to-end
latency.
-> If set to TE metric, the TE cost values are being used for path
computation.

Each Prefix-SID advertised with a Flex-Algo is installed based on the path that minimizes the chosen metric, while still respecting the algorithm’s constraints.

3. Constraint- Defines which links can be included/excluded:
• Admin Groups (Affinity Colors):

• Exclude-Any → drop link if any bit matches.
• Include-Any → allow link if at least one bit matches.
• Include-All → allow link only if all bits match.

• SRLG (Shared Risk Link Groups): Exclude links that share the same physical
risk.

This is optional Components so if not defined then would not be used in calculation of path. Constraints can be of in the form of inclusion/exclusion of particular links or SRLG etc. This can be applied by using affinity Colors.
• These constraints are applied not only to the primary paths but also to backup
paths (LFA, TI-LFA, and microloop avoidance).
• Any change in Flex-Algo definitions on a live network can cause temporary traffic
disruption until all routers converge on the updated paths.

Flex-Algo Path Computation Consists of:
1. Algorithm Definition (FAD): Establishing the rules for how paths are computed
(calculation type, optimization objective, and constraints).
2. Prefix-SID Advertisement: Loopback prefixes are advertised with the Flex-Algo ID
so that all participating nodes can calculate paths accordingly.

Why Flex-Algo Matters
• Distributed computation: Unlike SR-TE, where only the head-end calculates the
path, Flex-Algo enables all nodes to compute paths consistently.
• Simplified SID lists: Instead of long SID stacks in SR-TE, Flex-Algo often needs
just one Prefix-SID per destination.
• Intent-driven: Operators can steer traffic for low latency, high bandwidth, or
protected paths without touching the base IGP.
• Service differentiation: Same physical network, multiple logical topologies.

Example-
Imagine R1 advertises its loopback (10.0.0.1/32) with two Prefix-SIDs:
• SID 5 (Algo 0): Default SPF path (shortest IGP metric)
• SID 55 (Algo 128): Low-delay path excluding RED links
Traffic engineered for best-effort uses SID 5, while latency-sensitive services use SID 55. Both coexist seamlessly.

Benefits-
• Flex-Algo lets you define multiple logical networks inside a single IGP.
• Each logical network can optimize for different metrics or constraints.
• It reduces reliance on SR-TE head-end policies while still offering
intent-based routing.
• A foundational step towards automation and intent-based networking.

Flex-Algo in Action: The Financial Extranet Story-
Imagine a Financial Extranet — a specialized operator network designed that connects trading firms, brokers, banks, and global stock exchanges. In such networks, different types of financial traffic coexist, but each has very different requirements:

• Market Data Feeds & High-Frequency Trading Orders
o Require ultra-low latency and must follow the shortest possible path
with minimal delay.
o Even a few microseconds matter.
• Clearing, Settlement, Risk, and Reporting Traffic
o Throughput is more important than absolute latency.
o This traffic can take longer or cheaper paths without impacting
service quality.

How This Would Look with RSVP-TE
If we tried to achieve this separation with RSVP-TE:
• Each node would need to signal and maintain a full mesh of P2P RSVP LSPs.
• To separate intents (low-latency vs high-throughput), you’d need two sets of
LSPs:
o One mesh optimized for low-latency.
o Another mesh optimized for cost-efficient/high-capacity paths.
• This means:
o O(N²) scaling → state explosion as the number of nodes grows.
o Complex signaling, bandwidth reservations, and refresh overhead.
o Operators must explicitly manage every path.

• While RSVP-TE works best, it becomes operationally heavy and unscalable for
large extranet deployments

How This Would Look with SR-TE
With SR-TE, RSVP signaling is removed, but:
• The head-end nodes must still be configured with explicit SR Policies.
• For multiple intents, you need multiple SR Policies per destination (low-
latency policy, cost-based policy, etc.).
• Still operationally complex in a financial extranet where new participants
(trading firms, brokers, exchanges) are added frequently.

The Scaling Problem with RSVP-TE and SR-TE
In RSVP-TE or SR-TE based designs, every new node( New POP in New region or country/City)
• RSVP-TE: Building hundreds of new LSPs between the new node and
every existing node. Two separate meshes if you want both low-
latency and cost-based paths.
• SR-TE: Creating new SR Policies at each headend towards the new
destination, again duplicated per intent (latency vs cost).

• Each new location means engineering teams must reconfigure the entire
network. In a financial extranet, where new participants may be added
frequently, this becomes a major operational headache. just 2 new
routers into a 100-node RSVP-TE mesh forces the network to create 402
new LSPs. If you want two separate meshes (e.g., low-latency and cost-
optimized intents), that number doubles → 804 new LSPs

How Flex-Algo Simplifies this with Flex-Algo –
Operators can design the extranet using two logical topologies, both running on the same physical infrastructure:
• The IGP itself natively defines the low-latency Blue Core (Algo 128) and the cost-based Red Core
(Algo 129).
• Each router automatically computes consistent paths based on the FAD (calculation type, metric type,
constraints).
• A node advertising its Prefix-SID simply advertises one SID per algorithm.

• Blue Core (Low-Latency Slice)
o Flex-Algo 128
o Calculation Type: SPF
o Optimization Metric: Delay
o Constraints: Exclude “RED” affinity links (slower circuits)
o Used for: market data distribution, electronic trading, algorithmic order flow.

• Red Core (High-Throughput Slice)
o Flex-Algo 129
o Calculation Type: SPF
o Optimization Metric: IGP metric (cost)
o Constraints: none, or allow paths with higher delay but more capacity
o Used for: settlement, clearing, risk analytics, general business services.

With Flex-Algo:
• The new router simply advertises its loopback Prefix-SID with the Flex-Algo IDs it participates in.
• Instantly, all routers in the domain compute the right paths:
o Blue Core (Algo 128 → low-latency)
o Red Core (Algo 129 → cost-based)
• No RSVP mesh explosion.
• No per-headend SR Policy provisioning.
-> Adding a new trading site is as simple as “bring it online and advertise its Prefix-SIDs.” The network
automatically integrates it into the right logical topologies.

Example –
R1 advertises its loopback (10.0.0.1/32) with two Prefix-SIDs:
• SID 5 (Algo 0): Default SPF path (best-effort)
• SID 55 (Algo 128): Low-delay path in the Blue Core
A trading firm connecting to this extranet can select SID 55 for latency-sensitive trading traffic, while settlement and reporting apps continue to use SID 5 or Algo 129.

• The same physical backbone carries both types of traffic, but each follows paths optimized for its
intent.
• No need for RSVP-TE tunnels or complex SR-TE policies at every head-end.
• Flex-Algo distributes the logic across the IGP — every router knows how to forward based on the chosen
algorithm.