rfc-9502

IGP Flexible Algorithm in IP Networks

W. Britto, S. Hegde, P. Kaneriya, R. Shetty, R. Bonica, P. Psenak
date2023-11 streamIETF areartg wglsr statusPROPOSED STANDARD pages21 canonicalhttps://www.rfc-editor.org/rfc/rfc9502 doi10.17487/RFC9502
This document extends IGP Flexible Algorithm so that it can be used with regular IPv4 and IPv6 forwarding.

Extracted elements (27)

design-rationale §6

Existing prefix reachability advertisements cannot be reused to associate a prefix with a Flex-Algorithm because they advertise reachability only under default algorithm 0. New IP Flexible Algorithm reachability TLVs/sub-TLVs are therefore defined for both IS-IS and OSPF.

routing, ip

design-rationale §1

Flexible Algorithm as specified in RFC 9350 only computes paths to SR MPLS Prefix SIDs and SRv6 Locators, meaning it cannot be deployed without SR or SRv6. This document extends Flexible Algorithm to compute paths to regular IPv4 and IPv6 prefixes, removing the SR dependency.

routing, ip

design-rationale §6.5

The existing OSPF Flexible Algorithm ASBR Metric (FAAM) Sub-TLV from RFC 9350 cannot be used for IP Flexible Algorithm because SR and IP Flex-Algorithm topologies may differ (each signals participation independently), making SR-based topology calculations inapplicable to IP forwarding. A new OSPF IP Flexible Algorithm ASBR Metric (IPFAAM) Sub-TLV is defined instead.

routing, ip

interoperability-note §6.2

When a prefix advertisement is received in both an IS-IS SRv6 Locator TLV (RFC 9352) and an IS-IS IPv6 Algorithm Prefix Reachability TLV, the receiver MUST ignore both of them and MUST NOT install any forwarding entries based on these advertisements. This situation SHOULD be logged as an error.

routing, ip

normative-requirement §5.1 MUST

Algorithm values outside the Flex-Algorithm range (128–255) in any IP Algorithm participation or reachability advertisement MUST be ignored by the receiver; this situation SHOULD be logged as an error.

routing, ip

normative-requirement §6.5 MUST

An OSPF ABR MUST include the OSPF IPFAAM Sub-TLVs as part of any IP Flexible Algorithm ASBR reachability advertisement between areas. The FAAM Sub-TLV as defined in RFC 9350 MUST NOT be used during IP Flexible Algorithm path calculation; the IPFAAM Sub-TLV MUST be used instead.

routing, ip

normative-requirement §5 MUST

Flexible Algorithm participation MUST be advertised for each Flexible Algorithm data plane independently. IP Flexible Algorithm data plane participation MUST be signaled independently of any other Flexible Algorithm data plane (e.g., SR). A router may participate in a Flex-Algorithm for the IP data plane but not for the SR data plane.

routing, ip

normative-requirement §5.2 REQUIRED

For the OSPF IP Algorithm TLV, area- or AS-scoped flooding is REQUIRED. AS flooding scope SHOULD NOT be used unless local configuration policy on the originating router indicates domain-wide flooding. When multiple IP Algorithm TLVs are received from a given router, the one in the Router Information LSA with area-scoped flooding must be used; if same scope, the one with the numerically smallest Instance ID MUST be used.

routing, ip

normative-requirement §8 MUST

Forwarding entries for IP Flex-Algorithm prefixes MUST be installed in the forwarding plane of routers that participate in the associated topology and algorithm. Forwarding entries for IP Flex-Algorithm prefixes associated with Flex-Algorithms in which the node is not participating MUST NOT be installed.

routing, ip

normative-requirement §6.1 MUST

If a router receives multiple IPv4 (or IPv6) Algorithm Prefix Reachability advertisements for the same prefix from different originators that do not all advertise the same algorithm, it MUST ignore all of them and MUST NOT install any forwarding entries based on those advertisements. This situation SHOULD be logged as an error.

routing, ip

normative-requirement §6.1 MUST

In the IS-IS IPv4 Algorithm Prefix Reachability TLV, the D-flag (up/down bit) MUST be set when a prefix is leaked from level 2 to level 1. Prefixes with the D bit set MUST NOT be leaked from level 1 to level 2, preventing routing loops.

routing, ip

normative-requirement §10 MUST

LFA and R-LFA computations MUST be restricted to the Flex-Algorithm topology, and computed backup next hops should be programmed for the IP Flex-Algorithm prefixes.

routing, ip

normative-requirement §5.1 MUST NOT

The IS-IS IP Algorithm Sub-TLV MUST be propagated throughout the level and MUST NOT be advertised across level boundaries; the S bit in the enclosing Router Capability TLV MUST NOT be set. It MUST NOT be advertised more than once at a given level; if multiple copies are received from the same originator, a router MUST select the first in the lowest-numbered LSP and ignore subsequent instances.

routing, ip

normative-requirement §4 MUST

To guarantee loop-free forwarding, all routers participating in a Flex-Algorithm MUST agree on the Flexible Algorithm Definition (FAD). Selected nodes within the IGP domain MUST advertise FADs as described in RFC 9350.

