rfc-9351

Border Gateway Protocol - Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement

K. Talaulikar (Editor), P. Psenak, S. Zandi, G. Dawra
date2023-02 streamIETF areartg wgidr statusPROPOSED STANDARD pages14 canonicalhttps://www.rfc-editor.org/rfc/rfc9351 doi10.17487/RFC9351
Flexible Algorithm is a solution that allows some routing protocols (e.g., OSPF and IS-IS) to compute paths over a network based on user-defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distributed manner using a Flexible Algorithm Definition (FAD). This definition is provisioned on one or more routers and propagated through the network by OSPF and IS-IS flooding. Border Gateway Protocol - Link State (BGP-LS) enables the collection of various topology information from the network. This document defines extensions to the BGP-LS address family to advertise the FAD as a part of the topology information from the network.

Extracted elements (25)

design-rationale §1

BGP-LS advertisement of FAD information enables cross-domain SR Policy path construction by allowing a controller to learn the mapping of Flexible Algorithm numbers to their definitions across IGP areas/domains, and then select algorithm-specific SIDs (Prefix-SIDs for SR-MPLS or End SIDs for SRv6) at ABRs/ASBRs.

routing, bgp

design-rationale §2

FAD information is advertised as a node-level BGP-LS attribute (with the Node NLRI) because the FAD is a per-node advertisement in IS-IS and OSPF, while the Flexible Algorithm Prefix Metric is a prefix attribute (with the Prefix NLRI), reflecting the different scopes of these objects in IGP.

routing, bgp

design-rationale §3.6

The Flexible Algorithm Unsupported sub-TLV was introduced because, unlike most protocol extensions where unknown sub-TLVs can be silently skipped, the entire FAD must be understood by anyone using it for computation (per RFC 9350 Section 5.3). This makes incomplete FAD advertisement more dangerous than typical unknown-TLV scenarios.

routing, bgp

interoperability-note §2

Link attributes used in Flexible Algorithm computation (affinities, SRLG) are advertised via BGP-LS Application-Specific Link Attribute (ASLA) advertisements as specified in RFC 9294; this document covers only the FAD and FAPM node/prefix attributes.

routing, bgp

interoperability-note §3

The FAD TLV advertised in BGP-LS is derived from the IS-IS Flexible Algorithm Definition sub-TLV or the OSPFv2/OSPFv3 Flexible Algorithm Definition TLV, both as defined in RFC 9350. A single Node NLRI BGP-LS Attribute may include multiple FAD TLVs, one per algorithm the node advertises.

routing, bgp

interoperability-note §4

The FAPM TLV is derived from the IS-IS Flexible Algorithm Prefix Metric sub-TLV or the OSPFv2/OSPFv3 Flexible Algorithm Prefix Metric sub-TLV defined in RFC 9350. The Flags field semantics differ between protocols: it is meaningful for OSPF and must be zeroed for IS-IS.

routing, bgp

normative-requirement §4 MUST

In the FAPM TLV, the Flags field MUST be set to 0 for IS-IS (it is only applicable for OSPF). The Reserved field MUST be set to 0 by the originator and MUST be ignored by the receiver.

routing, bgp

normative-requirement §3.6 RECOMMENDED

It is RECOMMENDED that the choice of the node used for originating IGP topology information into BGP-LS be made such that the advertising node supports all FAD extensions in use in its part of the network, to avoid advertising an incomplete FAD.

routing, bgp

normative-requirement §3 MUST

The Length field of the FAD TLV MUST be 4 or larger, covering the four fixed octets (Flex Algo, Metric-Type, Calc-Type, Priority) plus any sub-TLVs.

routing, bgp

normative-requirement §3.6 MUST

The node originating the BGP-LS advertisement MUST include the Flexible Algorithm Unsupported sub-TLV when it encounters an unsupported sub-TLV in the corresponding FAD in the IS-IS or OSPF advertisement.

routing, bgp

normative-requirement §3.6 SHOULD

When advertising the Flexible Algorithm Unsupported sub-TLV, the protocol-specific sub-TLV types that are not supported SHOULD be included as a diagnostic aid.

routing, bgp

protocol-element §3.4

