Flex-Algorithm and Micro-loop Avoidance

Theoretical foundations and architecture

Flex-Algorithm turns the IGP into a traffic engineering tool without a controller. The operator describes a "plane" once: a metric type, affinity constraints and a priority. Every node that joined it runs a separate SPF on the pruned topology and advertises its own Prefix-SID for algorithm 128-255. This gives a plane with minimum delay, a plane without expensive links or two fully separated planes for duplication, and VPN traffic can be steered into the right one through color and SR-TE. The second part of the lesson covers a problem that is often forgotten when fast protection is designed: micro-loops that appear when nodes converge at different times. You will see how micro-loop avoidance (a local delay and a SID list of the path) differs from TI-LFA, how they work together and how this changes inside a Flex-Algo plane.

Flex-Algorithm: the idea and the numbers

Flexible Algorithm (RFC 9350) moves part of the SR-TE work into the IGP. You already know that a standard Prefix-SID is bound to algorithm 0 (plain SPF on the IGP metric) and that Strict SPF (algorithm 1) forbids deflection. The numbers 128-255 are left to the operator: each is its own "plane" with its own path definition. The definition is called FAD (Flex-Algorithm Definition) and holds the algorithm number, the metric type, the calculation type, a priority and a set of constraints. Metric type: 0 - the IGP metric, 1 - the minimum unidirectional link delay (measured and advertised with the IGP extensions of RFC 8570 and RFC 7471, or set statically), 2 - the TE metric. There is only one calculation type so far - SPF. Constraints are affinity (exclude-any, include-any, include-all over admin-group bits; extended admin groups allow more than 32 bits) and exclude SRLG. The M flag changes how the prefix metric is used. Link attributes for Flex-Algo travel as regular IS-IS TE extensions or in ASLA (RFC 8919, RFC 8920) with the Flex-Algo application bit.

Participation, FAD selection and computation

A node takes part in a plane if it explicitly advertised the algorithm in the SR-Algorithm sub-TLV (IS-IS) or the OSPF equivalent and supports the computation described in the FAD. The definition may be configured on several nodes: if definitions conflict, the FAD with the highest priority wins, and on a tie the one from the node with the highest identifier. Therefore at least two nodes usually advertise the FAD with identical configuration, and a copy error in a constraint produces a plane that differs between nodes. A node that does not support the FAD (the metric, a constraint, the calculation type) does not participate in the plane. The computation is done per algorithm: the topology is pruned (links removed by affinity and SRLG, and nodes that did not advertise the algorithm), then an SPF runs on the metric from the FAD. If the needed prefix is unreachable in this topology, there is no traffic of that algorithm to it at all, which differs from algorithm 0: it will not automatically fall back to another algorithm.

One prefix-SID per algorithm and forwarding

For each algorithm a node advertises its own Prefix-SID: the Prefix-SID sub-TLV has an Algorithm field. Indexes come from the same SRGB as for algorithm 0, but a separate index is allocated for each (node, algorithm) pair: in this lesson PE2 has 16002 for algorithm 0 and 16102 for algorithm 128. On every node of the plane the LFIB gets an entry for label 16102 that follows the shortest path of the plane. Nodes outside the plane have no such entries and a packet with this label is dropped, so the entry point must be used only where the path is known. The number of labels grows linearly with the number of nodes and algorithms: plan the index range and the SRGB in advance. The scope of Flex-Algo is an IGP domain (area or level); for inter-area and inter-domain paths SR-TE with an algorithm segment is used, and support for spreading Flex-Algo between areas depends on the platform.

Steering and use cases

Traffic enters a plane in three ways: an SR Policy whose first segment is the algorithm Prefix-SID (it can be set explicitly), an ODN template naming the algorithm for the dynamic path (color 200 is bound to algorithm 128 - you will see this in the configuration) and BGP/service routes whose next hop resolves to an algorithm prefix on platforms that implement it. Typical uses: low delay (the delay metric), excluding links (leased lines, satellite, expensive transit), two isolated layers A and B (include-any A or B) for duplication, regional or "slice" planes. The advantage is that no controller and no per-PE policies are needed: the plane is defined once. The limits are 128 algorithms in total and identical FADs on all nodes.

Micro-loops

A micro-loop is a short forwarding loop after a topology change (RFC 5715). Nodes finish the SPF and update the FIB at different times: node A has already switched to the new path that goes through B, while B still uses the old one, and packets bounce between them until B converges (usually from tens to hundreds of milliseconds). Triggers: link down, link up, a metric change, the overload bit. Consequences: loss, duplication, a growth of TTL-expired and overloaded links. There are two kinds of protection. A local delay (RFC 8333): after a change the node postpones the RIB update by a configured time (rib-update-delay in configuration, often a few seconds by default, which differs between platforms) so that neighbours can converge. SR-based protection: while the delay is active the node steers traffic not along the ordinary path but with the SID list of the new (post-convergence) path, which is loop-free by construction because every segment pins the next node. For the SR variant rely on current versions of draft-bashandy-rtgwg-segment-routing-uloop and on the platform documentation; check the RFC number separately.