routing

normative-requirement §6.3 MUST

When a prefix advertisement is received in any LSA advertising algorithm 0 reachability and in an OSPFv2 (or OSPFv3) IP Algorithm Prefix Reachability Sub-TLV, only the algorithm 0 reachability MUST be used, and all occurrences of the IP Algorithm Prefix Reachability Sub-TLV MUST be ignored.

routing, ip

normative-requirement §6.1 MUST

When a prefix advertisement is received in both a standard IPv4 Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability TLV, the standard IPv4 Prefix Reachability advertisement MUST be preferred when installing entries in the forwarding plane. The same rule applies to IPv6.

routing, ip

normative-requirement §7 MUST

When computing paths for a given IP Flex-Algorithm, all nodes that do not advertise participation for that IP Flex-Algorithm (as described in Section 5) MUST be pruned from the topology. Calculation is independent of Flex-Algorithm calculations for other data planes.

routing, ip

normative-requirement §6.4 MUST

When the OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is present, the NU-bit in the PrefixOptions field of the parent TLV MUST be set to prevent the advertisement from contributing to base algorithm reachability. If the NU-bit is not set, the sub-TLV MUST be ignored by the receiver.

routing, ip

protocol-element §5.1

The IS-IS IP Algorithm Sub-TLV (Type 29) is a sub-TLV of the IS-IS Router Capability TLV that advertises IP Flexible Algorithm participation. It contains a variable-length list of 1-octet Algorithm values, each in the range 128–255. Participation advertised here is topology-independent and applies to all topologies in which the advertising node participates.

routing, ip

protocol-element §5.2

The OSPF IP Algorithm TLV (Type 21) is a top-level TLV of the Router Information Opaque LSA that advertises IP Flexible Algorithm participation in OSPF. It contains a variable-length list of 1-octet Algorithm values (128–255) and MUST only be advertised once in the Router Information LSA.

routing, ip

protocol-element §6.3.1

The OSPFv2 IP Forwarding Address Sub-TLV (Type 7 of OSPFv2 Extended Prefix TLV) carries a 4-octet forwarding address for IP Algorithm Prefix reachability computation. It is optional; if absent, the forwarding address defaults to 0.0.0.0. It is only applicable to AS External and NSSA External route types.

routing, ip

registry §11

This document updates multiple IANA registries: adds IS-IS IP Algorithm Sub-TLV (29) to 'IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV'; adds OSPF IP Algorithm TLV (21) to 'OSPF Router Information (RI) TLVs'; adds IS-IS TLVs 126 (IPv4 Algorithm Prefix Reachability) and 127 (IPv6 Algorithm Prefix Reachability) to 'IS-IS Top-Level TLV Codepoints'; registers OSPFv2 Extended Prefix sub-TLV types 6 and 7; registers OSPFv3 Extended-LSA sub-TLV types 35 and 36; registers OSPFv2 Extended Inter-Area ASBR sub-TLV type 2; and creates new 'IP Algorithm Prefix Reachability Sub-TLV Flags' registry.

registry, routing, ip

security-consideration §12

An attacker can suppress reachability for a prefix that a legitimate node advertises under IP Flex-Algorithm X by advertising the same prefix under Flex-Algorithm Y from a malicious node, causing all such advertisements to be discarded (per the rule requiring consistent algorithm across originators). This attack is addressable by existing IGP authentication mechanisms (RFC 5304/5310 for IS-IS; RFC 2328/7474 for OSPFv2; RFC 4552/5340 for OSPFv3), but cannot be prevented if an authenticated node is compromised.

security, routing, ip

wire-format §5.1

IS-IS IP Algorithm Sub-TLV: Type (1 octet, value 29), Length (1 octet, variable), followed by n Algorithm fields (1 octet each, values 128–255). Carried as a sub-TLV of the IS-IS Router Capability TLV.

routing, ip

wire-format §6.1

IS-IS IPv4 Algorithm Prefix Reachability TLV (Type 126): TLV header with 4-bit Rsvd and 12-bit MTID, followed by per-prefix entries containing Metric (4 octets), Flags (1 octet with D-flag), Algorithm (1 octet, 128–255), Prefix Length (1 octet), Prefix (variable), and optional Sub-TLVs.

routing, ip

wire-format §6.3

OSPFv2 IP Algorithm Prefix Reachability Sub-TLV (Type 6 of OSPFv2 Extended Prefix TLV): Type (2 octets, value 6), Length (2 octets, value 8), MT-ID (1 octet), Algorithm (1 octet, 128–255), Flags (1 octet with E-bit), Reserved (1 octet), Metric (4 octets). Metric 0xFFFFFFFF indicates unreachable.

routing, ip

wire-format §6.4

OSPFv3 IP Algorithm Prefix Reachability Sub-TLV (Type 35 of OSPFv3 Extended-LSA): Type (2 octets, value 35), Length (2 octets, value 8), Algorithm (1 octet, 128–255), Reserved (3 octets), Metric (4 octets). Metric 0xFFFFFFFF indicates unreachable.

routing, ip