rfc-9350

IGP Flexible Algorithm

P. Psenak (Editor), S. Hegde, C. Filsfils, K. Talaulikar, A. Gulko
date2023-02 streamIETF areartg wglsr statusPROPOSED STANDARD pages42 canonicalhttps://www.rfc-editor.org/rfc/rfc9350 doi10.17487/RFC9350 errataview
IGP protocols historically compute the best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths.

updated by

Extracted elements (29)

design-rationale §5.3

The FAD Priority field (0-255, higher wins) combined with Router-ID tie-breaking ensures a deterministic, consistent winning FAD selection across all routers in the area without requiring coordination beyond normal IGP flooding, avoiding transient loops during FAD changes.

routing

design-rationale §13.1

Using Flex-Algorithm for inter-area or inter-domain prefix reachability without the M-flag is NOT RECOMMENDED because, without explicit FAPM (and FAAM for OSPF external routes), it is impossible to determine whether an ABR or ASBR has Flex-Algorithm reachability in the next area or domain, potentially causing persistent traffic drops or forwarding loops.

routing

interoperability-note §16

This extension introduces no new backward-compatibility issues. IS-IS, OSPFv2, and OSPFv3 all have well-defined handling of unrecognized TLVs and sub-TLVs, allowing routers that do not implement Flex-Algorithm to coexist with those that do.

routing

normative-requirement §14.1 MUST

A Flex-Algorithm path MUST be installed in the MPLS forwarding plane using the label corresponding to the Prefix-SID advertised for that Flex-Algorithm. Traffic that should use Flex-Algorithm-specific paths MUST be dropped when no such paths are available.

routing, mpls

normative-requirement §5 MUST

All routers configured to participate in a particular Flex-Algorithm that are within the same FAD advertisement scope MUST agree on the definition of the Flex-Algorithm to guarantee loop-free forwarding for paths computed for that algorithm.

routing

normative-requirement §5.1 MUST NOT

An IS-IS L1/L2 router MAY regenerate the winning FAD from level 2 into the level 1 area without modification, but MUST NOT regenerate any FAD sub-TLV from level 1 to level 2.

routing

normative-requirement §12 MUST

Application-specific link attributes used in Flex-Algorithm calculation MUST use ASLA advertisements (RFC 8919 / RFC 8920). A new Application Identifier bit (bit 3, the X-bit) in the SABM indicates that an ASLA advertisement is associated with Flex-Algorithm. Receivers MUST accept both Administrative Group and Extended Administrative Group TLVs.

routing

normative-requirement §13 MUST

During Flex-Algorithm computation, links MUST be pruned in this order: (1) any color matching the Exclude Admin Group rule, (2) any SRLG matching the Exclude SRLG rule, (3) no color matching the Include-Any Admin Group rule, (4) not all colors set for the Include-All Admin Group rule, (5) required non-IGP metric not advertised for the link (a metric of 0 MUST NOT be assumed).

routing

normative-requirement §5.3 MUST

Every router configured to participate in a Flex-Algorithm MUST select the winning FAD by: (1) choosing the advertisement(s) with the numerically greatest Priority value, then (2) tie-breaking by the numerically greatest System-ID (IS-IS) or Router-ID (OSPF). The selected FAD is the 'winning FAD'.

routing

normative-requirement §13 MUST

For SR-MPLS and SRv6 data planes, all nodes that do not advertise participation for a given Flex-Algorithm MUST be pruned from the topology during that Flex-Algorithm's path calculation.

routing

normative-requirement §5.3 MUST

If a node is configured to participate in a Flex-Algorithm but there is no valid FAD, or the winning FAD includes an unsupported calculation-type, metric-type, constraint, flag, or sub-TLV, it MUST stop participating: it MUST NOT announce participation and MUST remove any forwarding state associated with that Flex-Algorithm.

routing

normative-requirement §13.1 MUST

If the winning FAD includes the M-flag, an ABR or ASBR MUST include the FAPM in its inter-area/inter-domain prefix advertisement for that Flex-Algorithm when the prefix is reachable, and MUST NOT include it when the prefix is unreachable. If the FAPM for a Flex-Algorithm is absent from an inter-area or external prefix advertisement, that prefix MUST be treated as unreachable for that Flex-Algorithm.

routing

normative-requirement §14.1 MUST

LFA paths for a Flex-Algorithm MUST be computed using the same constraints as the primary paths for that Flex-Algorithm. LFA paths MUST only use Prefix-SIDs (SR-MPLS) or SIDs (SRv6) advertised specifically for the given Flex-Algorithm and MUST NOT use Adjacency SIDs on links pruned from the Flex-Algorithm computation.

routing, mpls

normative-requirement §14.2 MUST

SRv6 forwarding entries for locator prefixes MUST be installed in the forwarding plane of receiving routers when the associated topology/algorithm is being participated in. Forwarding entries for locators associated with Flex-Algorithms in which the node is not participating MUST NOT be installed.

routing, ip

normative-requirement §11.1 MUST

To advertise participation in a Flex-Algorithm for Segment Routing (both SR-MPLS and SRv6), the Flex-Algorithm value MUST be included in the SR-Algorithm TLV (OSPF) or sub-TLV (IS-IS). SR Flex-Algorithm participation advertisement is topology independent.

