Network Work group                                              N. KumarInternet-Draft                                       Cisco Systems, Inc.Intended status: Standards Track                            C. PignataroExpires: 11 July 2026                    North Carolina State University                                                                 M. Chen                                                     Huawei Technologies                                                               G. Mirsky                                                                Ericsson                                                          7 January 2026          Bit Index Explicit Replication (BIER) Ping and Trace                        draft-ietf-bier-ping-18Abstract   Bit Index Explicit Replication (BIER) is a multicast forwarding   architecture designed to simplify and optimize multicast delivery.   This document describes the mechanism and basic BIER OAM packet   format that can be used to perform failure detection and isolation on   the BIER data plane without any dependency on other layers, like the   IP layer.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 11 July 2026.Copyright Notice   Copyright (c) 2026 IETF Trust and the persons identified as the   document authors.  All rights reserved.Kumar, et al.             Expires 11 July 2026                  [Page 1]Internet-Draft                  BIER Ping                   January 2026   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   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3   2.  Conventions used in this document . . . . . . . . . . . . . .   3     2.1.  Terminology and Acronyms  . . . . . . . . . . . . . . . .   4     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4   3.  BIER OAM  . . . . . . . . . . . . . . . . . . . . . . . . . .   5     3.1.  BIER OAM Message Format . . . . . . . . . . . . . . . . .   5     3.2.  BIER Echo Request/Reply Message Format  . . . . . . . . .   6     3.3.  Return Code . . . . . . . . . . . . . . . . . . . . . . .   8     3.4.  BIER OAM TLVs . . . . . . . . . . . . . . . . . . . . . .   9       3.4.1.  Original SI-BitString TLV . . . . . . . . . . . . . .  10       3.4.2.  Target SI-BitString TLV . . . . . . . . . . . . . . .  11       3.4.3.  Incoming SI-BitString TLV . . . . . . . . . . . . . .  12       3.4.4.  Downstream Mapping TLV  . . . . . . . . . . . . . . .  13       3.4.5.  Responder BFER TLV  . . . . . . . . . . . . . . . . .  16       3.4.6.  Responder BFR TLV . . . . . . . . . . . . . . . . . .  17       3.4.7.  Ingress Interface TLV . . . . . . . . . . . . . . . .  17       3.4.8.  Erroneous Echo Request TLV  . . . . . . . . . . . . .  18   4.  BIER Ping and Traceroute Operations . . . . . . . . . . . . .  19     4.1.  BIER OAM Processing . . . . . . . . . . . . . . . . . . .  19     4.2.  Per BFER ECMP Discovery . . . . . . . . . . . . . . . . .  19     4.3.  Sending BIER Echo Request . . . . . . . . . . . . . . . .  20     4.4.  Receiving BIER Echo Request . . . . . . . . . . . . . . .  21     4.5.  Sending Echo Reply  . . . . . . . . . . . . . . . . . . .  23     4.6.  Receiving Echo Reply  . . . . . . . . . . . . . . . . . .  24   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25     5.1.  UDP Port Number . . . . . . . . . . . . . . . . . . . . .  25     5.2.  BIER OAM Registry Group . . . . . . . . . . . . . . . . .  25     5.3.  BIER OAM Message Type . . . . . . . . . . . . . . . . . .  25     5.4.  BIER Echo Request/Echo Reply Registries . . . . . . . . .  26       5.4.1.  BIER Echo Request/Echo Reply Message Types  . . . . .  26       5.4.2.  BIER Echo Reply Modes . . . . . . . . . . . . . . . .  27       5.4.3.  BIER Echo Return Codes  . . . . . . . . . . . . . . .  28     5.5.  Common Registration Procedures for TLVs and Sub-TLVs  . .  29       5.5.1.  TLVs  . . . . . . . . . . . . . . . . . . . . . . . .  30       5.5.2.  Sub-TLVs for TLV Type 4 . . . . . . . . . . . . . . .  31   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  32   7.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  32Kumar, et al.             Expires 11 July 2026                  [Page 2]Internet-Draft                  BIER Ping                   January 2026   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  33     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  33     8.2.  Informative References  . . . . . . . . . . . . . . . . .  34   Contributors' Addresses . . . . . . . . . . . . . . . . . . . . .  34   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  351.  Introduction   [RFC8279] introduces and explains BIER architecture that provides   optimal multicast forwarding through a "BIER domain" without   requiring intermediate routers to maintain any multicast-related per-   flow state.  BIER also does not require any explicit tree-building   protocol for its operation.  A multicast data packet enters a BIER   domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the   BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).   The BFIR router adds a BIER header to the packet.  The BIER header   contains a bit-string in which each bit represents exactly one BFER   to forward the packet to.  The set of BFERs to which the multicast   packet needs to be forwarded is specified by setting the bits that   correspond to those routers in the BIER header.  Similarly, the   Initiator of the BIER OAM packet controls the set of BFRs to which   the BIER OAM packet is addressed by setting bits in the BitString   field of the BIER header that correspond to the BFR-ID values of   those BFRs.   Operations, Administration, and Maintenance (OAM) mechanisms are   expected to support the detection of network failures.  After the   detection, operators localize and characterize the network defect.  A   query-based tool, e.g., ICMP [RFC0792] and LSP Ping [RFC8029],   [RFC6425], is broadly used to detect and localize a network defect.   Additionally, this mechanism can be used to check the consistency   between the data and control planes.  This document describes the   mechanism and basic BIER OAM packet format that can be used to   perform failure detection and isolation on the BIER data plane   without any dependency on other layers, like the IP layer.  The   specification conforms to R-1 through R-3, R-5, and R-11 requirements   listed in [I-D.ietf-bier-oam-requirements].  To conform to R-11, BIER   Echo Request message is encapsulated in the BIER header [RFC8296]   that uses the same values of BIFT-id, BSL, Entropy, and DSCP fields   as in the BIER header of the monitored BIER flow.  Note that the BIER   Echo Request/Reply protocol doesn't modify the content of the OAM   field in the BIER header (Section 2 of [RFC8296]).2.  Conventions used in this documentKumar, et al.             Expires 11 July 2026                  [Page 3]Internet-Draft                  BIER Ping                   January 20262.1.  Terminology and Acronyms   In this specification, the term "Initiator" is used interchangeably   with the "Sender of a BIER Echo Request".   BFER - Bit-Forwarding Egress Router   BFIR - Bit-Forwarding Ingress Router   BFR - Bit-Forwarding Router   BIER - Bit Index Explicit Replication   DDMAP - Downstream Detailed Mapping TLV   ECMP - Equal Cost Multi-Path   OAM - Operation, Administration, and Maintenance   SI - Set Identifier   QTF - Querier Timestamp Format   RTF - Responder Timestamp Format   NTP - Network Time Protocol   MTU - Maximum Transmission Unit   DA - Downstream Address   DIA - Downstream Interface Address   DoS - Denial-of-Service   PTP - Precision Time Protocol2.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.Kumar, et al.             Expires 11 July 2026                  [Page 4]Internet-Draft                  BIER Ping                   January 20263.  BIER OAM   BIER OAM is defined to stay within the BIER layer by directly   following the BIER header without mandating the need for an IP   header.  [RFC8296] defines a 4-bit field as "Proto" to identify the   payload following the BIER header.  When the payload is BIER OAM, the   "Proto" field will be set to 5 as defined in [RFC8296]3.1.  BIER OAM Message Format   The BIER OAM packet header format that follows the BIER header is   displayed in Figure 1.      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     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |  Ver  |MessageType|   Proto   |           Reserved            |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                        OAM Message Length                     |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ~                  Message Type Dependent Data                  ~     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                         Figure 1: BIER OAM Header      Ver - a four-bit field that indicates the version of the BIER OAM      header.  The current value is 1.  The version number is to be      incremented whenever a change is made that affects the ability of      an implementation to parse or process the BIER OAM header      correctly.  For example, if syntactic or semantic changes are made      to any of the fixed fields.      Message Type - a six-bit field that identifies OAM protocol.      Values defined in this document are as follows:                   Value      Description                   --------  ---------------                     1        Echo Request                     2        Echo Reply      Proto - a six-bit field.  This field is used to define whether      there is any data packet immediately following the OAM payload.      For example, the In-situ OAM Direct Export Option header [RFC9326]      can be appended to the BIER OAM message, enabling the collection      of the operational state and performance metrics.  This field MUST      be set to 0 if no data packet follows the OAM payload.  Otherwise,      the value is one from the IANA registry "BIER Next Protocol      Identifiers" [IANA-Next-Protocol-Identifiers].Kumar, et al.             Expires 11 July 2026                  [Page 5]Internet-Draft                  BIER Ping                   January 2026      Reserved - a two-octet field.  The value MUST be zeroed on      transmission and ignored on receipt.      OAM Message Length - a two-octet field that reflects the length of      the OAM message in octets, including the header and the Messsage      Type Dependent Data.      Message Type Dependant Data - a variable-length field that      includes the OAM message identified by the value of the Message      Type filed.3.2.  BIER Echo Request/Reply Message Format   The Echo Request/Reply header format is displayed in Figure 2      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     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |  Ver  | Echo Req/Rep  |   Proto   |         Reserved          |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                  Echo Request/Reply Length                    |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |   QTF |   RTF |   Reply Mode  |  Return Code  |   Reserved2   |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                        Sender's Handle                        |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                        Sequence Number                        |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                    Timestamp Sent                             |     |                                                               |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                  Timestamp Received                           |     |                                                               |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ~                              TLVs                             ~     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                  Figure 2: BIER Echo Request/Reply Format      Proto field MUST be set to 0 for Echo Request/Reply header.      QTF (Querier Timestamp Format) - a four-bit field.  When the field      is set to 2, the Timestamp Sent field is (in seconds and      picoseconds, according to the Initiator's clock) in the 64-bit      long NTP format [RFC5905].  When the value of the QTF field is 3,      the Timestamp Sent's format is the IEEE 1588-2008 (1588v2)      Precision Time Protocol (PTP) [IEEE.1588.2008] format.  Any other      value MUST be considered as invalid, the Return Code set toKumar, et al.             Expires 11 July 2026                  [Page 6]Internet-Draft                  BIER Ping                   January 2026      Malformed Echo Request received (1).  Also, the Erroneous Echo      Request TLV (Section 3.4.8) SHOULD be included in the BIER Echo      Reply.      RTF (Responder Timestamp Format) - a four-bit field.  When the      field is set to 2, the Timestamp Received field is (in seconds and      picoseconds, according to the Initiator's clock) in 64-bit long      NTP format [RFC5905].  When filed's value is 3, the format of the      Timestamp Received is as defined in IEEE 1588-2008 (1588v2)      Precision Time Protocol [IEEE.1588.2008].  Any other value MUST be      considered as invalid, the Return Code set to Malformed Echo      Request received (1).  Also, the Erroneous Echo Request TLV      (Section 3.4.8) SHOULD be included in the BIER Echo Reply.  The      Initiator MUST zero RTF in the Echo Request, and the Responder      MUST ignore the value on receipt.   The sender of the BIER Echo Request might receive the BIER Echo Reply   with RTF different from the Sender's QTF.  Thus, to calculate one-way   delay, the Sender MUST be able to interpret both timestamp formats,   i.e., NTP [RFC5905] and PTP [IEEE.1588.2008].  Although the use of   different timestamp formats is permitted, it may cause ambiguity or   even precision loss resulting from format conversion.  Thus, the use   of homogeneous formats is RECOMMENDED.      The Reply Mode - a one-octet field.  The value MUST be set to one      of the following values:                   Value      Description                   --------  ---------------                     1        Do not Reply                     2        Reply via IPv4/IPv6 UDP packet                     3        Reply via BIER packet      When Reply Mode is set to 1, the receiver will not send any reply.      This mode can be used for unidirectional path validation.  When      the Reply Mode is set to 2, the Responder Bit-Forwarding Router      (BFR) encapsulates the Echo reply payload with the IP/UDP header.      When the Initiator intends to validate the return BIER path, the      Reply Mode will be set to 3 so that the Responder BFR will      encapsulate the Echo Reply with the BIER header.  Also, the Reply      Mode "Reply via BIER packet" can be used if the IP network is      deemed less reliable compared to the BIER layer.      Return Code - a one-octet field.  The value MUST be set to zero if      the Type is "BIER Echo Request".  The value of the Return Code      filed MUST be set to one of the values defined in Section 3.3, if      the Type is "BIER Echo Reply".Kumar, et al.             Expires 11 July 2026                  [Page 7]Internet-Draft                  BIER Ping                   January 2026      Reserved2 - a one-octet field.  The Reserved field MUST be zeroed      on transmit and MUST be ignored on receipt.      Sender's Handle - a four-octet field.  The Sender's Handle is      filled by the Initiator, and returned unchanged by responder BFR.      This value can be used for matching the replies to the request      (see Section 4.3).      Sequence Number - a four-octet field.  The value of the field is      assigned by the Initiator and can be used to detect any missed      replies.      Timestamp - each field (Sent and Received) is an eight-octet      field.  The Timestamp Sent is the time when the Echo Request is      sent.  The Timestamp Received in Echo Reply is the time      (accordingly to responding BFR clock) that the corresponding Echo      Request was received.  The format depends on the QTF/RTF value.      The Initiator MUST zero Timestamp Received in the Echo Request,      and the Responder MUST ignore the value on receipt.      TLVs - Carries the TLVs as defined in Section 3.4.3.3.  Return Code   The responder uses the Return Code field to reply with a validity   check or other error message to Initiator.  It does not carry any   meaning in Echo Request and MUST be set to zero.  The Return Code can   be one of the following:           Value      Value Meaning           ------    ---------------            0      No return code            1      Malformed Echo Request received            2      One or more of the TLVs is not supported            3      Replying BFR is the only BFER in header BitString            4      Replying BFR is one of the BFERs in header BitString            5      Packet-Forward-Success            6      Invalid Multipath Info Request            8      No matching entry in the forwarding table            9      Set-Identifier Mismatch           10      DDMAP Mismatch   "No return code" will be used by Initiator in the Echo Request.  This   value MUST NOT be used in Echo Reply.   "Malformed Echo Request received" will be used by any BFR if the   received Echo Request packet is not properly formatted.Kumar, et al.             Expires 11 July 2026                  [Page 8]Internet-Draft                  BIER Ping                   January 2026   When a receiver does not support any TLV included in the Echo   Request, the Return code will be set to "One or more of the TLVs is   not supported" carrying the respective TLVs.   When the received header BitString in the Echo Request packet   contains only its BFR-ID, "Replying BFR is the only BFER in header   BitString" is set in the reply.  This value implies that the receiver   is BFER, and the packet is not forwarded to any more neighbors.   When the received header BitString in the Echo Request packet   contains its BFR-ID in addition to other BFR-IDs, "Replying BFR is   one of the BFERs in header BitString" is set in the reply.  This   value implies that the responder is a BFER and the packet is further   forwarded to one or more neighbors.   Any transit BFR will send the Echo Reply with "Packet-Forward-   Success", if the TLV in the received Echo Request is understood and   the forwarding table has forwarding entries for the BitString.  This   behavior is demonstrated by a transit BFR during traceroute mode.   When the Echo Request is received with multipath info   (Section 3.4.4.1) for more than one BFER, the Return Code is set to   "Invalid Multipath Info Request".   If the BitString cannot be matched in the local forwarding table, the   BFR will use "No matching entry in the forwarding table" in the   reply.   If the BIER-MPLS label in the received Echo Request is not the one   assigned for SI in Original SI-BitString TLV, "Set-Identifier   Mismatch" is set in order to report the mismatch.   If the BitString in Header-H does not match the BitString in Egress   BitString Sub-TLV of DDMAP TLV, a responding BFR will use "DDMAP   Mismatch" to report the problem.3.4.  BIER OAM TLVs   This section defines various TLVs that can be used in BIER OAM   packet.  The TLVs (Type-Length-Value tuples) have the following   format:Kumar, et al.             Expires 11 July 2026                  [Page 9]Internet-Draft                  BIER Ping                   January 2026      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                            ~     |                                                               |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Figure 3: Type-Length-Value Format Used in BIER Echo Request/Reply   TLV Types are defined below.  A system that receives an Echo Request   with unknown TLV Type with the value in the range 0 - 32767 MUST   transmit an Echo Reply with the Return Code "One or more of the TLVs   is not supported" (2).  Also, the Erroneous Echo Request TLV   (Section 3.4.8) SHOULD be included in the BIER Echo Reply.  A system   that receives an Echo Request with the value in the range 32768 -   65535 MAY silently drop the packet.  Length is the length of the   Value field in octets.  The Value field depends on the TLV Type.3.4.1.  Original SI-BitString TLV   The Original SI-BitString TLV carries the set of BFERs and carries   the same BitString that the Initiator includes in the BIER header.   This TLV has the following format:      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 = variable       |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |    Set ID     | Sub-domain ID |BS Len |      Reserved         |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                BitString  (first 32 bits)                     ~     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ~                                                               ~     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                BitString  (last 32 bits)                      |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           Figure 4: The Format of the Original SI-BitString TLV   Set ID - a one-octet field that is set to the value of the Set   Identifier to which the BitString belongs.  This value is derived as   defined in [RFC8279].Kumar, et al.             Expires 11 July 2026                 [Page 10]Internet-Draft                  BIER Ping                   January 2026   Sub-domain ID - a one-octet field that is set to the Sub-domain value   to which BFER in BitString belongs.   BS Len - a four-bit field that is set based on the length of   BitString as defined in [RFC8296] reflected in four-octet words.   Reserved - a twelve-bit field.  Its value MUST be zeroed on   transmission and ignored on receipt.   BitString - a variable length field.  The BitString field carries the   set of BFR-IDs that Initiator will include in the BIER header.   Any Initiator MUST include this TLV in the Echo Request packet.3.4.2.  Target SI-BitString TLV   The Target SI-BitString TLV carries the set of BFERs from which the   Initiator expects the reply.  This TLV has the following format:      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 = variable       |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |    Set ID     | Sub-domain ID |BS Len |       Reserved        |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                BitString  (first 32 bits)                     ~     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ~                                                               ~     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                BitString  (last 32 bits)                      |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            Figure 5: The Format of the Target SI-BitString TLV   Set ID field is set to the Set Identifier to which the BitString   belongs.This value is derived as defined in [RFC8279].   Sub-domain ID is set to the Sub-domain value to which BFER in   BitString belongs.   BS Len is set based on the length of BitString as defined in   [RFC8296]   Reserved - the value MUST be zeroed on transmission and ignored on   receipt.Kumar, et al.             Expires 11 July 2026                 [Page 11]Internet-Draft                  BIER Ping                   January 2026   The BitString field carries the set of BFR-IDs of BFER(s) that   Initiator expects a response.  The BitString in this TLV may be   different from the BitString in the BIER header and allows control of   the BFER responding to the Echo Request.  This TLV MUST be included   by Initiator in the BIER OAM packet if the Downstream Mapping TLV   (Section 3.4.4) is included.3.4.3.  Incoming SI-BitString TLV   The Incoming SI-BitString TLV will be included by Responder BFR in   Reply message and copies the BitString from the BIER header of   incoming Echo Request message.  This TLV has the following format:      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 = variable       |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |    Set ID     | Sub-domain ID |BS Len |       Reserved        |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                BitString  (first 32 bits)                     ~     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ~                                                               ~     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                BitString  (last 32 bits)                      |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           Figure 6: The Format of the Incoming SI-BitString TLV   Set ID field is set to the Set Identifier to which the BitString   belongs.  This value is derived as defined in [RFC8279]   Sub-domain ID is set to the Sub-domain value to which BFER in   BitString belongs.   BS Len is set based on the length of BitString as defined in   [RFC8296].   Reserved - the value MUST be zeroed on transmission and ignored on   receipt.   The BitString field copies the BitString from the BIER header of the   incoming Echo Request.  A Responder BFR SHOULD include this TLV in   Echo Reply if the Echo Request is received with the I flag set in   Downstream Mapping TLV.   An Initiator MUST NOT include this TLV in Echo Request.Kumar, et al.             Expires 11 July 2026                 [Page 12]Internet-Draft                  BIER Ping                   January 20263.4.4.  Downstream Mapping TLV   This TLV has the following format:      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 = variable       |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |               MTU             | Address Type  |     Flags     |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |               Downstream Address (4 or 16 octets)             |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |         Downstream Interface Address (4 or 16 octets)         |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |        Sub-TLVs Length        |                               |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |     .                                                               .     .                      List of Sub-TLVs                         .     .                                                               .     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+             Figure 7: The Format of the Downstream Mapping TLV   MTU  A two-octet field.  The value is the Maximum Transmission Unit      (MTU) value of the egress interface.   Address Type  A one-octet field.  The Address Type indicates the      address type and length of the IP address for the downstream      interface.  The value of the Address Type field is set to one of      the values listed in Figure 8.  Any other value MUST be processed      as invalid TLV.               Value     Address Type              -------    ---------------                  1       IPv4 Numbered                  2       IPv4 Unnumbered                  3       IPv6 Numbered                  4       IPv6 Unnumbered                        Figure 8: The Address Types   Flags  The Flags field has the following format:                              0 1 2 3 4 5 6 7                             +-+-+-+-+-+-+-+-+                             |   Reserved  |I|                             +-+-+-+-+-+-+-+-+Kumar, et al.             Expires 11 July 2026                 [Page 13]Internet-Draft                  BIER Ping                   January 2026                      Figure 9: The Flags Field Format   Reserved - a seven-bit field.  Its value MUST be zeroed on   transmission and ignored on receipt.   I - a one-bit field.  When I flag is set, the Responding BFR MUST   include the Incoming SI- BitString TLV in Echo Reply message.   Downstream Address and Downstream Interface Address      each field is either four-octet or sixteen-octet, depending on the      value of Address Type field.      Note that values of the Address Type field are mapped to      combinations of lengths of Downstream Address and Donstream      Address Interface fileds as follows:                  Value     DA Length     DIA Length                 -------   ------------  ------------                     1           4           4                     2           4           4                     3          16          16                     4          16           4      where:      DA Length         Downstream Address (DA) field Length      DIA Length         Downstream Interface Address (DIA) field Length      If the Address Type is 1, the Downstream Address MUST be set to      IPv4 BFR-Prefix of downstream BFR and Downstream Interface Address      is set to the downstream interface address.      If the Address Type is 2, the Downstream Address MUST be set to      IPv4 BFR-Prefix of downstream BFR and Downstream Interface Address      is set to the index assigned by the responding BFR to the      interface.      If the Address Type is 3, the Downstream Address MUST be set to      IPv6 BFR-Prefix of downstream BFR and Downstream Interface Address      is set to the downstream interface address.      If the Address Type is 4, the Downstream Address MUST be set to      IPv6 BFR-Prefix of downstream BFR and Downstream Interface Address      is set to the index assigned by the responding BFR to the      interface.Kumar, et al.             Expires 11 July 2026                 [Page 14]Internet-Draft                  BIER Ping                   January 20263.4.4.1.  Downstream Detailed Mapping Sub-TLVs   This section defines the optional Sub-TLVs that can be included in   Downstream Mapping TLV.                   Sub-TLV Type     Value                   ------------  -------------                       1         Multipath Entropy Data                       2         Egress BitString3.4.4.1.1.  Multipath Entropy Data       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 = variable       |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |M|   Reserved  | Multipath Type|                               |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |      |                                                               |      |                  (Multipath Information)                      |      |                                                               |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+              Figure 10: The Format of the Multipath Data Blob   M Flag  This flag is set to 0 if all packets will be forwarded out      through the interface defined in the Downstream Mapping TLV.  When      set to 1, Multipath Information will be defined by the Bit masked      Entropy data.   Reserved  The value MUST be zeroed on transmission and ignored on      receipt.        The interpretaion of the Multipath Type field and Multipath      Entropy Data encoding options are the same defined in      Section 3.4.1.1 of [RFC8029].3.4.4.1.2.  Egress BitString Sub-TLV   Responder BFR MAY include this Sub-TLV with the rewritten BitString   in the outgoing interface as defined in Section 6.1 of [RFC8279].Kumar, et al.             Expires 11 July 2026                 [Page 15]Internet-Draft                  BIER Ping                   January 2026      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 = variable       |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |    Set ID     | Sub-domain ID |BS Len |       Reserved        |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                BitString  (first 32 bits)                     ~     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ~                                                               ~     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                BitString  (last 32 bits)                      |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               Figure 11: The Egress BitString Sub-TLV Format   Set ID field is set to the Set Identifier to which the BitString   belongs.  This value is derived as defined in [RFC8279].   Sub-domain ID is set to the Sub-domain value to which BFER in   BitString belongs.   BS Len is set based on the length of BitString as defined in   [RFC8296].   Reserved - the value MUST be zeroed on transmission and ignored on   receipt.   The BitString field copies the rewritten BitString in the outgoing   interface as defined in Section 6.1 of [RFC8279].3.4.5.  Responder BFER TLV   The BFER replying to the request MAY include the Responder BFER TLV.   This TLV identifies the originator of BIER Echo Reply.  This TLV has   the following format:      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 = 5              |           Length = 4          |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |         Reserved              |           BFR-ID              |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                  Figure 12: The Responder BFER TLV Format   Length  A two-octet field.  The value MUST be set to four.Kumar, et al.             Expires 11 July 2026                 [Page 16]Internet-Draft                  BIER Ping                   January 2026   Reserved  A two-octet field.  The value MUST be zeroed on      transmission and ignored on receipt.   BFR-ID  A two-octet field.  The BFR-ID field carries the BFR-ID of      the replying BFER.  This TLV MAY be included by the Responding      BFER in the BIER Echo Reply packet.3.4.6.  Responder BFR TLV   Any transit BFR replying to the request MAY include the Responder BFR   TLV.  This is used to identify the replying BFR without BFR-ID.  This   TLV has the following format:      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     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |     TLV Type = 6              |        Length = 8 or 20       |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |         Reserved              |          Address Type         |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                                                               |     ~                       BFR-Prefix (4 or 16 bytes)              ~     |                                                               |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                  Figure 13: The Responder BFR TLV Format   Length  The Length field, depending on the Address Type value - 8 or      20.   Reserved  A two-octet field.  The value MUST be zeroed on      transmission and ignored on receipt.   Address Type  A two-octet field.  Set to 1 for IPv4 or 2 for IPv6.   BFR-Prefix  This field carries the local BFR-Prefix of the replying      BFR.  This TLV MAY be included by Responding BFR in BIER Echo      Reply packet.3.4.7.  Ingress Interface TLV   The BFR replying to the request MUST include the Ingress Interface   TLV.  This TLV identifies the incoming interface on which the Echo   Request was received.  This TLV has the following format:Kumar, et al.             Expires 11 July 2026                 [Page 17]Internet-Draft                  BIER Ping                   January 2026      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     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |     TLV Type = 7              |        Length = 8 or 20       |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |         Reserved              |          Address Type         |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                                                               |     ~           Ingress Interface Address (4 or 16 bytes)           ~     |                                                               |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                Figure 14: The Ingress Interface TLV Format   Length  The Length field, depending on the Address Type value - 8 or      20.   Reserved  A two-octet field.  The value MUST be zeroed on      transmission and ignored on receipt.   Address Type  A two-octet field.  Set to 1 for IPv4 numbered, 2 for      IPv4 Unnumbered, 3 for IPv6 numbered, or 4 for IPv6 Unnumbered.   Ingress Interface Address      As defined in Section 3.4.43.4.8.  Erroneous Echo Request TLV   The BFER replying to the request MAY include the Erroneous Echo   Request TLV.  This TLV provides information about the type and   location of the problem in the BIER Echo Request.  This TLV has the   following format:      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 = 8              |       Length = variable       |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                               Pointer                         |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |             As much of invoking BIER Echo Request             |     ~            as possible without exceeding path MTU             ~     |                                                               |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+              Figure 15: The Erroneous Echo Request TLV Format   Pointer  A four-octet field that identifies the octet offset withinKumar, et al.             Expires 11 July 2026                 [Page 18]Internet-Draft                  BIER Ping                   January 2026      the received BIER Echo Request message where the error was      detected.  The Pointer will point beyond the end of the BIER Echo      Reply message if the field in error is beyond what can fit in the      resulting packet.4.  BIER Ping and Traceroute Operations   This section describes aspects of BIER ping and traceroute   operations.4.1.  BIER OAM Processing   A BIER OAM packet MUST be punted to the BIER control plane for OAM   processing if one of the following conditions is true:   *  The receiving BFR is a BFER.   *  TTL of BIER-MPLS Label (Section 2.1.1.1 of [RFC8296]) expired.   *  Hop Limit in the IPv6 header (Section 2 of      [I-D.ietf-bier-bierin6]) expired.   The use of the Router Alert label to be deprecated as proposed in   [RFC9570].   Processing of the received BIER OAM packet with unknown value of the   Message Type field (Figure 1) is stopped and the event SHOULD be   logged although through the rate-controlling system.   A transit BFR, i.e., one that does not punt the BIER OAM packet to   the BIER control plane, forwards the BIER OAM packet according to the   rules specified in Section 6.5 of [RFC8279].4.2.  Per BFER ECMP Discovery   As defined in [RFC8279], BIER follows the unicast forwarding path and   allows load balancing over ECMP paths between BFIR and BFER.  BIER   OAM is expected to support ECMP path discovery between a BFIR and a   given BFER and MUST support path validation and failure detection of   any particular ECMP path between BFIR and BFER.   [RFC8296] proposes the BIER header with the Entropy field that can be   leveraged to exercise all ECMP paths.  The Initiator/BFIR will use a   traceroute message to query each hop about the Entropy information   for each of the downstream paths.  To avoid complexity, it is   suggested that the ECMP query is performed per BFER by carrying the   required information in the BIER OAM message.Kumar, et al.             Expires 11 July 2026                 [Page 19]Internet-Draft                  BIER Ping                   January 2026   When an operator performs per BFER ECMP discovery, the Initiator MUST   include Multipath Entropy Data Sub-TLV in Downstream Mapping TLV.  It   MUST also include the BFER in the BitString TLV to which the   Multipath query is performed.   Any transit BFR will transmit the BIER Echo Reply to the Initiator   with Bit-masked Entropy for each downstream path as defined in   [RFC8029].4.3.  Sending BIER Echo Request   The Initiator MUST set the Message Type as 1 and Return Code as 0.   The Proto field in the OAM packet MUST be set to 0.  The choice of   the Sender's Handle and Sequence Number is a local matter to the   Initiator and SHOULD increment the Sequence Number by 1 for every   subsequent Echo Request.  The QTF field is set to Initiator's local   timestamp format, and the TimeStamp Sent field is set to the time   that the Echo Request is sent.   The Initiator MUST include Original SI-BitString TLV.  The Initiator   MUST NOT include more than one Original SI-BitString TLV.  The   Initiator infers the Set Identifier value and Sub-domain ID value   from the respective BitString that will be included in the BIER   header of the packet and includes the values in "SI" and Sub-Domain   ID fields, respectively.   In Ping mode, the Initiator MAY include Target SI-BitString TLV to   control the responding BFER(s) by listing all the BFERs from which   the Initiator expects a response.  In the traceroute mode, the   Initiator MAY include Target SI-BitString TLV to control the path   trace towards any specific BFER or set of BFERs.  The Initiator on   receiving a reply with the Return code "Replying BFR is the only BFER   in the header BitString" or "Replying router is one of the BFERs in   header BitString" SHOULD unset the respective BFR-ID from Target SI-   BitString for any subsequent Echo Request.   The Initiator MAY include Downstream Mapping TLV (Section 3.4.4) in   the Echo Request to query additional information from transit BFRs   and BFERs.  In case of ECMP discovery, the Initiator MUST include the   Multipath Entropy Data Sub-TLV and SHOULD set the Target SI-BitString   TLV carrying a specific BFER ID.Kumar, et al.             Expires 11 July 2026                 [Page 20]Internet-Draft                  BIER Ping                   January 2026   The Initiator MUST encapsulate the OAM packet with the BIER header   and MUST set the Proto as 5 and further encapsulates with BIER-MPLS   label.  In ping mode, the BIER-MPLS Label TTL MUST be set to 255.  In   traceroute mode, the BIER-MPLS Label TTL is set successively,   starting from 1 and MUST stop sending the Echo Request if it receives   a reply with Return code as "Replying router is the only BFER in BIER   header BitString" from all BFER listed in Target SI-BitString TLV.4.4.  Receiving BIER Echo Request   Sending a BIER OAM Echo Request to control plane for payload   processing is triggered as mentioned in Section 4.1.   Any BFR on receiving an Echo Request MUST perform the basic sanity   check, including, but not limited to, checking values of the fields   with a priori known values, e.g., Ver, Reply Mode, or Type and Length   if any TLV is present.  If, at any stage of processing the received   BIER Echo Request, the BFR encounters an error, it MUST stop   processing and transmit BIER Echo Reply with the Return Code set   accordingly.  If the BFR cannot parse the OAM packet completely   because the value in the OAM Message Length field is incorrect, BFR   MUST send Echo Reply with Return Code set to "Malformed Echo Request   received" if the OAM Message Length is incorrect.  The Erroneous Echo   Request TLV (Section 3.4.8) SHOULD be included in the BIER Echo   Reply.  If the packet sanity check is fine, it SHOULD initiate the   below set of variables:   Reply-Flag      This flag is initially set to 1.   Interface-I      The incoming interface on which the Echo Request was received.      This MAY be used to validate the Downstream Detailed Mapping TLV      (DDMAP) info and populate the Ingress Interface TLV.   BIER-Label-L      The BIER-MPLS Label received as the top label of the received Echo      Request.  This MAY be used to validate if the packet is traversing      the desired Set Identifier and sub-domain path.   Header-H      The BIER header of the received Echo Request.  It can be used to      validate the DDMAP info and to populate the Incoming SI-BitString      TLV.  Also, it can be used to perform entropy calculation      considering a different field in the header and replying with      Multipath Entropy Data Sub-TLV.Kumar, et al.             Expires 11 July 2026                 [Page 21]Internet-Draft                  BIER Ping                   January 2026   Best-return-code      contains the Return Code for the echo reply packet as currently      best known.  As the algorithm progresses, this code may change      depending on the results of further checks that it performs.   BFR MUST initialize the internal, to the implementation, Best-return-   code variable to the null value.   BFR will populate the Interface-I with the identifier of the   interface over which the Echo Request is received, the top label in   the MPLS stack of the received Echo Request to BIER-Label-L, and the   BIER header to Header-H.  If the received Echo Request carries Target   SI-BitString TLV, a BFR SHOULD run the boolean AND operation between   BitString in Header-H and BitString in Target SI-BitString TLV.  If   the resulting BitString is all-zero, reset Reply-Flag=0 and go to   Section 4.5.  Else:   *  If the BIER-Label-L does not correspond to the local label      assigned for {sub-domain, BitStringLen, SI} in Original SI-      BitString TLV, Set the Best-return-code to "Set-Identifier      Mismatch" and Go to Section 4.5.   The step above allows the detection of a synchronization problem in   the upstream BFR between BIER-Label and {sub-domain, BitStringLen,   SI} that might cause an unintended packet leak between sub-domains.   *  Set the Best-return-code to "One or more of the TLVs is not      supported" if any of the TLVs in the Echo Request message is not      supported.  Go to Section 4.5.   *  If the BitString in Header-H does not match the BitString in      Egress BitString Sub-TLV of DDMAP TLV, set the Best-return-code to      "DDMAP Mismatch" and go to Section 4.5.  When there are more than      one DDMAP TLV in the received Request packet, the Downstream      Address and Downstream Interface Address should be matched with      Interface-I to identify the right DDMAP TLV and then perform the      BitString match.   The step above allows the detection of a deviation between the BIER   control plane and the BIER forwarding plane in the upstream node that   may result in a forwarding loop or packet duplication.   *  Set the Best-return-code to "Invalid Multipath Info Request", when      the DDMAP TLV carries Multipath Entropy Data Sub-TLV, and if the      Target SI-BitString TLV in the received Echo Request carries more      than 1 BFER id.  Go to Section 4.5.  Else, list the ECMP      downstream neighbors to reach BFR-ID in Target SI-BitString TLV,      calculate the Entropy considering the BitString in Header-H andKumar, et al.             Expires 11 July 2026                 [Page 22]Internet-Draft                  BIER Ping                   January 2026      Multipath Entropy Data Sub-TLV from received Echo Request.  Store      the Data for each Downstream interface in a temporary variable.      Set the Best-return-code to 5 (Packet-Forward-Success) and goto      Section 4.5   This step instructs the node to calculate the Entropy Data for each   downstream interface to reach the BFER in Target SI-BitString TLV by   considering the incoming BitString and Entropy Data.   *  Set the Best-return-code to "Replying router is the only BFER in      BIER header BitString", and go to Section 4.5 if the responder is      BFER and there are no more bits in the BIER header BitString left      for forwarding.   *  Set the Best-return-code to "Replying router is one of the BFERs      in BIER header BitString", and include Downstream Mapping TLV if      the responder is BFER and there are more bits in BitString left      for forwarding.  Also, include the Multipath information as      defined in Section 4.2 if the received Echo Request carries      Multipath Entropy Data Sub-TLV.  Go to Section 4.5.   *  Set the Best-return-code to "No matching entry in the forwarding      table", if the forwarding lookup, defined in Section 6.5 of      [RFC8279] does not match any entry for the received BitString in      BIER header.   The step above allows the detection of the missing BFR-ID in the   node's BIER forwarding table.  It is difficult to detect the absence   of the BFR-ID if the Request includes more than one BFR-IDs in the   BitString and so may need to include the BFER-id that is not   responding to detect such failure.   *  Set the Best-return-code to "Packet-Forward-Success", and include      Downstream Mapping TLV.  Go to Section 4.5.4.5.  Sending Echo Reply   If Reply-Flag=0, BFR MUST release the variables and MUST NOT send any   response to the Initiator.  If Reply-Flag=1, proceed as below:   The Responder BFR SHOULD include the BitString from Header-H to   Incoming SI-BitString TLV and include the Set ID, Sub-domain ID and   BS Len that corresponds to BIER-Label-L.  Responder BFR SHOULD   include the Ingress Interface TLV and populate the address from   Interface-I.   When the Best-return-code is "Replying BFR is one of the BFERs in   header BitString", it MUST include Responder BFER TLV.Kumar, et al.             Expires 11 July 2026                 [Page 23]Internet-Draft                  BIER Ping                   January 2026      If the received Echo Request had DDMAP with Multipath Entropy Data      Sub-TLV, Responder BFR MUST include DDMAP as defined in      Section 3.4.4 for each outgoing interface over which the packet      will be replicated and include the respective Multipath Entropy      Data Sub-TLV.  For each outgoing interface, the respective Egress      BitString MUST be included in DDMAP TLV.      If the received Echo Request had DDMAP without Multipath Entropy      Data Sub-TLV, Responder BFR MUST include DDMAP as defined in      Section 3.4.4 for each outgoing interface over which the packet      will be replicated.  For each outgoing interface, respective      Egress BitString MUST be included in DDMAP TLV.   When the Best-return-code is "Replying BFR is the only BFER in header   BitString", it MUST include Responder BFER TLV.   The Responder MUST set the Message Type as 2 and Return Code as Best-   return-code.  The Proto field MUST be set to 0.   The Echo Reply can be sent as BIER-encapsulated, or IP/UDP   encapsulated, depending on the Reply Mode in the received Echo   Request.  When the Reply Mode in the received Echo Request is set to   3, Responder appends the BIER header listing the BitString with BFIR   ID (from Header-H), sets the Proto to 5, and sets the BFIR as 0.   When the Reply Mode in the received Echo Request is set to 2,   Responder encapsulates with the IP/UDP header.  The UDP destination   port MUST be set to TBD1 (Section 5.1), and the source port MAY be   set to TBD1 or other value selected from the Dynamic range of port   numbers.  The source IP address is any non-link-local address   associated with the responder, and the destination IP address is   derived from the BFIR-id of the BIER header [RFC8296] in the received   Echo Request.4.6.  Receiving Echo Reply   The Initiator, upon receiving the Echo Reply, will use the Sender's   Handle to match with Echo Request sent.  If no match is found, the   Initiator MUST ignore the Echo Reply.   If receiving Echo Reply has Downstream Mapping, the Initiator SHOULD   copy the same to subsequent Echo Request(s).   If one of the Echo Reply is received with Return Code as "Replying   BFR is one of the BFERs in header BitString", it SHOULD reset the   BFR-ID of the responder from Target SI-BisString TLV in subsequent   Echo Request.  This step helps avoid any BFR that is both BFER and   transit BFR to respond with Echo Reply continuously.Kumar, et al.             Expires 11 July 2026                 [Page 24]Internet-Draft                  BIER Ping                   January 20265.  IANA Considerations   The terms used in the IANA Considerations below are intended to be   consistent with [RFC8126].5.1.  UDP Port Number   This document requests a UDP port TBD1 to be allocated by IANA for   BIER Echo.   Service Name bier-echo   Transport Protocol UDP, TCP   Assignee IESG iesg@ietf.org   Contact IETF Chair chair@ietf.org   Description The UDP destination port number for the IP/UDP   encapsulated BIER Echo Reply message.   Reference This document   Port Number TBD15.2.  BIER OAM Registry Group   IANA is requested to create and maintain the "BIER OAM" registry   group containing the registries listed below.5.3.  BIER OAM Message Type   IANA is requested to create in the BIER OAM Message Type registry in   the BIER OAM registry group as follows:      Registry Name: BIER OAM Message Type.      Assignment Policy:      0-31 - IETF Review      32-58 - RFC Required      59 - 61 - Experimental Use (Reserved, not to be assigned)      62 - 63 - Private Use (Reserved, not to be assigned)Kumar, et al.             Expires 11 July 2026                 [Page 25]Internet-Draft                  BIER Ping                   January 2026        +=========+===============================+===============+        | Value   |          Description          | Reference     |        +=========+===============================+===============+        | 0       |            Reserved           | This document |        +---------+-------------------------------+---------------+        | 1       |  BIER Echo Request/Echo Reply | This document |        +---------+-------------------------------+---------------+        | 2 - 58  |           Unassigned          | This document |        +---------+-------------------------------+---------------+        | 59 - 61 | Reserved for Experimental Use | This document |        +---------+-------------------------------+---------------+        | 62 - 63 |    Reserved for Private Use   | This document |        +---------+-------------------------------+---------------+                       Table 1: BIER OAM Message Type5.4.  BIER Echo Request/Echo Reply Registries   IANA is requested to create three BIER Echo Request/Echo Reply   registries in the BIER OAM registry group, as described below.5.4.1.  BIER Echo Request/Echo Reply Message Types   IANA is requested to create in the in the BIER OAM registry group the   BIER Echo Request/Echo Reply Message Types registry as follows:      Registry Name: BIER Echo Request/Echo Reply Message Types      Assignment Policy:      0 - 191 - IETF Review      192 - 247 - RFC Required      248 - 251 - Experimental Use (Reserved, not to be assigned)      252 - 255 - Private Use (Reserved, not to be assigned)Kumar, et al.             Expires 11 July 2026                 [Page 26]Internet-Draft                  BIER Ping                   January 2026       +===========+===============================+===============+       | Value     |          Description          | Reference     |       +===========+===============================+===============+       | 0         |            Reserved           | This document |       +-----------+-------------------------------+---------------+       | 1         |       BIER Echo Request       | This document |       +-----------+-------------------------------+---------------+       | 2         |        BIER Echo Reply        | This document |       +-----------+-------------------------------+---------------+       | 3 - 175   |           Unassigned          | This document |       +-----------+-------------------------------+---------------+       | 176 - 247 |           Unassigned          | This document |       +-----------+-------------------------------+---------------+       | 248-251   | Reserved for Experimental Use | This document |       +-----------+-------------------------------+---------------+       | 252-255   |    Reserved for Private Use   | This document |       +-----------+-------------------------------+---------------+            Table 2: BIER Echo Request/Echo Reply Message Types5.4.2.  BIER Echo Reply Modes   IANA is requested to create in the BIER OAM registry group the new   BIER Echo Reply Mode registry as follows:      Registry Name: BIER Echo Reply Mode      Assignment Policy:      0 - 191 - IETF Review      192 - 247 - RFC Required      248 - 251 - Experimental Use (Reserved, not to be assigned)      252 - 255 - Private Use (Reserved, not to be assigned)Kumar, et al.             Expires 11 July 2026                 [Page 27]Internet-Draft                  BIER Ping                   January 2026     +===========+===================================+===============+     | Value     |            Description            | Reference     |     +===========+===================================+===============+     | 0         |              Reserved             | This document |     +-----------+-----------------------------------+---------------+     | 1         |            Do Not Reply           | This document |     +-----------+-----------------------------------+---------------+     | 2         | Reply via an IPv4/IPv6 UDP Packet | This document |     +-----------+-----------------------------------+---------------+     | 3         |       Reply via BIER packet       | This document |     +-----------+-----------------------------------+---------------+     | 4 - 175   |             Unassigned            | This document |     +-----------+-----------------------------------+---------------+     | 176 - 247 |             Unassigned            | This document |     +-----------+-----------------------------------+---------------+     | 248-251   |   Reserved for Experimental Use   | This document |     +-----------+-----------------------------------+---------------+     | 252-255   |      Reserved for Private Use     | This document |     +-----------+-----------------------------------+---------------+                       Table 3: BIER Echo Reply Modes5.4.3.  BIER Echo Return Codes   IANA is requested to create in the BIER OAM registry group the new   BIER Echo Return Codes registry as follows:      Registry Name: BIER Echo Return Codes      Assignment Policy:      0 - 191 - IETF Review      192 - 247 - RFC Required      248 - 251 - Experimental Use (Reserved, not to be assigned)      252 - 255 - Private Use (Reserved, not to be assigned)Kumar, et al.             Expires 11 July 2026                 [Page 28]Internet-Draft                  BIER Ping                   January 2026       +=========+=================================+===============+       | Value   |           Description           | Reference     |       +=========+=================================+===============+       | 0       |          No Return Code         | This document |       +---------+---------------------------------+---------------+       | 1       | Malformed Echo Request received | This document |       +---------+---------------------------------+---------------+       | 2       |  One or more of the TLVs is not | This document |       |         |            supported            |               |       +---------+---------------------------------+---------------+       | 3       |  Replying BFR is the only BFER  | This document |       |         |       in header BitString       |               |       +---------+---------------------------------+---------------+       | 4       |    Replying BFR is one of the   | This document |       |         |    BFERs in header BitString    |               |       +---------+---------------------------------+---------------+       | 5       |      Packet-Forward-Success     | This document |       +---------+---------------------------------+---------------+       | 6       | Invalid Multipath Info Request  | This document |       +---------+---------------------------------+---------------+       | 7       |            Unassigned           | This document |       +---------+---------------------------------+---------------+       | 8       | No matching entry in the        | This document |       |         | forwarding table                |               |       +---------+---------------------------------+---------------+       | 9       | Set-Identifier Mismatch         | This document |       +---------+---------------------------------+---------------+       | 10      | DDMAP Mismatch                  | This document |       +---------+---------------------------------+---------------+       | 11 -    |            Unassigned           | This document |       | 247     |                                 |               |       +---------+---------------------------------+---------------+       | 248-251 |  Reserved for Experimental Use  | This document |       +---------+---------------------------------+---------------+       | 252-255 |     Reserved for Private Use    | This document |       +---------+---------------------------------+---------------+                      Table 4: BIER Echo Return Codes5.5.  Common Registration Procedures for TLVs and Sub-TLVs   This section describes registration procedures for Type registries in   BIER Echo Request/Reply TLVs and sub-TLVs.Kumar, et al.             Expires 11 July 2026                 [Page 29]Internet-Draft                  BIER Ping                   January 2026      +=============+==============+================================+      | Range       | Registration | Note                           |      |             | Procedures   |                                |      +=============+==============+================================+      | 0-16383     | Standards    | This range is for TLVs and     |      |             | Action       | sub-TLVs that require an error |      |             |              | message if not recognized.     |      +-------------+--------------+--------------------------------+      | 16384-31739 | RFC Required | This range is for TLVs and     |      |             |              | sub-TLVs that require an error |      |             |              | message if not recognized.     |      +-------------+--------------+--------------------------------+      | 31740-31743 | Experimental | Not to be assigned.            |      |             | Use          |                                |      +-------------+--------------+--------------------------------+      | 31744-32767 | First Come,  | This range is for TLVs and     |      |             | First Served | sub-TLVs that require an error |      |             |              | message if not recognized.     |      +-------------+--------------+--------------------------------+      | 32768-49161 | Standards    | his range is for TLVs and sub- |      |             | Action       | TLVs that can be silently      |      |             |              | dropped if not recognized.     |      +-------------+--------------+--------------------------------+      | 49162-64507 | RFC Required | This range is for TLVs and     |      |             |              | sub-TLVs that can be silently  |      |             |              | dropped if not recognized.     |      +-------------+--------------+--------------------------------+      | 64508-64511 | Experimental | Not to be assigned.            |      |             | Use          |                                |      +-------------+--------------+--------------------------------+      | 64512-65535 | First Come,  | This range is for TLVs and     |      |             | First Served | sub-TLVs that can be silently  |      |             |              | dropped if not recognized.     |      +-------------+--------------+--------------------------------+                               Table 5: TLVs5.5.1.  TLVs   IANA is requested to create in the BIER OAM registry group a registry   for the Type field of top-level TLVs. as well as sub-registries for   the associated sub-TLVs.  Note that the meaning of a sub-TLV is   scoped by the TLV.  The number of spaces for the sub-TLVs of various   TLVs is independent.      Registry Name: TLVs      Assignment Policy: Section 5.5Kumar, et al.             Expires 11 July 2026                 [Page 30]Internet-Draft                  BIER Ping                   January 2026   The TLVs requested by this document for the IANA consideration are   listed in Table 6.     +======+==============+===============+=========================+     | Type |   TLV Name   | Reference     | Sub-TLV Registry        |     +======+==============+===============+=========================+     | 0    |   Reserved   | This document |                         |     +------+--------------+---------------+-------------------------+     | 1    | Original SI- | This document | No Sub-TLVs             |     |      |  BitString   |               |                         |     +------+--------------+---------------+-------------------------+     | 2    |  Target SI-  | This document | No Sub-TLVs             |     |      |  BitString   |               |                         |     +------+--------------+---------------+-------------------------+     | 3    | Incoming SI- | This document | No Sub-TLVs             |     |      |  BitString   |               |                         |     +------+--------------+---------------+-------------------------+     | 4    |  Downstream  | This document | Link the Sub-TLVs for   |     |      |   Mapping    |               | TLV Type 4 sub-registry |     +------+--------------+---------------+-------------------------+     | 5    |  Responder   | This document | No Sub-TLVs             |     |      |     BFER     |               |                         |     +------+--------------+---------------+-------------------------+     | 6    |  Responder   | This document | No Sub-TLVs             |     |      |     BFR      |               |                         |     +------+--------------+---------------+-------------------------+     | 7    |   Ingress    | This document | No Sub-TLVs             |     |      |  Interface   |               |                         |     +------+--------------+---------------+-------------------------+                               Table 6: TLVs5.5.2.  Sub-TLVs for TLV Type 4   IANA is requested to create in the registry for the Type 4   (Downstream Mapping) a sub-registry Sub-TLVs for Type 4.      Registry Name: Sub-TLVs for Type 4      Assignment Policy: Section 5.5Kumar, et al.             Expires 11 July 2026                 [Page 31]Internet-Draft                  BIER Ping                   January 2026             +======+========================+===============+             | Type |      Sub-TLV Name      | Reference     |             +======+========================+===============+             | 0    |        Reserved        | This document |             +------+------------------------+---------------+             | 1    | Multipath Entropy Data | This document |             +------+------------------------+---------------+             | 2    |    Egress BitString    | This document |             +------+------------------------+---------------+                               Table 7: TLVs6.  Security Considerations   The security considerations of [RFC8296], and through it of   [RFC8279], apply to this specification.   The security consideration for BIER Ping is similar to ICMP [RFC0792]   or LSP Ping [RFC8029], [RFC6425].  As with ICMP or LSP Ping, BFR can   be exposed to Denial-of-Service (DoS) attacks, and it is RECOMMENDED   to regulate the BIER Ping packet flow to the control plane.  A rate   limiter SHOULD be applied to avoid any attack.  Specifically, a rate   limiter SHOULD be applied to the well-known UDP port defined in   Section 5.1.  Although using BIER Echo Request in a DoS amplification   attack is theoretically possible, spoofing BFIR ID in the BIER Header   presents itself as a serious challenge.  As a result, this threat is   not a big concern.   As with ICMP or LSP Ping, a traceroute can be used to obtain network   information.  It is RECOMMENDED that the implementation checks the   integrity of BFIR of the Echo messages against any locally secured   list before processing the message further.   In some BIER environments, transmitting a single BIER Echo Request   message can result in the sender receiving an overwhelming number of   BIER Echo Reply messages.  In that case, an operator MAY choose to   address the BIER Echo Request to a subset of BFERs rather than to all   BFERs in the domain.7.  Acknowledgement   The authors would like to thank Antoni Przygienda, Eric Rosen, Faisal   Iqbal, Jeffrey (Zhaohui) Zhang, and Shell Nakash for their review and   comments.   The authors would like to thank Mankamana Mishra for his thorough   review and comments.Kumar, et al.             Expires 11 July 2026                 [Page 32]Internet-Draft                  BIER Ping                   January 20268.  References8.1.  Normative References   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels", BCP 14, RFC 2119,              DOI 10.17487/RFC2119, March 1997,              <https://www.rfc-editor.org/info/rfc2119>.   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,              May 2017, <https://www.rfc-editor.org/info/rfc8174>.   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,              "Network Time Protocol Version 4: Protocol and Algorithms              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,              <https://www.rfc-editor.org/info/rfc5905>.   [RFC8029]  Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,              Aldrin, S., and M. Chen, "Detecting Multiprotocol Label              Switched (MPLS) Data-Plane Failures", RFC 8029,              DOI 10.17487/RFC8029, March 2017,              <https://www.rfc-editor.org/info/rfc8029>.   [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,              <https://www.rfc-editor.org/info/rfc8279>.   [RFC8296]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,              Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation              for Bit Index Explicit Replication (BIER) in MPLS and Non-              MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January              2018, <https://www.rfc-editor.org/info/rfc8296>.   [RFC6425]  Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,              Yasukawa, S., and T. Nadeau, "Detecting Data-Plane              Failures in Point-to-Multipoint MPLS - Extensions to LSP              Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,              <https://www.rfc-editor.org/info/rfc6425>.   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for              Writing an IANA Considerations Section in RFCs", BCP 26,              RFC 8126, DOI 10.17487/RFC8126, June 2017,              <https://www.rfc-editor.org/info/rfc8126>.Kumar, et al.             Expires 11 July 2026                 [Page 33]Internet-Draft                  BIER Ping                   January 2026   [IEEE.1588.2008]              "Standard for a Precision Clock Synchronization Protocol              for Networked Measurement and Control Systems",              IEEE Standard 1588, March 2008.   [IANA-Next-Protocol-Identifiers]              IANA, "IANA BIER Next Protocol Identifiers Registry",              <https://www.iana.org/assignments/bier/bier.xhtml#bier-              next-protocol-identifiers>.8.2.  Informative References   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,              RFC 792, DOI 10.17487/RFC0792, September 1981,              <https://www.rfc-editor.org/info/rfc792>.   [RFC9326]  Song, H., Gafni, B., Brockners, F., Bhandari, S., and T.              Mizrahi, "In Situ Operations, Administration, and              Maintenance (IOAM) Direct Exporting", RFC 9326,              DOI 10.17487/RFC9326, November 2022,              <https://www.rfc-editor.org/info/rfc9326>.   [RFC9570]  Kompella, K., Bonica, R., and G. Mirsky, Ed., "Deprecating              the Use of Router Alert in LSP Ping", RFC 9570,              DOI 10.17487/RFC9570, May 2024,              <https://www.rfc-editor.org/info/rfc9570>.   [I-D.ietf-bier-oam-requirements]              Mirsky, G., Nainar, N. K., Chen, M., and S. Pallagatti,              "Operations, Administration and Maintenance (OAM)              Requirements for Bit Index Explicit Replication (BIER)              Layer", Work in Progress, Internet-Draft, draft-ietf-bier-              oam-requirements-21, 23 November 2025,              <https://datatracker.ietf.org/doc/html/draft-ietf-bier-              oam-requirements-21>.   [I-D.ietf-bier-bierin6]              Zhang, Z., Zhang, Z. J., Wijnands, I., Mishra, M. P.,              Bidgoli, H., and G. S. Mishra, "Supporting BIER in IPv6              Networks (BIERin6)", Work in Progress, Internet-Draft,              draft-ietf-bier-bierin6-12, 25 August 2025,              <https://datatracker.ietf.org/doc/html/draft-ietf-bier-              bierin6-12>.Contributors' AddressesKumar, et al.             Expires 11 July 2026                 [Page 34]Internet-Draft                  BIER Ping                   January 2026   Nobo Akiya   Big Switch Networks   Japan   Email: nobo.akiya.dev@gmail.com   Lianshu Zheng   Individual Contributor   China   Email: veronique_cheng@hotmail.comAuthors' Addresses   Nagendra Kumar   Cisco Systems, Inc.   7200 Kit Creek Road   Research Triangle Park, NC 27709   United States of America   Email: naikumar@cisco.com   Carlos Pignataro   North Carolina State University   United States of America   Email: cpignata@gmail.com, cmpignat@ncsu.edu   Mach Chen   Huawei Technologies   Email: mach.chen@huawei.com   Greg Mirsky   Ericsson   Email: gregimirsky@gmail.comKumar, et al.             Expires 11 July 2026                 [Page 35]