Bit Index Explicit Replication (BIER) Support via IS-IS
updated by
- rfc-9272 — Underlay Path Calculation Algorithm and Constraints for Bit Index Explicit Replication (BIER)
Extracted elements (27)
BIER information is tied to host prefixes (node addresses) rather than any prefix, ensuring each advertisement is unambiguously associated with a specific BFR node. Advertisements for non-host prefixes are ignored to prevent misuse.
BIER subdomains are each associated with a single IS-IS topology (MT), allowing BIER to leverage existing IS-IS multi-topology mechanisms for traffic engineering or IPv6 separation without requiring a new topology construct.
The IS-IS BIER extensions are aligned with OSPFv2 Extensions for BIER where protocol mechanisms overlap, facilitating consistent multi-IGP deployment of BIER domains.
This document defines support only for MPLS encapsulation as specified in RFC 8296. Support for other encapsulation types and multiple encapsulation types are explicitly outside the scope of this document.
A router receiving an <MT,SD> advertisement that does not match its locally configured pair MUST report a misconfiguration and MUST ignore all received BIER advertisements associated with the conflicting <MT,SD> pair.
A valid BFR-id MUST be unique within the flooding scope. All BFERs/BFIRs MUST detect duplicate valid BFR-IDs for a given <MT,SD>; when detected, all advertising routers MUST be treated as if they did not advertise a valid BFR-id.
BIER information MUST be associated with a host prefix that is a node address for the advertising node. Prefix length MUST be 32 for IPv4 or 128 for IPv6; otherwise the advertisement MUST be ignored.
If an implementation does not support non-zero values in the BAR or IPA fields but receives such values, it SHOULD treat the advertising router as incapable of supporting BIER.
If the label associated with the Maximum Set Identifier exceeds the 20-bit range, the BIER MPLS Encapsulation sub-sub-TLV MUST be ignored.
If the same BitString length is repeated in multiple BIER MPLS Encapsulation sub-sub-TLVs inside the same BIER Info sub-TLV, the entire BIER Info sub-TLV MUST be ignored.
Implementations SHOULD protect against excessive BIER advertisement changes by dampening updates if they occur over an extended period of time, to reduce LSP update storms.
Label ranges within all BIER MPLS Encapsulation sub-sub-TLVs across all BIER Info sub-TLVs advertised by the same BFR MUST NOT overlap. If overlap is detected, the advertising router MUST be treated as if it did not advertise any BIER sub-TLVs.
Label values in the BIER MPLS Encapsulation sub-sub-TLV MUST NOT match any of the reserved values defined in RFC 3032 (MPLS Label Stack Encoding).
The mapping of BIER subdomains to IS-IS topologies MUST be consistent within the IS-IS flooding domain. All routers in the flooding scope MUST advertise the same subdomain within the same multi-topology.
When the Prefix Attributes Flags sub-TLV is present, the N flag MUST be set and the R flag MUST NOT be set in BIER advertisements. BIER sub-TLVs MUST be included when a prefix reachability advertisement is leaked between levels.
Whenever an advertisement violates any constraint defined in this document, the receiving router MUST support logging this occurrence. Logging SHOULD be dampened to avoid excessive output.
The BIER Info sub-TLV (type value 32) is advertised within IS-IS extended reachability TLVs 135, 235, 236, and 237. It carries BIER subdomain information for routers participating as BFRs and may appear multiple times per prefix-reachability TLV, once per supported subdomain.
The BIER MPLS Encapsulation sub-sub-TLV (type 1) is advertised within the BIER Info sub-TLV and carries MPLS label range information for a specific BitString length within a given <MT,SD>. It may appear multiple times within a single BIER Info sub-TLV.
The Max SI field in the BIER MPLS Encapsulation sub-sub-TLV specifies the maximum Set Identifier for the encapsulation. Each SI maps to a single label in the label range, starting from SI=0 at the first label.
A new 'BIER Algorithms' registry is created within the BIER registry. Registration policies: Standards Action for 0-127, Specification Required for 128-239, Experimental Use for 240-254. Initial values: 0 = no BIER-specific algorithm, 255 = Reserved.
A new 'Sub-sub-TLVs for BIER Info Sub-TLV' registry is created within the IS-IS TLV Codepoints registry with Expert Review policy. Initial value: type 1 = BIER MPLS Encapsulation.
This document adds value 32 (BIER Info) to the 'Sub-TLVs for TLVs 135, 235, 236, and 237' registry in the IS-IS TLV Codepoints registry.
An attack on the IS-IS BIER control plane cannot cause a BitString DoS attack because BFIRs independently decide which bits to set in encapsulations and are not influenced by IS-IS BIER advertisements. The IS-IS advertisements only inform forwarding table construction, not bit selection.
BIER forwarding ensures each transmitted replica of a received packet has fewer bits set than the received packet (each bit appears in only one copy), preventing packet amplification via the IS-IS control plane. A failure of this property cannot be caused by IS-IS control plane attacks.
General IS-IS security concerns are addressed by RFC 5304 (IS-IS Cryptographic Authentication) and RFC 5310 (IS-IS Generic Cryptographic Authentication), which apply to the BIER extensions defined here.
The BIER Info sub-TLV encodes: Type (1 octet), Length (1 octet, variable), BAR/BIER Algorithm (1 octet), IPA/IGP Algorithm (1 octet), subdomain-id (1 octet), BFR-id (2 octets), followed by variable-length sub-sub-TLVs.
The BIER MPLS Encapsulation sub-sub-TLV (type 1) has a fixed length of 4 octets encoding: Max SI (1 octet), BS Len/Local BitString Length (4 bits), and Label/first label of range (20 bits).