routing

protocol-element §4

A Flexible Algorithm Definition (FAD) is the triplet of (a) calculation-type, (b) metric-type, and (c) a set of constraints. The Flex-Algorithm is a numeric identifier in the range 128-255 associated via configuration with the FAD; the mapping between a Flex-Algorithm value and its meaning is operator-defined.

routing

protocol-element §6.4

The IS-IS and OSPF Flexible Algorithm Definition Flags (FADF) sub-TLV (Type 4) carries a variable-length Flags field. The M-flag (bit 0) mandates use of the Flex-Algorithm-specific prefix metric for inter-area and external prefix calculations; it is explicitly not applicable to prefixes advertised as SRv6 locators.

routing

protocol-element §6.5

The IS-IS Flexible Algorithm Exclude SRLG (FAESRLG) sub-TLV (Type 5) carries one or more SRLG values (each 4 octets) that MUST be excluded from the Flex-Algorithm topology. Unlike other IS-IS FAD sub-sub-TLVs, it MAY appear multiple times in the FAD set for a given IS; the receiver MUST take the union of all values.

routing

protocol-element §10.1

The OSPFv2 Extended Inter-Area ASBR (EIA-ASBR) LSA (Opaque Type 11, LS Type 10) is originated by OSPFv2 ABRs to advertise Flex-Algorithm-specific reachability and metrics for ASBRs external to the area. Semantically equivalent to the Type 4 summary-LSA, but carries the ASBR Router ID in the LSA body rather than in the LSID.

routing

registry §18.1

IANA allocated values 128-255 in the 'IGP Algorithm Types' registry for Flexible Algorithms. A new 'IGP Metric-Type' registry (Standards Action) was created with three initial entries: 0 (IGP Metric), 1 (Min Unidirectional Link Delay), and 2 (TE Default Metric / TE Metric).

registry, routing

registry §18.2

IANA created the 'IGP Flexible Algorithm Definition Flags' registry (Standards Action, ascending bit order). Bit 0 is assigned as the Prefix Metric Flag (M-flag).

registry, routing

registry §18.3.3

IANA created the 'IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV' registry (Expert Review), assigning types 1 (Exclude Admin Group), 2 (Include-Any Admin Group), 3 (Include-All Admin Group), 4 (Definition Flags), and 5 (Exclude SRLG). A new 'Link Attribute Application Identifiers' registry bit 3 (X-bit) was also assigned for Flex-Algorithm in the SABM.

registry, routing

security-consideration §17

A compromised authenticated node can advertise a malicious FAD (e.g., specifying an unsupported metric-type or calculation-type), causing misrouting or blackholing of Flex-Algorithm traffic across the area. This class of attack is not preventable through authentication and is analogous to advertising any other incorrect IGP information.

security, routing

security-consideration §17

An attacker can hijack a particular Flex-Algorithm by advertising a FAD with Priority 255 (or any value greater than the legitimate nodes), causing all routers in the area to compute paths according to the attacker's definition. This is mitigated by the existing IS-IS (RFC 5304, RFC 5310) and OSPF (RFC 7474, RFC 4552) authentication mechanisms.

security, routing

wire-format §5.1

The IS-IS FAD sub-TLV (Type 26) is a sub-TLV of IS-IS Router CAPABILITY TLV-242. Its fixed portion encodes Flex-Algorithm (1 octet, 128-255), Metric-Type (1 octet), Calc-Type (1 octet, 0-127), and Priority (1 octet), followed by optional sub-TLVs. The Router Capability TLV carrying it MUST have the S bit clear to prevent flooding outside the originating level.

routing

wire-format §8

The IS-IS Flexible Algorithm Prefix Metric (FAPM) sub-TLV (Type 6, Length 5) is a sub-TLV of TLVs 135, 235, 236, and 237. It encodes Flex-Algorithm (1 octet, 128-255) and Metric (4 octets). It MUST NOT be advertised as a sub-TLV of the IS-IS SRv6 Locator TLV.

routing

wire-format §5.2

The OSPF FAD TLV (Type 16) is a top-level TLV of the Router Information (RI) LSA. Its fixed portion encodes Flex-Algorithm (1 octet), Metric-Type (1 octet), Calc-Type (1 octet), and Priority (1 octet), followed by optional sub-TLVs. Area-scoped flooding is REQUIRED; AS-scoped flooding SHOULD NOT be used unless local policy requires domain-wide advertisement.

routing

wire-format §9

The OSPF FAPM sub-TLV (Type 3 for OSPFv2, 26 for OSPFv3, Length 8) encodes Flex-Algorithm (1 octet), Flags (1 octet; bit 0 is the E-bit for Type 2 external metric, applicable only to external/NSSA prefixes), Reserved (2 octets), and Metric (4 octets).

routing

wire-format §10.2

The OSPF Flexible Algorithm ASBR Metric (FAAM) sub-TLV (Type 1 for OSPFv2, 33 for OSPFv3, Length 8) encodes Flex-Algorithm (1 octet), Reserved (3 octets, MUST be zero), and Metric (4 octets). It advertises the Flex-Algorithm-specific metric for ASBR reachability between areas.

routing