BIER BFD

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 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

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.¶

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 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¶

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.¶

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

Authors' Addresses