Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9793.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

2. Terminology

This document makes use of the terminology defined in [RFC4271] and [RFC8279]. Some terms are listed below for convenience.¶

BIER:

Bit Indexed Explicit Replication¶

BFR:

Bit-Forwarding Router¶

BFR-ID:

BFR Identifier¶

BSL:

BitStringLength¶

BIFT:

Bit Index Forwarding Table¶

BIFT-id:

Bit Index Forwarding Table Identifier¶

BFER:

Bit-Forwarding Egress Router¶

BFR-prefix:

Each BFR is assigned a single "BFR-prefix" for each sub-domain to which it belongs. It is recommended that the BFR-prefix be a loopback address of the BFR.¶

NLRI:

Network Layer Reachability Information [RFC4271]¶

AFI:

Address Family Identifier [RFC4760]¶

SAFI:

Subsequent Address Family Identifier [RFC4760]¶

3. BIER Path Attribute

This specification defines an optional, transitive BGP path attribute, referred to as the "BIER attribute". This attribute can be attached to a BGP UPDATE message by the originator for NLRIs of AFI 1 or 2 and SAFI 1, 2, or 4 to indicate the BIER-specific information of a particular BFR identified by the /32 (for IPv4) or /128 (for IPv6) host address prefix contained in the NLRI. The attachment of the BIER attribute to non-host address prefixes is not defined by this document. It may be specified in the future, for example, by [BIER-Prefix-Redistribute].¶

If the BIER path attribute is present, the NLRI is referred to as a "BFR-prefix". Use of the attribute with other AFIs/SAFIs is outside the scope of this document.¶

The BIER path attribute is an optional, transitive BGP path attribute with type code 41 and of variable length. The attribute value portion carries BIER TLVs, which are encoded as follows:¶

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Type             |             Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                        Value (variable)                       ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Length field defines the length of the value portion in octets (thus, a TLV with no value portion would have a length of zero). The TLV is not padded to 4-octet alignment. Unknown and unsupported 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. The attribute type code for the BIER attribute is 41. The value field of the BIER attribute contains one or more BIER TLVs as shown below:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type = 1            |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-domain   |            BFR-ID             |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   |                           Sub-TLVs                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................

Type:

1¶

Length:

2 octets encoding the length in octets of the Value part.¶

Sub-domain:

A 1-octet field encoding the sub-domain ID corresponding to the BFR-ID (see [RFC8279]).¶

BFR-ID:

A 2-octet field encoding the BFR-ID (see [RFC8279]).¶

Reserved:

SHOULD be set to 0 on transmission and MUST be ignored on reception.¶

Sub-TLVs:

Contains one or more sub-TLVs.¶

The BIER TLV MAY appear multiple times in the BIER path attribute, one for each sub-domain. There MUST be no more than one BIER TLV with the same Sub-domain value; if there is, the entire BIER path attribute MUST be ignored.¶

A BIER TLV may have sub-TLVs, which may have their own sub-TLVs. All those are referred to as sub-TLVs and share the same Type space, regardless of the level.¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type = 2            |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Max SI    |BS Len |             Label                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        sub-TLVs                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type = 3            |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Max SI    |BS Len |                  BIFT-id              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        sub-TLVs                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type = 4           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Nexthop                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5. BIFT Calculation with BGP Signaling

As pointed out in [RFC8279], BIFTs are derived from the unicast FIB by adding BIER-specific information.¶

For each sub-domain, a BFR calculates the corresponding BIFTs by going through the BIER prefixes whose BIER attribute includes a BIER TLV for the sub-domain. For a non-zero BFR-id in the BIER TLV, a BIFT entry is created or updated. The entry's BFR Neighbor (BFR-NBR) [RFC8279] is the Nexthop in the BIER Nexthop sub-TLV in the corresponding MPLS Encapsulation sub-TLV or in the top-level BIER TLV if the MPLS Encapsulation sub-TLV does not have a BIER Nexthop sub-TLV. If there is no BIER Nexthop sub-TLV at all, the entry's BFR-NBR is the BIER prefix itself. The BIER label or BIFT-id for the entry is derived from the label range in the MPLS Encapsulation sub-TLV or from the BIFT-id range in the non-MPLS Encapsulation sub-TLV.¶

