Bit Index Explicit Replication (BIER) Ping and Trace
draft-ietf-bier-ping-27
| Document | Type | Active Internet-Draft (bier WG) | |
|---|---|---|---|
| Authors | Nagendra Kumar Nainar , Carlos Pignataro , Mach Chen , Greg Mirsky | ||
| Last updated | 2026-05-30 | ||
| Replaces | draft-kumarzheng-bier-ping | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Reviews |
INTDIR Telechat review
(of
-16)
by Brian Haberman
Ready w/nits
TSVART IETF Last Call review
(of
-16)
by Marcus Ihlar
Ready w/issues
INTDIR Early review
(of
-08)
by Brian Haberman
Almost ready
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Mankamana Prasad Mishra | ||
| Shepherd write-up | Show Last changed 2023-11-27 | ||
| IESG | IESG state | IESG Evaluation::External Party | |
| Action Holders | |||
| Consensus boilerplate | Yes | ||
| Telechat date |
(None)
Has enough positions to pass. |
||
| Responsible AD | Gunter Van de Velde | ||
| Send notices to | mankamana mishra <mankamis@cisco.com> | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA expert review state | Expert Reviews OK | ||
| IANA expert review comments | Approval from AD: Short version: once all the remaining blocking DISCUSS ballots are cleared, this IETF Review draft will move forward with the requested port assignment. A bit of context may help. OAM is a very different kind of application compared to most of the more traditional cases the port expert usually reviews. An OAM network service comes with quite different operational and security expectations. Early on, there was some confusion around this being a request for a port to carry multicast traffic. As the port expert rightly pointed out, different rules apply there, and using a dedicated multicast address is preferred over assigning a port number. That misunderstanding was discussed in detail and ultimately resolved by tightening up the text and being more explicit in the draft. Where we landed is that the actual request is for a port used by unicast packets, operating in a closed and well-controlled environment. The protocol does not cause payload amplification in its responses, and payload confidentiality (authentication and/or encryption) is not only unnecessary but would actually be counter-productive for this specific OAM use case. The draft (draft-ietf-bier-ping) has also gone through the Security Directorate review twice and was reviewed during IESG evaluation by two Security ADs, with no security concerns identified. Taking all of that together, once the remaining blocking DISCUSS items are resolved, I’m comfortable proceeding with the port assignment as requested by the document. |
draft-ietf-bier-ping-27
Network Work group N. Kumar
Internet-Draft NVIDIA
Intended status: Standards Track C. Pignataro
Expires: 1 December 2026 North Carolina State University
M. Chen
Huawei Technologies
G. Mirsky
Independent
30 May 2026
Bit Index Explicit Replication (BIER) Ping and Trace
draft-ietf-bier-ping-27
Abstract
Bit Index Explicit Replication (BIER) is a multicast forwarding
architecture designed to simplify and optimize multicast delivery.
This document specifies 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 1 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kumar, et al. Expires 1 December 2026 [Page 1]
Internet-Draft BIER Ping May 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 . . . . . . . . . . . . . . 4
2.1. Terminology and Acronyms . . . . . . . . . . . . . . . . 4
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. BIER OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. BIER OAM Message Format . . . . . . . . . . . . . . . . . 5
3.2. BIER Echo Request/Reply Message Format . . . . . . . . . 6
3.3. Return Code . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. BIER OAM TLVs . . . . . . . . . . . . . . . . . . . . . . 10
3.4.1. Original SI-BitString TLV . . . . . . . . . . . . . . 11
3.4.2. Target SI-BitString TLV . . . . . . . . . . . . . . . 12
3.4.3. Incoming SI-BitString TLV . . . . . . . . . . . . . . 13
3.4.4. Downstream Detailed Mapping TLV . . . . . . . . . . . 14
3.4.5. Responder BFER TLV . . . . . . . . . . . . . . . . . 19
3.4.6. Responder BFR TLV . . . . . . . . . . . . . . . . . . 19
3.4.7. Ingress Interface TLV . . . . . . . . . . . . . . . . 20
3.4.8. Erroneous Echo Request TLV . . . . . . . . . . . . . 21
4. BIER Ping and Traceroute Operations . . . . . . . . . . . . . 21
4.1. BIER OAM Processing . . . . . . . . . . . . . . . . . . . 21
4.2. BFER ECMP Discovery Within a BIER Domain with MPLS
Underlay . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3. Sending BIER Echo Request . . . . . . . . . . . . . . . . 22
4.4. Receiving BIER Echo Request . . . . . . . . . . . . . . . 23
4.5. Sending Echo Reply . . . . . . . . . . . . . . . . . . . 27
4.6. Receiving Echo Reply . . . . . . . . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
5.1. UDP Port Number . . . . . . . . . . . . . . . . . . . . . 28
5.2. BIER OAM as BIER NEXT Protocol . . . . . . . . . . . . . 29
5.3. BIER OAM Registry Group . . . . . . . . . . . . . . . . . 29
5.4. BIER OAM Message Type . . . . . . . . . . . . . . . . . . 29
5.5. BIER Echo Request/Echo Reply Registries . . . . . . . . . 30
5.5.1. BIER Echo Request/Echo Reply Message Types . . . . . 30
5.5.2. BIER Echo Reply Modes . . . . . . . . . . . . . . . . 31
5.5.3. BIER Echo Return Codes . . . . . . . . . . . . . . . 32
5.6. Common Registration Procedures for TLVs and Sub-TLVs . . 33
5.6.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . 34
5.6.2. Sub-TLVs for TLV Type 4 . . . . . . . . . . . . . . . 35
Kumar, et al. Expires 1 December 2026 [Page 2]
Internet-Draft BIER Ping May 2026
6. Security Considerations . . . . . . . . . . . . . . . . . . . 36
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 36
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Normative References . . . . . . . . . . . . . . . . . . 37
8.2. Informative References . . . . . . . . . . . . . . . . . 38
Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. 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]).
Kumar, et al. Expires 1 December 2026 [Page 3]
Internet-Draft BIER Ping May 2026
2. Conventions used in this document
2.1. Terminology and Acronyms
In this specification:
The term "Initiator" is used interchangeably with the "Sender of a
BIER Echo Request".
An incoming interface, also referred to as ingress interface, is a
BFR's interface on which it receives a BIER Echo Request packet.
A downstream interface, also referred to as egress interface, is a
BFR's interface over which the BIER Echo Request packet may be
transmitted to reach the destination.
BFER - Bit-Forwarding Egress Router
BFIR - Bit-Forwarding Ingress Router
BFR - Bit-Forwarding Router
BIFT - Bit Index Forwarding Table
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
Kumar, et al. Expires 1 December 2026 [Page 4]
Internet-Draft BIER Ping May 2026
PTP - Precision Time Protocol
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 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. To produce information that is useful to an operator,
information that statistically reflects conditions experienced by the
monitored data flow, the operator must be able to ensure that active
OAM packets, e.g., BIER Echo Request, traverse the set of links and
nodes and receive the same forwarding treatment as the monitored
flow. Hence, all fields in the BIER header that affect packet
forwarding (e.g., BFIR-id, BitString) must be set to the values
applied to the monitored data flow. [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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIER OAM Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: BIER OAM Header
Ver - a four-bit field that indicates the version of the BIER OAM
header. The value defined in this document 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.
Kumar, et al. Expires 1 December 2026 [Page 5]
Internet-Draft BIER Ping May 2026
Message Type - a six-bit field that identifies OAM protocol.
Values defined in this document are as in Table 1.
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].
Reserved - a two-octet field. The value MUST be zeroed on
transmission and ignored on receipt.
BIER OAM Message Length - a four-octet field that reflects the
length of the OAM message in octets, including the header and the
Messsage Type Dependent Data.
3.2. BIER Echo Request/Reply Message Format
The format of the BIER Echo Request/Reply message, preceded by the
BIER OAM header (Figure 1), 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 Type | Proto | Reserved | BIER
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OAM
| BIER Echo Request/Reply Length | Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------
| QTF | RTF | Reply Mode | Return Code | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Sent |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Received |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: BIER Echo Request/Reply Format
Kumar, et al. Expires 1 December 2026 [Page 6]
Internet-Draft BIER Ping May 2026
Echo Type - a six-bit field . Valid values are listed in Table 1.
Proto - a six-bit field. It MUST be set to 0 for Echo Request/
Reply header.
Reserved - a two-octet field.d. The Reserved field MUST be zeroed
on transmit and MUST be ignored on receipt.
BIER Echo Request/Reply Length a four-octet field that reflects
the length of the BIER Echo Request/Reply message in octets,
including the BIER OAM header Section 3.
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 field is in the IEEE 1588-2008 (1588v2)
Precision Time Protocol (PTP) [IEEE.1588.2008] 64-bit truncated
version (48-bit sec + 16-bit nsec) format.
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 field's value is 3, the format of the
Timestamp Received is as defined in IEEE 1588-2008 (1588v2)
Precision Time Protocol [IEEE.1588.2008] for 64-bit truncated
version (48-bit sec + 16-bit nsec). The Initiator MUST zero RTF
in the Echo Request, and the Responder MUST ignore the value on
receipt.
+=======+===================+
| Value | Description |
+=======+===================+
| 1 | BIER Echo Request |
+-------+-------------------+
| 2 | BIER Echo Reply |
+-------+-------------------+
Table 1: BIER Echo Type
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.
Kumar, et al. Expires 1 December 2026 [Page 7]
Internet-Draft BIER Ping May 2026
The Reply Mode - a one-octet field. The value MUST be set to one
of the values from Table 2.
+=======+===================================+
| Value | Description |
+=======+===================================+
| 1 | Do not Reply |
+-------+-----------------------------------+
| 2 | Reply via an IPv4/IPv6 UDP packet |
+-------+-----------------------------------+
| 3 | Reply via a BIER packett |
+-------+-----------------------------------+
Table 2: BIER Reply Mode
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.
The Responder BFR uses the BFIR-id field in the BIER header to
determine which IP address family to use in the IP/UDP
encaspulation. If the BFIR-id is associated with IPv4 and IPv6
addresses, the Responder uses its local policy to select the
address family. 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 a 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 Return Code MUST be set to
zero by the Initiator of a BIER Echo Request, and ignored on its
receipt. The value of the Return Code field MUST be set to one of
the values defined in Section 3.3, if the Type is "BIER Echo
Reply".
Reserved2 - a one-octet field. The Reserved2 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.
Kumar, et al. Expires 1 December 2026 [Page 8]
Internet-Draft BIER Ping May 2026
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 values in Table 3.
+=======+======================================================+
| Value | Description |
+=======+======================================================+
| 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 |
+-------+------------------------------------------------------+
Table 3: BIER Echo Return Code
"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 1 December 2026 [Page 9]
Internet-Draft BIER Ping May 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 value of the BIFT-id field, representing a particular Bit
Index Forwarding Table (see Section 6.4. of [RFC8279]), a.k.a. 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 Downstream Detailed Mapping (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 1 December 2026 [Page 10]
Internet-Draft BIER Ping May 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) MUST 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 1 December 2026 [Page 11]
Internet-Draft BIER Ping May 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. A
Responder MUST NOT include this TLV in the Echo Reply 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 1 December 2026 [Page 12]
Internet-Draft BIER Ping May 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. If the DDMAP TLV
(Section 3.4.4) is included in the BIER OAM Echo Request packet, one
and only one Target BitString TLV MUST also be included in the
packet.
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
DDMAP TLV.
Kumar, et al. Expires 1 December 2026 [Page 13]
Internet-Draft BIER Ping May 2026
An Initiator MUST NOT include this TLV in Echo Request. A Responder
BFR MUST include the Incoming SI-BitString TLV setting field values
as specified in Section 4.5.
3.4.4. Downstream Detailed Mapping TLV
The Downstream Detailed Mapping object is an optional TLV that an
Initiator MAY include in a BIER Echo Request message. Only one DDMAP
TLV MAY appear in an BIER Echo Request. The presence of a DDMAP TLV
is a request that the Responder MUST include in its BIER Echo Reply
message DDMAP TLV for each interface over which this BIER OAM Echo
Request could be forwarded. The BFER received the BIER Echo Request
MUST NOT include DDMAP TLV in its BIER Echo Reply.
The format of the Downstream Detailed Mapping TLV shown in Figure 7.
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 Detailed Mapping TLV
Maximum Transmission Unit (MTU) A two-octet field. The MTU is the
size in octets of the largest BIER packet (including the BIER
header) that fits on the interface to the downstream BFR. The
Initiator MUST zero the field, and the Responder ignores its value
in the received BIER Echo Request. The Responder sets the value
in the BIER Echo Reply.
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 Table 4. Any other value MUST be processed
as invalid TLV. The Initiator MUST set the Address Type to IPv4
Kumar, et al. Expires 1 December 2026 [Page 14]
Internet-Draft BIER Ping May 2026
Unnumbered in its BIER Echo Request. The Responder MUST set the
value in its BIER Echo reply according to the type and length of
its downstream interface.
+=======+==================================+
| Value | Address Type |
+=======+==================================+
| 1 | IPv4 Numbered |
+-------+----------------------------------+
| 2 | IPv4 Unnumbered |
+-------+----------------------------------+
| 3 | IPv6 Global Unicast Address |
| | (including Unique Local Address) |
+-------+----------------------------------+
| 4 | IPv6 Link-Local Address Only |
+-------+----------------------------------+
Table 4: The Address Types
Flags The Flags field has the following format:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |I|
+-+-+-+-+-+-+-+-+
Figure 8: 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 (DA) and Downstream
Address Interface (DIA) fields as shown im Table 5.
Kumar, et al. Expires 1 December 2026 [Page 15]
Internet-Draft BIER Ping May 2026
+=======+===========+============+
| Value | DA Length | DIA Length |
+=======+===========+============+
| 1 | 4 | 4 |
+-------+-----------+------------+
| 2 | 4 | 4 |
+-------+-----------+------------+
| 3 | 16 | 16 |
+-------+-----------+------------+
| 4 | 16 | 4 |
+-------+-----------+------------+
Table 5: The Address Type Lengths
where:
DA Length
Downstream Address field Length
DIA Length
Downstream Interface Address field Length
If the Address Type is "IPv4 Numbered" (1), the Downstream Address
field 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 "IPv4 Unnumbered" (2), the Downstream
Address field 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 "IPv6 Global Unicast Address (including
Unique Local Address)" (3), the Downstream Address MUST be set to
IPv6 BFR-Prefix of downstream BFR and Downstream Interface Address
is set to the downstream interface IPv6 Global Unicast Address
(including Unique Local Address).
If the Address Type is "IPv6 Link-Local Address Only" (4), the
Downstream Address MUST be set to the IPv6 BFR-Prefix of the
downstream BFR, and the Downstream Interface Address is set to the
index assigned by the responding BFR to the interface.
The Initiator MUST set the Downstream Address to 224.0.0.2, and the
Downstream Interface Address MUST be set to 0 in the BIER Echo
Request. The Responder MUST ignore these values in the received BIER
Echo Request.
Kumar, et al. Expires 1 December 2026 [Page 16]
Internet-Draft BIER Ping May 2026
3.4.4.1. Downstream Detailed Mapping Sub-TLVs
This section defines the optional Sub-TLVs that can be included in
DDMAP TLV in Table 6.
+=======+========================+
| Value | Description |
+=======+========================+
| 1 | Multipath Entropy Data |
+-------+------------------------+
| 2 | Egress BitString |
+-------+------------------------+
Table 6: Sub-TLV for the
Downstream Detailed Mapping
TLV
Any value other than listed in Table 6 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) MUST be included in
the BIER Echo Reply.
3.4.4.1.1. MPLS Multipath Entropy Data Sub-TLV
MPLS Multipath Entropy Data sub-TLV is applicable for BIER Echo
Request packets encapsulated in MPLS. Encoding of multipath
information for other data planes, e.g., IPv6, is for further study.
If the MPLS Multipath Entropy Data sub-TLV is present in the BIER
Echo Request packet encapsulated in a non-MPLS data plane, it MUST be
ignored by the responding BFR.
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 9: The Format of the Multipath Data Blob
M Flag This flag is set to 0 if all packets will be forwarded out
Kumar, et al. Expires 1 December 2026 [Page 17]
Internet-Draft BIER Ping May 2026
through the interface defined in the DDMAP 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 downstream interface as defined in Section 6.1 of [RFC8279].
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 10: 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 downstream
interface as defined in Section 6.1 of [RFC8279].
Kumar, et al. Expires 1 December 2026 [Page 18]
Internet-Draft BIER Ping May 2026
3.4.5. Responder BFER TLV
The BFER replying to the request MAY include the Responder BFER TLV
in its BIER Echo Reply. An Initiator MUST NOT include this TLV in
Echo Request. 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 11: The Responder BFER TLV Format
Length A two-octet field. The value MUST be set to four.
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 in its BIER Echo Reply. An Initiator MUST NOT include this TLV
in Echo Request. 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 12: The Responder BFR TLV Format
Length The Length field, depending on the Address Type value - 8 or
Kumar, et al. Expires 1 December 2026 [Page 19]
Internet-Draft BIER Ping May 2026
20.
Reserved A two-octet field. The value MUST be zeroed on
transmission and ignored on receipt.
Address Type A two-octet field. Set according to Table 7. Any
other value is invalid.
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.
+=======+==============+
| Value | Address Type |
+=======+==============+
| 1 | IPv4 Address |
+-------+--------------+
| 2 | IPv6 Address |
+-------+--------------+
Table 7: The Address Types
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:
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 13: 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.
Kumar, et al. Expires 1 December 2026 [Page 20]
Internet-Draft BIER Ping May 2026
Address Type A two-octet field. Set its value according to Table 4.
Ingress Interface Address
A four or sixteen-octet-long field. It lists an address
associated with the interface on which the BIER Echo Request
received.
3.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 14: The Erroneous Echo Request TLV Format
Pointer A four-octet field that identifies the octet offset within
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 the BIER header (Section 2.1.1.1 of [RFC8296]) expired.
Kumar, et al. Expires 1 December 2026 [Page 21]
Internet-Draft BIER Ping May 2026
* Hop Limit in the IPv6 header (Section 2 of
[I-D.ietf-bier-bierin6]) expired.
The use of the Router Alert label has been deprecated by [RFC9570].
Processing of the received BIER OAM packet with an unknown value of
the Message Type field (Figure 1) is stopped, and the event MUST be
logged 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. BFER ECMP Discovery Within a BIER Domain with MPLS Underlay
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.
When an operator performs BFER ECMP discovery within a BIER domain
over MPLS underlay, the Initiator MUST include MPLS Multipath Entropy
Data Sub-TLV in DDMAPTLV. 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 the Initiator SHOULD monotonically increase the
Sequence Number, e.g., increment it by one 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.
Kumar, et al. Expires 1 December 2026 [Page 22]
Internet-Draft BIER Ping May 2026
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" MUST unset the respective BFR-ID from Target SI-
BitString for any subsequent Echo Request.
The Initiator MAY include DDMAP TLV (Section 3.4.4) in the Echo
Request to query additional information from transit BFRs and BFERs.
In case of ECMP discovery within a BIER domain with the MPLS
underlay, the Initiator MUST include the MPLS Multipath Entropy Data
Sub-TLV and MUST set the Target SI-BitString TLV carrying a specific
BFER ID.
The Initiator MUST encapsulate the OAM packet with the BIER header
and MUST set the Proto as 5. In ping mode, the TTL field in the BIER
header MUST be set to 255. In traceroute mode, the TTL in the BIER
header 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.
Kumar, et al. Expires 1 December 2026 [Page 23]
Internet-Draft BIER Ping May 2026
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, 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) MUST be included in the BIER Echo Reply. If the
packet sanity check is fine, it MUST 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.
BIFT-id-L
The BIFT-id field in the BIER header of the received BIER 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 MPLS
Multipath Entropy Data Sub-TLV.
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 value from
the BIFT-id field of the BIER header of the received BIER Echo
Request is copied to BIFT-id-L, and the BIER header is copied to
Header-H. If the received Echo Request carries Target SI-BitString
TLV, a BFR MUST run the boolean AND operation between BitString in
Kumar, et al. Expires 1 December 2026 [Page 24]
Internet-Draft BIER Ping May 2026
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 BIFT-id-L does not correspond to the BIFT-id 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.
* If the value in the Reply Mode field is unknown, the Receiver MUST
set Reply-Flag=0 and go to Section 4.5.
* The Receiver sets the Best-return-code to "Malformed Echo Request
received" if the value of the QTF field is neither 2, nor 3.
Also, the Erroneous Echo Request TLV (Section 3.4.8) MUST be
included in the BIER Echo Reply. Go to Section 4.5.
* The Receiver sets the Best-return-code to "Malformed Echo Request
received" if none or more than one Original SI-BitString TLV found
in the received BIER Echo Request. Also, the Erroneous Echo
Request TLV (Section 3.4.8) MUST be included in the BIER Echo
Reply. Go to Section 4.5.
* The Receiver sets the Best-return-code to "Malformed Echo Request
received" if DDMAP TLV is present in the BIER Echo Request message
and none or more than one Target SI-BitString TLVs found. Also,
the Erroneous Echo Request TLV (Section 3.4.8) MUST be included in
the BIER Echo Reply. Go to Section 4.5.
* The Receiver sets the Best-return-code to "Malformed Echo Request
received" if the Incoming S_-BitString TLV is present in the BIER
Echo Request message. Also, the Erroneous Echo Request TLV
(Section 3.4.8) MUST be included in the BIER Echo Reply. Go to
Section 4.5.
* 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.
Kumar, et al. Expires 1 December 2026 [Page 25]
Internet-Draft BIER Ping May 2026
* 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 MPLS 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 and
MPLS 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 DDMAP 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.
Kumar, et al. Expires 1 December 2026 [Page 26]
Internet-Draft BIER Ping May 2026
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
DDMAP 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 MUST 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 BIFT-id-L. Responder BFR MUST 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.
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 downstream interface over which the packet
will be replicated and include the respective Multipath Entropy
Data Sub-TLV. For each downstream 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 downstream interface over which the packet
will be replicated. For each downstream 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
Kumar, et al. Expires 1 December 2026 [Page 27]
Internet-Draft BIER Ping May 2026
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 DDMAP TLV, the Initiator MUST copy the
TLV 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.
5. 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 TBD1
Kumar, et al. Expires 1 December 2026 [Page 28]
Internet-Draft BIER Ping May 2026
5.2. BIER OAM as BIER NEXT Protocol
IANA is requested to update the BIER Next Protocol Identifiers
registry as follows:
+=======+=============+===============+
| Value | Description | Reference |
+=======+=============+===============+
| 5 | OAM Packet | This document |
+-------+-------------+---------------+
Table 8: BIER OAM as BIER Next Protocol
5.3. BIER OAM Registry Group
IANA is requested to create and maintain the "BIER OAM" registry
group containing the registries listed below.
5.4. 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 - 58 - IETF Review
59 - 61 - Experimental Use (Reserved, not to be assigned)
62 - 63 - Private Use (Reserved, not to be assigned)
Kumar, et al. Expires 1 December 2026 [Page 29]
Internet-Draft BIER Ping May 2026
+=========+===============================+===============+
| Value | Description | Reference |
+=========+===============================+===============+
| 0 | Reserved | This document |
+---------+-------------------------------+---------------+
| 1 | BIER Echo Request | This document |
+---------+-------------------------------+---------------+
| 2 | BIER Echo Reply | This document |
+---------+-------------------------------+---------------+
| 3 - 58 | Unassigned | This document |
+---------+-------------------------------+---------------+
| 59 - 61 | Reserved for Experimental Use | This document |
+---------+-------------------------------+---------------+
| 62 - 63 | Reserved for Private Use | This document |
+---------+-------------------------------+---------------+
Table 9: BIER OAM Message Type
5.5. 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.5.1. BIER Echo Request/Echo Reply Message Types
IANA is requested to create in the in the BIER OAM registry group the
BIER Echo Types registry as follows:
Registry Name: BIER Echo Types
Assignment Policy:
0 - 247 - IETF Review
248 - 251 - Experimental Use (Reserved, not to be assigned)
252 - 255 - Private Use (Reserved, not to be assigned)
Kumar, et al. Expires 1 December 2026 [Page 30]
Internet-Draft BIER Ping May 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 10: BIER Echo Types
5.5.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 - 247 - IETF Review
248 - 251 - Experimental Use (Reserved, not to be assigned)
252 - 255 - Private Use (Reserved, not to be assigned)
Kumar, et al. Expires 1 December 2026 [Page 31]
Internet-Draft BIER Ping May 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 a BIER packet | This document |
+-----------+-----------------------------------+---------------+
| 4 - 191 | Unassigned | This document |
+-----------+-----------------------------------+---------------+
| 192 - 247 | Unassigned | This document |
+-----------+-----------------------------------+---------------+
| 248-251 | Reserved for Experimental Use | This document |
+-----------+-----------------------------------+---------------+
| 252-255 | Reserved for Private Use | This document |
+-----------+-----------------------------------+---------------+
Table 11: BIER Echo Reply Modes
5.5.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 - 247 - IETF Review
248 - 251 - Experimental Use (Reserved, not to be assigned)
252 - 255 - Private Use (Reserved, not to be assigned)
Kumar, et al. Expires 1 December 2026 [Page 32]
Internet-Draft BIER Ping May 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 12: BIER Echo Return Codes
5.6. 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 1 December 2026 [Page 33]
Internet-Draft BIER Ping May 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 | This range is for TLVs and |
| | Action | sub-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 13: TLVs
5.6.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.6
Kumar, et al. Expires 1 December 2026 [Page 34]
Internet-Draft BIER Ping May 2026
The TLVs requested by this document for the IANA consideration are
listed in Table 14.
+======+==================+===============+=========================+
| Type | TLV Name | Reference | Sub-TLV Registry |
+======+==================+===============+=========================+
| 0 | Reserved | This | |
| | | document | |
+------+------------------+---------------+-------------------------+
| 1 | Original SI- | This | No Sub-TLVs |
| | BitString | document | |
+------+------------------+---------------+-------------------------+
| 2 | Target SI- | This | No Sub-TLVs |
| | BitString | document | |
+------+------------------+---------------+-------------------------+
| 3 | Incoming SI- | This | No Sub-TLVs |
| | BitString | document | |
+------+------------------+---------------+-------------------------+
| 4 | Downstream | This | Link the Sub-TLVs for |
| | Detailed Mapping | document | TLV Type 4 sub-registry |
+------+------------------+---------------+-------------------------+
| 5 | Responder BFER | This | No Sub-TLVs |
| | | document | |
+------+------------------+---------------+-------------------------+
| 6 | Responder BFR | This | No Sub-TLVs |
| | | document | |
+------+------------------+---------------+-------------------------+
| 7 | Ingress | This | No Sub-TLVs |
| | Interface | document | |
+------+------------------+---------------+-------------------------+
Table 14: TLVs
5.6.2. Sub-TLVs for TLV Type 4
IANA is requested to create in the registry for the Type 4
(Downstream Detailed Mapping) a sub-registry Sub-TLVs for Type 4.
Registry Name: Sub-TLVs for Type 4
Assignment Policy: Section 5.6
Kumar, et al. Expires 1 December 2026 [Page 35]
Internet-Draft BIER Ping May 2026
+======+=============================+===============+
| Type | Sub-TLV Name | Reference |
+======+=============================+===============+
| 0 | Reserved | This document |
+------+-----------------------------+---------------+
| 1 | MPLS Multipath Entropy Data | This document |
+------+-----------------------------+---------------+
| 2 | Egress BitString | This document |
+------+-----------------------------+---------------+
Table 15: TLVs
6. Security Considerations
The security considerations of [RFC8296], and through it of
[RFC8279], apply to this specification.
The security considerations for BIER Ping are similar to ICMP
[RFC0792], ICMPv6 [RFC4443], and 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 1 December 2026 [Page 36]
Internet-Draft BIER Ping May 2026
8. References
8.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 1 December 2026 [Page 37]
Internet-Draft BIER Ping May 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>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[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>.
Kumar, et al. Expires 1 December 2026 [Page 38]
Internet-Draft BIER Ping May 2026
[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-13, 23 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-
bierin6-13>.
Contributors' Addresses
Nobo Akiya
Big Switch Networks
Japan
Email: nobo.akiya.dev@gmail.com
Lianshu Zheng
Individual Contributor
China
Email: veronique_cheng@hotmail.com
Authors' Addresses
Nagendra Kumar
NVIDIA
Email: nagendrakumar.nainar@gmail.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
Independent
Email: gregimirsky@gmail.com
Kumar, et al. Expires 1 December 2026 [Page 39]