BIER WG Q. Xiong Internet-Draft ZTE Corporation Intended status: Standards Track G. Mirsky Expires: 2 April 2027 Ciena Corporation F. Hu Individual C. Liu China Unicom G. Mishra Individual 29 September 2026 BIER BFD draft-ietf-bier-bfd-12 Abstract Point-to-multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the application of P2MP BFD in BIER network. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 2 April 2027. Copyright Notice Copyright (c) 2026 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 Xiong, et al. Expires 2 April 2027 [Page 1] Internet-Draft BIER BFD September 2026 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 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 3. BIER BFD Encapsulation . . . . . . . . . . . . . . . . . . . 4 4. BIER BFD Session Bootstrapping . . . . . . . . . . . . . . . 5 4.1. Bootstrapping a BIER BFD Session Using BIER Ping . . . . 5 4.2. BGP Bootstrapping . . . . . . . . . . . . . . . . . . . . 6 5. Discriminators and Packet Demultiplexing . . . . . . . . . . 6 6. Active Tail Behavior in BIER BFD . . . . . . . . . . . . . . 7 6.1. Unsolicited Head Notification Mode . . . . . . . . . . . 7 7. Operational Considerations . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10.1. BIER OAM Message Type . . . . . . . . . . . . . . . . . 9 10.2. BFD Discriminator for a P2MP BFD Session with Active Tails Using Unsolicited Notification TLV . . . . . . . . . . . 9 10.3. BGP's BFD Discriminator Attribute Mode of P2MP BFD Session with Active Tails Using Unsolicited Notifications . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Bit Index Explicit Replication (BIER) provides efficient multicast forwarding without requiring per-flow state in the network. A BIER Forwarding Router (BFR) delivers packets to a set of receivers identified by the bitstring in the BIER header, enabling scalable multicast distribution across a domain. As BIER deployments grow, operators require mechanisms to verify continuity, detect failures, and assess reachability of multiple receivers in a BIER sub-domain. Xiong, et al. Expires 2 April 2027 [Page 2] Internet-Draft BIER BFD September 2026 Bidirectional Forwarding Detection (BFD) is widely used to provide rapid failure detection for unicast paths. Point-to-multipoint (P2MP) BFD, specified in [RFC8562], extends BFD to multipoint trees and allows a single head to monitor the liveness of multiple tails. In [RFC8562], the head transmits BFD Control packets to all tails, and each tail monitors the continuity of the path from the head. [RFC8562] does not define any mechanism for the head to learn about failures affecting individual tails; it only enables tails to detect loss of continuity from the head. [RFC8563] builds on [RFC8562] by defining several mechanisms that allow a tail to notify the head about failures affecting the path between the head and that specific tail. These mechanisms include unsolicited tail-to-head notifications and procedures for "active tails", enabling the head to correlate failures with individual receivers. Together, [RFC8562] and [RFC8563] provide a complete framework for multipoint continuity checking and failure reporting. This document specifies the procedures for transmitting P2MP BFD over BIER. It defines how a BIER head encapsulates BFD Control packets, how tails demultiplex and process them, and how unsolicited notifications defined in [RFC8563] may be sent from tails to the head. The document also describes bootstrapping mechanisms that allow tails to discover the BFD session parameters associated with a given BIER sub-domain and bitstring. The goal of this specification is to provide a lightweight and scalable continuity-checking mechanism for BIER paths, enabling operators to detect failures affecting any subset of receivers without introducing per-flow state in the network. The procedures defined here apply to any BIER deployment and do not require modifications to the BIER forwarding architecture. 2. Conventions used in this document 2.1. Terminology This document uses the acronyms defined in [RFC8279] along with the following: BFD: Bidirectional Forwarding Detection. OAM: Operations, Administration, and Maintenance. P2MP: Point-to-Multipoint. Xiong, et al. Expires 2 April 2027 [Page 3] Internet-Draft BIER BFD September 2026 2.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. BIER BFD Encapsulation Figure 1 shows the encapsulation of a P2MP BFD Control packet in a BIER packet. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | BIFT-id | TC |S| TTL | B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I |Nibble | Ver | BSL | Entropy | E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R |OAM|Rsv| DSCP | Proto | BFIR-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H | BitString (first 32 bits) ~ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ a ~ ~ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e ~ BitString (last 32 bits) | r +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | Ver |MessageType| Proto | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F | My Discriminator | D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Your Discriminator | C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o | Desired Min TX Interval | n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t | Required Min RX Interval | r +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o | Required Min Echo RX Interval | l +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- Figure 1: BIER BFD Encapsulation BIER BFD encapsulation uses the BIER OAM packet format defined in [I-D.ietf-bier-ping]. The BitString identifies the set of tails that are expected to receive and process the BFD Control packet. The Xiong, et al. Expires 2 April 2027 [Page 4] Internet-Draft BIER BFD September 2026 value of the Message Type field MUST be set to BIER BFD (TBD1 will be assigned by IANA Section 10.1). The BFD Control packet, defined in Section 4 [RFC5880], immediately follows the BIER OAM header. The operation of Multipoint BFD with the BFD Control packet is described in [RFC8562]. 4. BIER BFD Session Bootstrapping As defined in [RFC8562], a BIER BFD session MAY be established to monitor the state of the multipoint path. The BIER BFD session could be created for each multipoint path and the set of BFERs over which the BFIR is requested to run BIER BFD. The BFIR, according to Section 5.7 of [RFC8562], MAY bootstrap the BFD session using a BIER OAM message (Section 4.1) or the control plane (Section 4.2). Either method MUST refer to the root of the multipoint path and the value of My Discriminator associated with the path to the set of BFERs. The BIER BFD bootstrapping MUST be repeated when the value of My Discriminator is changed. Also, a P2MP BFD session can be statically configured. 4.1. Bootstrapping a BIER BFD Session Using BIER Ping The BIER OAM can be used to bootstrap the BIER BFD session. The BFIR sends the BIER OAM Echo request message carrying a BFD discriminator TLV which immediately follows the Target SI-Bitstring TLV (Section 3.3.2 of [I-D.ietf-bier-ping]). The Target SI-Bitstring TLV MUST be used to carry the set of BFER information (including Sub-domain-id, Set ID, BS Len, Bitstring) for the purpose of the session establishment. Figure 2 displays the format of the BFD Discriminator for a P2MP BFD Session with Active Tails Using Unsolicited Notifications TLV. 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 = TBD2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: BFD Discriminator for a P2MP BFD Session with Active Tails Using Unsolicited Notifications TLV where: Xiong, et al. Expires 2 April 2027 [Page 5] Internet-Draft BIER BFD September 2026 * Type indicates BFD Discriminator for a P2MP BFD Session with Active Tails Using Unsolicited Notifications TLV. The value (TBD2) is to be allocated by IANA (Section 10.2). * Length MUST be set to 4. * My Discriminator - four-octet long field. The value is the local discriminator generated by BFIR for this session. This discriminator MUST be used as the My Discriminator field in the BIER BFD Control packets sent by the BFIR. 4.2. BGP Bootstrapping [RFC9026] describes the applicability of [RFC8562] in the detection of a Multicast Virtual Private Network. The new BGP Attribute, BFD Discriminator, can be used to bootstrap a P2MP BFD session according to [RFC8562]. To bootstrap a P2MP BFD session with active tails using unsolicited notifications according to [RFC9780], IANA is requested to allocate a new value (TBD3) for the BFD Mode (Section 10.3). 5. Discriminators and Packet Demultiplexing P2MP BFD modifies the demultiplexing rules defined in [RFC5880]. In [RFC5880], a received BFD packet is demultiplexed using the Your Discriminator field, which uniquely identifies the session at the receiver. In P2MP BFD ([RFC8562]), tails do not allocate discriminators and therefore cannot rely on Your Discriminator for demultiplexing. Instead, [RFC8562] defines that tails demultiplex packets using the My Discriminator field, which is assigned by the MultipointHead. Because the MultipointHead assigns the My Discriminator, it is not globally unique across all tails. Therefore, the discriminator alone is insufficient to identify a P2MP BFD session at a tail uniquely. [RFC8562] requires that tails select the correct session using the discriminator in combination with other context, and explicitly leaves the exact method of selection to the application: | “the session MUST be selected based on some combination of other | fields, possibly including source addressing information, the My | Discriminator field, and the interface over which the packet was | received. The exact method of selection is application specific | and is thus outside the scope of this specification.” In BIER, the value of the BFIR-id field (Figure 1) in the BIER header provides the additional context required by RFC 8562 for demultiplexing P2MP BFD sessions at the tail. Because the Xiong, et al. Expires 2 April 2027 [Page 6] Internet-Draft BIER BFD September 2026 MultipointHead assigns the My Discriminator and uniqueness is guaranteed only per head, the discriminator alone does not uniquely identify a session across all tails. The BFIR-id uniquely identifies the originating head within the BIER domain. Therefore, the tuple (BFIR-id, My Discriminator) uniquely identifies the P2MP BFD session at every tail. Tails MUST use this tuple as the demultiplexing key, consistent with the requirement in [RFC8562] that session selection use a combination of fields beyond the My Discriminator alone. 6. Active Tail Behavior in BIER BFD Active Tail behavior for P2MP BFD over BIER, as specified in this document, is based on the unsolicited notification mechanisms defined in [RFC9780], not on the solicited notification methods defined in [RFC8563]. In [RFC8563], the MultipointHead learns the state of the multicast distribution tree by explicitly querying tails; the tails respond to these queries, and the resulting messages are therefore solicited notifications. [RFC9780], in contrast, defines mechanisms by which an Active tail can independently detect failures and send unsolicited notifications to the head, without being queried. This document specifies the applicability of the [RFC9780] Active Tail mechanisms to P2MP BFD sessions transported over BIER. When P2MP BFD is transported over BIER, an Active tail: * Monitors continuity from the head using [RFC8562] procedures. * Identifies the session using the tuple (BFIR-id, My Discriminator). * Upon detecting a failure, sends an unsolicited notification toward the head using the mechanisms defined in [RFC9780]. Note that a unicast message must be sent over a path which is disjoint from the multicast distribution tree 6.1. Unsolicited Head Notification Mode [RFC9780] provides detailed information on using the unsolicited notification method for P2MP MPLS LSP, which is also applicable to BIER. Xiong, et al. Expires 2 April 2027 [Page 7] Internet-Draft BIER BFD September 2026 In Section 5.2.1 [RFC8563] it is noted that "the tail sends unsolicited BFD packets in response to the detection of a multipoint path failure" but without the specifics on the information in the packet and frequency of transmissions. This document defines the procedure of the active tail with unsolicited notifications for BIER as specified below. Upon detecting the failure, a BFER sends a BFD Control packet with the following settings: * the Poll (P) bit MUST be set; * the Status (Sta) field MUST be set to the Down value; * the Diagnostic (Diag) field MUST be set to Control Detection Time Expired value; * the value of the Your Discriminator field MUST be set to the My Discriminator value associated with the failed P2MP BFD session; * BFD Control packet MUST use IP/UDP encapsulation with the destination IP address of the BFIR and the UDP destination port number set to 4784 per [RFC5883] * the BFD Control packets MUST be transmitted at the rate of one per second until either the BFER receives a valid for this BFD session control packet with the Final (F) bit is set from the BFIR or the defect condition clears. To improve the likelihood of notifying the BFIR of the failure, the BFER SHOULD transmit three BFD Control packets defined above in pseudo-random intervals between packets within a one-second interval. A BFIR that has received the BFD Control packet demultiplexes BFD sessions as defined in [RFC5880], i.e., based on the value in Your Discriminator field. After the BFIR matches the received BFD Control Packet to the BFD session, it sends the unicast IP/UDP encapsulated BFD Control packet with the Final (F) bit set to the BFER. 7. Operational Considerations Operational considerations formulated in Section 6 of [RFC8562], Section 8 of [RFC8563], and in [I-D.ietf-bier-ping] apply to BIER BFD. Xiong, et al. Expires 2 April 2027 [Page 8] Internet-Draft BIER BFD September 2026 8. Security Considerations This document inherits all security considerations from [RFC5880], [RFC8562], [RFC8563], and [I-D.ietf-bier-ping]. A single failure could affect a significant number of BFERs, thus causing a spike in the number of BFD Control packets with notifications, as defined in Section 6.1. To mitigate the overloading of the control plane, an implementation MUST control the number of BFD Control packets passed to the control plane for processing. 9. Acknowledgments The authors would like to thank the comments and suggestions from Sandy Zhang, Jeffrey (Zhaohui) Zhang, Donald Eastlake 3rd, Reshad Rahman, and Les Ginsberg. 10. IANA Considerations 10.1. BIER OAM Message Type IANA is requested to assign a new type from the BIER OAM Message Type registry in the BIER OAM registry group as follows: +=======+=============+=================+ | Value | Description | Reference | +=======+=============+=================+ | TBD1 | BIER BFD | [this document] | +-------+-------------+-----------------+ Table 1 10.2. BFD Discriminator for a P2MP BFD Session with Active Tails Using Unsolicited Notification TLV IANA is requested to assign a new type from the TLVs registry in the BIER OAM registry group as follows: +=======+==================================+===========+ | Value | Description | Reference | +=======+==================================+===========+ | TBD2 | BFD Discriminator for a P2MP BFD | [this | | | Session with Active Tails Using | document] | | | Unsolicited Notification TLV | | +-------+----------------------------------+-----------+ Table 2 Xiong, et al. Expires 2 April 2027 [Page 9] Internet-Draft BIER BFD September 2026 10.3. BGP's BFD Discriminator Attribute Mode of P2MP BFD Session with Active Tails Using Unsolicited Notifications IANA is requested to assign a new value from "BFD Mode" subregistry (defined in [RFC9026]) in the Border Gateway Protocol (BGP) Parameters registry according to Table 3: +=======+====================================+===========+ | Value | Description | Reference | +=======+====================================+===========+ | TBD3 | P2MP BFD Session with Active Tails | [this | | | Using Unsolicited Notifications | document] | +-------+------------------------------------+-----------+ Table 3 11. References 11.1. Normative References [I-D.ietf-bier-ping] Nainar, N. K., Pignataro, C., Chen, M., and G. Mirsky, "Bit Index Explicit Replication (BIER) Ping and Trace", Work in Progress, Internet-Draft, draft-ietf-bier-ping-29, 19 September 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, June 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Xiong, et al. Expires 2 April 2027 [Page 10] Internet-Draft BIER BFD September 2026 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, . [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, Ed., "Bidirectional Forwarding Detection (BFD) for Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, April 2019, . [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, Ed., "Bidirectional Forwarding Detection (BFD) Multipoint Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, . [RFC9026] Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed., "Multicast VPN Fast Upstream Failover", RFC 9026, DOI 10.17487/RFC9026, April 2021, . [RFC9780] Mirsky, G., Mishra, G., and D. Eastlake 3rd, "Bidirectional Forwarding Detection (BFD) for Multipoint Networks over Point-to-Multipoint MPLS Label Switched Paths (LSPs)", RFC 9780, DOI 10.17487/RFC9780, May 2025, . Authors' Addresses Quan Xiong ZTE Corporation China Email: xiong.quan@zte.com.cn Greg Mirsky Ciena Corporation Email: gregimirsky@gmail.com, gmirsky@ciena.com Fangwei Hu Individual Email: hufwei@163.com Chang Liu China Unicom No.9 Shouti Nanlu Xiong, et al. Expires 2 April 2027 [Page 11] Internet-Draft BIER BFD September 2026 Beijing 100048 China Phone: +86-010-68799999-7294 Email: liuc131@chinaunicom.cn Gyan Mishra Individual Email: hayabusagsm@gmail.com Xiong, et al. Expires 2 April 2027 [Page 12]