BIER traffic is sent to the BFR-NBR either directly (BIER header directly follows a Layer 2 header) if the BFR-NBR is directly connected or via a tunnel. Notice that, if a non-BFR BGP speaker re-advertises a BIER prefix (in this case, it cannot update the BIER attribute since it is not capable), or if a BFR BGP speaker re-advertises a BIER prefix without updating the BIER Nexthop sub-TLV, the BFR receiving the prefix will tunnel BIER traffic -- the BGP speaker re-advertising the BIER prefix will not see the BIER traffic for the BIER prefix.¶

How the tunnel is set up and chosen is outside the scope of this document. It can be any kind of tunnel, e.g., MPLS Label Switched Path or IP/GRE, as long as the tunnel header can indicate that the payload is BIER.¶

6. Example of BIER Nexthop Usage and Handling

Consider a simple topology as follows:¶

                                      ----- BFER1
                                     /
           BFR1 --- non-BFR --- BFR2 ------ BFER2
                                     \
                                      ----- BFER3

The BFER1/2/3 each advertises a route for its loopback address with a BIER path attribute, listing one BIER TLV for each sub-domain that it is in, with a non-zero BFR-ID and an MPLS Encapsulation sub-TLV. A BIER Nexthop sub-TLV is not included in the one from BFER1 but is included in the ones from BFER2/3. The BIER Nexthop sub-TLV encodes the BFR-prefix of BFER2 and BFER3, respectively.¶

When BFR2 receives the route, it calculates its BIFT entries. Because the route from BFER1 does not include a BIER Nexthop, BFR2 uses BFR1's BFR-prefix as the next hop.¶

When BFR2 re-advertises the routes to the non-BFR, it adds a BIER Nexthop sub-TLV to the BFER1 route and updates the BIER Nexthop sub-TLV in the BFER2/3 routes, all encoding BFR2's own address. It also updates the MPLS Encapsulation sub-TLV to encode its own labels.¶

When the non-BFR receives the routes, since it does not support BIER, no BIER-specific action is taken and the routes are re-advertised to BFR1 with the BIER path attribute unchanged.¶

When BFR1 receives the routes, it calculates the BIFT entries, using BFR2's address encoded in the BIER Nexthop sub-TLV as the next hop. Because BFR2 is not directly connected, a tunnel must be used.¶

7. Operational Considerations

In this document, it is assumed that the BIER domain [RFC8279] is aligned with an Administrative Domain (AD), which may be composed of multiple Autonomous Systems. Use of the BIER attribute in other scenarios is outside the scope of this document.¶

BFR-prefixes are typically loopback addresses on the BFRs. They are distributed throughout the AD, but they do not need to be distributed outside the AD for the BIER's purposes. This is analogous to the Provider Edge router's loopback addresses that are distributed inside the AD, but they do not need to be distributed outside the AD.¶

If prefixes are distributed outside of the AD with the BIER attribute attached and the neighboring AD also deploying BIER, then the two BIER domains, which should be independent of each other, may be incorrectly joined together and most likely have conflicting configurations, causing security risks and operational troubles.¶

To prevent that, a boundary router of the AD that supports the BIER attribute MUST support a policy based on an External BGP (EBGP) session/group that indicates whether the attribute is allowed; by default, it is NOT allowed. If it is not allowed, the BIER attribute MUST NOT be sent to any EBGP peer of the session/group. If a BIER attribute is received from the peer, it MUST be treated exactly as if it were an unrecognized non-transitive attribute. That is, it MUST be quietly ignored and not passed along to other BGP peers.¶

8. IANA Considerations

IANA has assigned codepoint 41 to the BIER attribute in the "BGP Path Attributes" registry <https://www.iana.org/assignments/bgp-parameters> as follows:¶

IANA has created the "BGP BIER TLV and Sub-TLV Types" registry within the "Border Gateway Protocol (BGP) Parameters" registry group. The type field for the registry consists of 2 octets, with possible values from 0 to 65535 (the value 0 is reserved). The allocation policy for this field is First Come First Served [RFC8126].¶

The five initial values have been allocated as follows:¶

9. Security Considerations

This document introduces no new security considerations beyond those already discussed in [RFC4271], [RFC8279], and the operational considerations (Section 7) of this document.¶

Acknowledgements

Thanks to Eric Rosen and Peter Psenak for their valuable comments on this document.¶

Authors' Addresses