Summary

  • RFC 9502 extends IGP Flexible Algorithm to ordinary IPv4 and IPv6 prefix forwarding. It does not make an advertised algorithm, a Flexible Algorithm Definition or a prefix TLV synonymous with an installed route or an observed packet path.
  • The IP data plane has its own participation signal. A router may participate in the same Flex-Algorithm for IP while not participating for Segment Routing, and a non-participant must not install the IP Flex-Algorithm forwarding entry.
  • The standard deliberately names refusal paths: conflicting advertisements can cause a receiver to install nothing; an unsupported or invalid definition makes a configured node stop participating; and a later area or domain may be unable to provide the claimed algorithm-specific reachability.

The attractive dashboard sentence is short: “algorithm 128 is up.” It can be useful shorthand inside a team that knows exactly which router, topology, data plane and time it covers. It becomes dangerous when it travels unqualified. A label in an IGP, a green FAD collector and an inventory row can each be true while no particular IPv4 or IPv6 packet has used the intended constraint set.

RFC 9502 is not a promise that every router will send traffic by the least-delay path, a proof that a service received the expected treatment, or an operator charter. It is a carefully bounded extension. It lets IGP Flexible Algorithm, previously associated with Segment Routing data planes, compute constraint-based paths to regular IP prefixes. Its value lies in making one data plane’s algorithm-specific state legible enough to compute and install. That is substantial. It is also narrower than the stories often attached to a path label.

Four records, not one route

Start with the distinction that a topology display tends to hide. There is an algorithm definition. There is a router’s participation in a data plane. There is a prefix advertisement associated with that algorithm and a topology. There is a local calculation and, in the successful case, a forwarding-plane entry. RFC 9502 makes each record necessary for the next; it does not erase the separations between them.

The Flexible Algorithm Definition, or FAD, supplies the shared rules: metric, calculation type and possible constraints. RFC 9350 requires routers that participate in a particular algorithm within the same advertisement scope to agree on the definition so that the resulting forwarding can remain loop-free. Agreement is a property of the participating set. It is not evidence that all routers in an administrative domain joined it, that every implementation supports it, or that every destination remains reachable under its exclusions.

RFC 9502 then gives ordinary IP its own data plane. This is more than an encoding detail. Participation in the IP Flexible Algorithm data plane must be advertised independently from participation in an SR data plane. A router can participate for one and not the other; it remains in default algorithm 0 regardless. Treating the number alone as a network-wide policy therefore loses the exact question the standard asks: which nodes, in which data plane, currently say they can calculate and forward under this definition?

The prefix record is still a third object. The new IS-IS and OSPF advertisements associate a prefix with a topology and an algorithm. RFC 9502 supplies carefully limited receiver behavior. If competing originators advertise the same prefix under different algorithms in the stated cases, the receiver must ignore them and must not install forwarding entries on their basis. When ordinary algorithm-0 reachability is present alongside an algorithm-specific advertisement, the standard supplies preference rules rather than a license to combine meanings freely.

A collector that counts advertisements as successful routes misses the most important branch: well-formed input can lead to deliberate non-installation.

Finally comes the local calculation. For IP Flex-Algorithm, non-participating nodes are pruned from the relevant topology. The resulting path is computed using the specified algorithm in the associated topology. A capable receiving router that participates in both that topology and algorithm must install the forwarding entry; one that does not participate must not. This is not a vague aspiration. It is a narrow, testable chain of local conditions.

What a shared definition can and cannot say

The IANA IGP Parameters registry reserves values 128 through 255 for Flexible Algorithms. That registry gives numbers stable meaning. It does not show that a particular value has been configured on a router, flooded through a specific scope, accepted by a peer, selected by a calculation or used by traffic. A registry is a coordination surface; it is not a telemetry system.

The same discipline applies to an FAD. A label such as “low delay” may invite an organization to speak as if it had bought a delivery guarantee. But the definition only identifies the calculation rules. A participating node must still select a valid FAD it supports. RFC 9350 is explicit that a node configured to participate must stop participating when no valid definition is available or when the selected definition contains a calculation type, metric, constraint, flag or sub-TLV it does not support. A configuration intent is therefore weaker than effective participation.

This is an operationally healthy rule. Inventing a zero metric for missing data or silently accepting an unfamiliar constraint would create a comforting but false continuity. The standards instead favor a bounded failure. In the base Flex-Algorithm calculation, links lacking a required non-IGP metric are pruned rather than treated as zero. The resulting path may be absent. That absence is information: it says the system has not established the conditions for the narrower claim.

The distinction becomes sharper at boundaries. A router computing for its local IGP area does not automatically see the next area or domain’s full topology. RFC 9350 says an ABR or ASBR can choose an egress according to the local Flex-Algorithm path while the next region separately computes onward reachability. The consequence can be an end-to-end path that is suboptimal under the constraints, or traffic dropped where the next segment lacks reachability for the algorithm. Calling the original FAD “end-to-end policy” would turn a local computation into a claim about a system it has not observed.

Evidence that survives an incident review

For an actual change window, preserve the FAD selected at each relevant router, its advertisement scope and the hardware/software support decision. Preserve the IP-data-plane participation advertisement independently from SR participation. Preserve the algorithm-specific prefix advertisement, the topology and metric inputs used at calculation time, and the discard reason whenever an input was ignored or a route was not installed.

Next, prove the local forwarding state. A control-plane advertisement is not a FIB snapshot. A FIB snapshot is not a counter. A counter is not a destination-side receipt. If the business question concerns a user flow, join source and destination prefixes, encapsulation or plain-IP treatment, next hop, interface counters, loss/latency observations, the destination-side service record and the relevant clock sources. Each item should identify who asserted it and which condition could falsify it.

This is not bureaucratic excess. It prevents two familiar failures. First, a controller may advertise a new constraint while an older winning FAD remains selected somewhere else. Second, a team may see a route installed locally and conclude a customer flow met a service objective, although a later area pruned the path or the application never accepted the traffic. Separating the records allows a fast, proportionate response: repair a malformed advertisement without declaring an outage; contain an actual forwarding failure without rewriting a history of the algorithm definition.

The editorial discipline in Heng Lu’s notes is useful here. The common layer should be strict about the facts it must coordinate. Beyond that layer, later choices and effects remain local. In this case the RFC’s shared semantics are unusually clear: numbers, FAD agreement, participation signals, prefix associations and computation rules. Whether a router supports the FAD, whether it installs the result, whether a packet traverses it and whether a destination provides a useful service are separately observable realities. The distinction is not a downgrade of the standard. It is why the standard can be trusted for what it actually governs.

Sources