The Flexible Algorithm Definition Flags sub-TLV (Type 1043) carries a variable-length bitmask of flags associated with the FAD computation, as defined in RFC 9350. Its Length MUST be a non-zero multiple of 4 octets.

routing, bgp

protocol-element §3

The Flexible Algorithm Definition TLV (FAD TLV, Type 1039) is a new optional BGP-LS Attribute TLV associated with the Node NLRI. It carries the Flexible Algorithm number (128–255), Metric-Type, Calc-Type, Priority, and zero or more sub-TLVs defining the algorithm's computation constraints.

routing, bgp

protocol-element §3.1

The Flexible Algorithm Exclude-Any Affinity sub-TLV (Type 1040) carries Extended Admin Group (EAG) values specifying link affinities to exclude from computation. Its Length MUST be a non-zero multiple of 4 octets.

routing, bgp

protocol-element §3.5

The Flexible Algorithm Exclude SRLG sub-TLV (Type 1045) carries one or more 4-octet SRLG values; links associated with any listed SRLG are excluded from the algorithm's computation. Its Length MUST be a non-zero multiple of 4 octets.

routing, bgp

protocol-element §3.3

The Flexible Algorithm Include-All Affinity sub-TLV (Type 1042) carries EAG values specifying that only links carrying all of the listed affinities are eligible for the algorithm's computation. Its Length MUST be a non-zero multiple of 4 octets.

routing, bgp

protocol-element §3.2

The Flexible Algorithm Include-Any Affinity sub-TLV (Type 1041) carries EAG values specifying that links with any of the listed affinities are eligible for inclusion in the algorithm's computation. Its Length MUST be a non-zero multiple of 4 octets.

routing, bgp

protocol-element §4

The Flexible Algorithm Prefix Metric TLV (FAPM TLV, Type 1044) is a new optional BGP-LS Attribute TLV associated with the Prefix NLRI. It carries the Flex Algo number, Flags (OSPF only), a Reserved field, and a 4-octet Metric. A Prefix NLRI may include one or more FAPM TLVs for different algorithms.

routing, bgp

protocol-element §3.6

The Flexible Algorithm Unsupported sub-TLV (Type 1046) signals that the originating BGP-LS node encountered one or more FAD sub-TLVs in the IGP advertisement that it does not support. It carries a Protocol-ID octet and zero or more unsupported sub-TLV type codes.

routing, bgp

registry §5

IANA allocated code points 1039–1046 in the 'BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs' registry for: FAD TLV (1039), Exclude-Any Affinity (1040), Include-Any Affinity (1041), Include-All Affinity (1042), Definition Flags (1043), Prefix Metric (1044), Exclude SRLG (1045), and Unsupported (1046).

registry, bgp, routing

security-consideration §7

Security considerations for acquiring and distributing BGP-LS information follow RFC 7752. It is assumed that the IGP instances originating FAD TLVs will support all required security for Flexible Algorithm deployment as described in RFC 9350.

security, routing, bgp

security-consideration §7

Tampering with the Flexible-Algorithm-related BGP-LS information (FAD TLV and FAPM TLV) may affect applications using it, including impacting route calculation and programming. The impact is scoped to the specific Flexible Algorithm topology, limiting the blast radius.

security, routing, bgp

wire-format §3

The FAD TLV encodes: Type (2 octets, value 1039), Length (2 octets, MUST be 4 or larger), Flex Algo (1 octet, 128–255), Metric-Type (1 octet), Calc-Type (1 octet), Priority (1 octet), followed by variable-length sub-TLVs.

routing, bgp

wire-format §4

The FAPM TLV encodes: Type (2 octets, value 1044), Length (8 octets), Flex Algo (1 octet, 128–255), Flags (1 octet, applicable to OSPF only; MUST be 0 for IS-IS), Reserved (2 octets, MUST be set to 0 by originator and MUST be ignored by receiver), Metric (4 octets).

routing, bgp

wire-format §3.6

The Flexible Algorithm Unsupported sub-TLV encodes: Type (2 octets, value 1046), Length (variable), Protocol-ID (1 octet identifying the BGP-LS source protocol), followed by zero or more sub-TLV type codes whose size depends on the protocol (1 octet for IS-IS, 2 octets for OSPF).

routing, bgp