BGP Extensions for Bit Index Explicit Replication (BIER)
Extracted elements (24)
BIFT-id ranges may overlap across different encapsulation types (MPLS vs. non-MPLS) because the forwarding context distinguishes them; only overlaps within the same encapsulation type on the same BFR are prohibited as they would cause ambiguity.
The BIER Nexthop sub-TLV allows a re-advertising BFR to insert itself as the next hop for BIER traffic, enabling BIER traffic to flow through the BFR rather than requiring a tunnel all the way to the BFER. Without the sub-TLV, the receiving BFR must tunnel BIER traffic to the BIER prefix directly.
A non-BFR BGP speaker that does not understand BIER will re-advertise the route with the BIER attribute unchanged (since it is optional transitive), without performing any BIER-specific action. The receiving BFR will then tunnel BIER traffic to the BIER prefix, bypassing the non-BFR speaker.
A BFER MUST attach a BIER attribute to its own /32 or /128 host BFR-prefix NLRI, including one BIER TLV for each supported sub-domain with an MPLS and/or non-MPLS Encapsulation sub-TLV.
A boundary router of the AD that supports the BIER attribute MUST support a policy (based on EBGP session/group) controlling whether the attribute is allowed outbound; by default it is NOT allowed. If not allowed, the BIER attribute MUST NOT be sent to EBGP peers, and any received BIER attribute MUST be quietly ignored and not passed to other BGP peers.
BIFT-id ranges within all BIER non-MPLS Encapsulation sub-TLVs advertised by the same BFR MUST NOT overlap. If an overlap is detected, all such sub-TLVs MUST be ignored. Overlap across different encapsulation types (MPLS vs. non-MPLS) is allowed.
If syntactic checking of the BIER attribute fails (total TLV lengths do not match attribute/TLV length fields), the attribute is considered malformed and the 'attribute discard' action per RFC 7606 MUST be taken.
If the label associated with the Maximum SI exceeds the 20-bit range, the BIER MPLS Encapsulation sub-TLV containing the error MUST be ignored. If the same BitString length is repeated in multiple BIER MPLS Encapsulation sub-TLVs inside the same BIER TLV, all such sub-TLVs MUST be ignored.
Label ranges within all BIER MPLS Encapsulation sub-TLVs advertised by the same BFR MUST NOT overlap. If an overlap is detected, all BIER MPLS Encapsulation sub-TLVs advertised by the BFR MUST be ignored.
The BIER Nexthop sub-TLV MUST NOT be included more than once in each MPLS or non-MPLS Encapsulation sub-TLV or in the top-level BIER TLV.
There MUST be no more than one BIER TLV with the same Sub-domain value in a BIER path attribute; if there is, the entire BIER path attribute MUST be ignored.
Two different BFR-prefixes MUST NOT have the same non-zero BFR-ID in the same sub-domain. If duplication is detected, the receiving BFR MUST NOT use those BFR-prefixes for BIFT calculation, and an error SHOULD be logged.
Unknown and unsupported TLV types MUST be preserved and propagated within the BIER attribute. The presence of unknown or unexpected TLVs MUST NOT result in the NLRI or the BIER attribute being considered malformed.
When creating a BIER attribute, a BFR MUST include one BIER TLV for every sub-domain that the prefix belongs to.
When re-advertising a BIER prefix, a BFR SHOULD set/update the BIER Nexthop sub-TLV to its own BIER prefix; if it does so, it MUST replace the encapsulation sub-TLV with its own. If it does not update the Nexthop, it MUST NOT update the encapsulation sub-TLV.
BIFT calculation: for each sub-domain, a BFR creates BIFT entries by iterating BIER prefixes with a matching BIER TLV. The BFR-NBR is taken from the BIER Nexthop sub-TLV (in the encapsulation sub-TLV, then the top-level BIER TLV, or defaults to the BIER prefix itself). The BIER label or BIFT-id is derived from the encapsulation sub-TLV's range.
The BIER attribute is an optional, transitive BGP path attribute with type code 41 and variable length. It is attached to BGP UPDATE messages for NLRIs of AFI 1 or 2 and SAFI 1, 2, or 4 to convey BIER-specific information (BFR-ID, BSL, encapsulation) for /32 or /128 host address prefixes.
IANA assigned codepoint 41 to the BIER attribute in the 'BGP Path Attributes' registry. A new 'BGP BIER TLV and Sub-TLV Types' registry was created under the BGP Parameters registry group with a 2-octet type field (values 0–65535, 0 reserved), allocated First Come First Served. Initial values: 0=Reserved, 1=BIER TLV, 2=MPLS Encapsulation sub-TLV, 3=non-MPLS Encapsulation sub-TLV, 4=BIER Nexthop sub-TLV.
Leaking the BIER attribute across AD boundaries can incorrectly merge two independent BIER domains that may have conflicting configurations, creating security risks and operational trouble. The document addresses this by requiring boundary routers to suppress the BIER attribute on EBGP sessions by default.
This document introduces no new security considerations beyond those in RFC 4271 (BGP-4) and RFC 8279 (BIER), plus the operational considerations in Section 7 regarding BIER attribute leakage across administrative domain boundaries.
BIER TLVs within the BIER attribute are encoded as Type (2 octets), Length (2 octets), Value (variable). TLVs are not padded to 4-octet alignment. The BIER TLV (Type=1) contains Sub-domain (1 octet), BFR-ID (2 octets), Reserved (1 octet), and Sub-TLVs.
The BIER MPLS Encapsulation sub-TLV (Type=2) encodes Max SI (1 octet), BS Len (4 bits), and Label (20 bits), optionally followed by sub-TLVs. The label range starts at Label and ends at Label + Max SI, with one label per Set Identifier.
The BIER Nexthop sub-TLV (Type=4) encodes a Nexthop field of 4 octets (IPv4) or 16 octets (IPv6), indicated by a Length of 4 or 16 respectively. It specifies the BFR neighbor address used in BIFT entry calculation.
The BIER non-MPLS Encapsulation sub-TLV (Type=3) encodes Max SI (1 octet), BS Len (4 bits), and BIFT-id (20 bits). The BIFT-id range starts at BIFT-id and ends at BIFT-id + Max SI, providing one BIFT-id per Set Identifier for non-MPLS BIER forwarding.