draft-ietf-bier-ping-08.txt		draft-ietf-bier-ping-10.txt
	Network Work group N. Kumar		Network Work group N. Kumar
	Internet-Draft C. Pignataro		Internet-Draft C. Pignataro
	Intended status: Standards Track Cisco Systems, Inc.		Intended status: Standards Track Cisco Systems, Inc.
	Expires: 7 September 2023 N. Akiya		Expires: 20 November 2023 N. Akiya
	Big Switch Networks		Big Switch Networks
	L. Zheng		L. Zheng
	Individual Contributor		Individual Contributor
	M. Chen		M. Chen
	Huawei Technologies		Huawei Technologies
	G. Mirsky		G. Mirsky
	Ericsson		Ericsson
	6 March 2023		19 May 2023
	BIER Ping and Trace		BIER Ping and Trace
	draft-ietf-bier-ping-08		draft-ietf-bier-ping-10
	Abstract		Abstract
	Bit Index Explicit Replication (BIER) is an architecture that		Bit Index Explicit Replication (BIER) is an architecture that
	provides optimal multicast forwarding through a "BIER domain" without		provides optimal multicast forwarding through a "BIER domain" without
	requiring intermediate routers to maintain any multicast related per-		requiring intermediate routers to maintain any multicast-related per-
	flow state. BIER also does not require any explicit tree-building		flow state. BIER also does not require any explicit tree-building
	protocol for its operation. A multicast data packet enters a BIER		protocol for its operation. A multicast data packet enters a BIER
	domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the		domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the
	BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).		BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).
	The BFIR router adds a BIER header to the packet. The BIER header		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		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		to forward the packet to. The set of BFERs to which the multicast
	packet needs to be forwarded is expressed by setting the bits that		packet needs to be forwarded is expressed by setting the bits that
	correspond to those routers in the BIER header.		correspond to those routers in the BIER header.
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 7 September 2023.		This Internet-Draft will expire on 20 November 2023.
	Copyright Notice		Copyright Notice
	Copyright (c) 2023 IETF Trust and the persons identified as the		Copyright (c) 2023 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions used in this document . . . . . . . . . . . . . . 3		2. Conventions used in this document . . . . . . . . . . . . . . 3
	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4		2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
	3. BIER OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. BIER OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. BIER OAM message format . . . . . . . . . . . . . . . . . 4		3.1. BIER OAM message format . . . . . . . . . . . . . . . . . 4
	3.2. Return Code . . . . . . . . . . . . . . . . . . . . . . . 6		3.2. Return Code . . . . . . . . . . . . . . . . . . . . . . . 7
	3.3. BIER OAM TLV . . . . . . . . . . . . . . . . . . . . . . 8		3.3. BIER OAM TLV . . . . . . . . . . . . . . . . . . . . . . 9
	3.3.1. Original SI-BitString TLV . . . . . . . . . . . . . . 8		3.3.1. Original SI-BitString TLV . . . . . . . . . . . . . . 9
	3.3.2. Target SI-BitString TLV . . . . . . . . . . . . . . . 9		3.3.2. Target SI-BitString TLV . . . . . . . . . . . . . . . 10
	3.3.3. Incoming SI-BitString TLV . . . . . . . . . . . . . . 10		3.3.3. Incoming SI-BitString TLV . . . . . . . . . . . . . . 11
	3.3.4. Downstream Mapping TLV . . . . . . . . . . . . . . . 10		3.3.4. Downstream Mapping TLV . . . . . . . . . . . . . . . 12
	3.3.5. Responder BFER TLV . . . . . . . . . . . . . . . . . 13		3.3.5. Responder BFER TLV . . . . . . . . . . . . . . . . . 15
	3.3.6. Responder BFR TLV . . . . . . . . . . . . . . . . . . 13		3.3.6. Responder BFR TLV . . . . . . . . . . . . . . . . . . 15
	3.3.7. Upstream Interface TLV . . . . . . . . . . . . . . . 14		3.3.7. Upstream Interface TLV . . . . . . . . . . . . . . . 16
	3.3.8. Reply-To TLV . . . . . . . . . . . . . . . . . . . . 15		3.4. Multipath Entropy Data Encoding . . . . . . . . . . . . . 17
	3.4. Multipath Entropy Data Encoding . . . . . . . . . . . . . 16		4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 17
	4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 16		4.1. BIER OAM Processing . . . . . . . . . . . . . . . . . . . 17
	4.1. BIER OAM Processing . . . . . . . . . . . . . . . . . . . 16
	4.2. Per BFER ECMP Discovery . . . . . . . . . . . . . . . . . 17		4.2. Per BFER ECMP Discovery . . . . . . . . . . . . . . . . . 17
	4.3. Sending BIER Echo Request . . . . . . . . . . . . . . . . 17		4.3. Sending BIER Echo Request . . . . . . . . . . . . . . . . 18
	4.4. Receiving BIER Echo Request . . . . . . . . . . . . . . . 18		4.4. Receiving BIER Echo Request . . . . . . . . . . . . . . . 19
	4.5. Sending Echo Reply . . . . . . . . . . . . . . . . . . . 20		4.5. Sending Echo Reply . . . . . . . . . . . . . . . . . . . 21
	4.6. Receiving Echo Reply . . . . . . . . . . . . . . . . . . 21		4.6. Receiving Echo Reply . . . . . . . . . . . . . . . . . . 22
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	5.1. BIER OAM Registry . . . . . . . . . . . . . . . . . . . . 22		5.1. UDP Port Number . . . . . . . . . . . . . . . . . . . . . 22
	5.2. Message Types, Reply Modes, Return Codes . . . . . . . . 22		5.2. BIER OAM Parameters . . . . . . . . . . . . . . . . . . . 22
	5.3. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 22		5.3. BIER OAM Message Type . . . . . . . . . . . . . . . . . . 22
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 23		5.4. BIER Echo Request/Echo Reply Parameters . . . . . . . . . 23
	7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23		5.4.1. BIER Echo Request/Echo Reply Message Types . . . . . 23
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		5.4.2. BIER Echo Reply Modes . . . . . . . . . . . . . . . . 24
	8.1. Normative References . . . . . . . . . . . . . . . . . . 23		5.4.3. BIER Echo Return Codes . . . . . . . . . . . . . . . 25
	8.2. Informative References . . . . . . . . . . . . . . . . . 24		5.5. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24		6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
			7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 28
			8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
			8.1. Normative References . . . . . . . . . . . . . . . . . . 28
			8.2. Informative References . . . . . . . . . . . . . . . . . 29
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
	1. Introduction		1. Introduction
	[RFC8279] introduces and explains BIER architecture that provides		[RFC8279] introduces and explains BIER architecture that provides
	optimal multicast forwarding through a "BIER domain" without		optimal multicast forwarding through a "BIER domain" without
	requiring intermediate routers to maintain any multicast related per-		requiring intermediate routers to maintain any multicast-related per-
	flow state. BIER also does not require any explicit tree-building		flow state. BIER also does not require any explicit tree-building
	protocol for its operation. A multicast data packet enters a BIER		protocol for its operation. A multicast data packet enters a BIER
	domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the		domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the
	BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).		BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).
	The BFIR router adds a BIER header to the packet. The BIER header		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		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		to forward the packet to. The set of BFERs to which the multicast
	packet needs to be forwarded is expressed by setting the bits that		packet needs to be forwarded is expressed by setting the bits that
	correspond to those routers in the BIER header.		correspond to those routers in the BIER header.
	This document describes the mechanism and basic BIER Operations,		Operations, Administration, and Maintenance (OAM) mechanisms are
	Administration, and Maintenance (OAM) packet format that can be used		expected to support the detection of network failures. After the
	to perform failure detection and isolation on the BIER data plane		detection, operators localize and characterize the network defect. A
	without any dependency on other layers like the IP layer.		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.
	2. Conventions used in this document		2. Conventions used in this document
	2.1. Terminology		2.1. Terminology
	BFER - Bit Forwarding Egress Router		BFER - Bit-Forwarding Egress Router
	BFIR - Bit Forwarding Ingress Router		BFIR - Bit-Forwarding Ingress Router
			BFR - Bit-Forwarding Router
	BIER - Bit Index Explicit Replication		BIER - Bit Index Explicit Replication
	DDMAP - Downstream Detailed Mapping TLV		DDMAP - Downstream Detailed Mapping TLV
	ECMP - Equal Cost Multi-Path		ECMP - Equal Cost Multi-Path
	OAM - Operation, Administration, and Maintenance		OAM - Operation, Administration, and Maintenance
	SI - Set Identifier		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 Protocol
	2.2. Requirements Language		2.2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. BIER OAM		3. BIER OAM
	BIER OAM is defined to stay within the BIER layer by directly		BIER OAM is defined to stay within the BIER layer by directly
	following the BIER header without mandating the need for IP header.		following the BIER header without mandating the need for an IP
	[RFC8296] defines a 4-bit field as "Proto" to identify the payload		header. [RFC8296] defines a 4-bit field as "Proto" to identify the
	following the BIER header. When the payload is BIER OAM, the "Proto"		payload following the BIER header. When the payload is BIER OAM, the
	field will be set to 5 as defined in [RFC8296]		"Proto" field will be set to 5 as defined in [RFC8296]
	3.1. BIER OAM message format		3.1. BIER OAM message format
	The BIER OAM packet header format that follows BIER header is as		The BIER OAM packet header format that follows the BIER header is
	follows:		displayed in Figure 1.
	0 1 2 3		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		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 | Message Type | Proto | Reserved |		| Ver | Message Type | Proto | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| OAM Message Length |		| OAM Message Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Message Type Dependent Data ~		~ Message Type Dependent Data ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Ver		Figure 1: BIER OAM Header
	Set to 1.
	Message Type		Ver - a four-bit field that indicates the current 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.
	This document defines the following Message Types:		Message Type - a six-bit field that identifies OAM protocol.
			Values defined in this document are as follows:
	Type Value Field		Value Description
	-------- ---------------		-------- ---------------
	1 BIER Echo Request		1 Echo Request
	2 BIER Echo Reply		2 Echo Reply
	Proto		Proto - a six-bit field. This field is used to define if there is
			any data packet immediately following the OAM payload, which may
			be used by a hybrid OAM [RFC7799]. This field MUST be set to 0 if
			there is no data packet following the OAM payload. Value is one
			from the IANA registry "BIER Next Protocol Identifiers" [RFC8296].
	This field is used to define if there is any data packet		Reserved - a fourteen-bit field. The value MUST be zeroed on
	immediately following the OAM payload which is used for passive		transmission and ignored on receipt.
	OAM functionality. This field is set to 0 if there is no data
	packet following OAM payload.
	OAM Message Length		OAM Message Length - a two-octet field that reflects the length of
	This field defines the length of the OAM message including the		the OAM message, including the header and the Messsage Type
	header and Dependent Data field.		Dependent Data.
	The Echo Request/Reply header format is as follows:		Message Type Dependant Data - a variable-length field that
			includes the OAM message identified by the value of the Message
			Type filed.
			The Echo Request/Reply header format displayed in Figure 2
	0 1 2 3		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		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 |		| Ver | Echo Req/Rep | Proto | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| QTF | RTF | Reply mode | Return Code | Reserved |		| Echo Request/Reply Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| QTF | RTF | Reply Mode | Return Code | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender's Handle |		| Sender's Handle |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence Number |		| Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TimeStamp Sent |		| Timestamp Sent |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| |
	| TimeStamp Sent |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TimeStamp Received |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TimeStamp Received |		| Timestamp Received |
			| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ TLVs ~		~ TLVs ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Proto		Figure 2: BIER Echo Request/Reply Format
	Set to 0 for Echo Request/Reply header.		Proto field MUST be set to 0 for Echo Request/Reply header.
	QTF		QTF (Querier Timestamp Format) - a four-bit field. When the field
			is set to 2, the Timestamp Sent field is (in seconds and
			microseconds, according to the Initiator's clock) in 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 MAY be
			considered as a sanity check failure.
	Querier Timestamp Format. When set to 2, the Timestamp Sent field		RTF (Responder Timestamp Format) - a four-bit field. When the
	is (in seconds and microseconds, according to the Initiator's		field is set to 2, the Timestamp Received field is (in seconds and
	clock) in NTP format [RFC5905]. When set to 3, the timestamp		microseconds, according to the Initiator's clock) in NTP format
	format is in IEEE 1588-2008 (1588v2) Precision Time Protocol		[RFC5905]. When filed's value is 3, the format of the Timestamp
	format. Any other value MAY be considered as sanity check failure		Received is as defined in IEEE 1588-2008 (1588v2) Precision Time
			Protocol [IEEE.1588.2008]. Any other value MAY be considered as a
			sanity check failure.
	RTF		The sender of the BIER Echo Request might receive the BIER Echo Reply
	Responder Timestamp Format. When set to 2, the Timestamp Received		with RTF different from the Sender's QTF, Thus, the Sender MUST be
	field is (in seconds and microseconds, according to the		able to interpret both timestamp formats, i.e., NTP [RFC5905] and PTP
	Initiator's clock) in NTP format [RFC5905]. When set to 3, the		[IEEE.1588.2008].
	timestamp format is in IEEE 1588-2008 (1588v2) Precision Time
	Protocol format. Any other value MAY be considered as sanity
	check failure.
	Reply mode		The Reply Mode - a one-octet field. The value MUST be set to one
	The Reply mode is set to one of the below:		of the following values:
	Value Meaning		Value Description
	-------- ---------------		-------- ---------------
	1 Do not Reply		1 Do not Reply
	2 Reply via IPv4/IPv6 UDP packet.		2 Reply via IPv4/IPv6 UDP packet
	3 Reply via BIER packet		3 Reply via BIER packet
	When Reply mode is set to 1, the receiver will not send any reply.		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		This mode can be used for unidirectional path validation. When
	Reply mode is set to 2, the Responder BFR encapsulates the Echo reply		the Reply Mode is set to 2, the Responder Bit-Forwarding Router
	payload with IP header. When the Initiator intends to validate the		(BFR) encapsulates the Echo reply payload with the IP/UDP header.
	return BIER path, the Reply mode will be set to 3 so that the		When the Initiator intends to validate the return BIER path, the
	Responder BFR will encapsulates the Echo Reply with the BIER header.		Reply Mode will be set to 3 so that the Responder BFR will
			encapsulate the Echo Reply with the BIER header.
	Return Code		Return Code - a one-octet field. The value MUST be set to zero if
	Set to zero if Type is "BIER Echo Request". Set to one of the		the Type is "BIER Echo Request". The value of the Return Code
	value defined in section 3.2, if Type is "BIER Echo Reply".		filed MUST be set to one of the values defined in Section 3.2, if
			the Type is "BIER Echo Reply".
	Reserved		Reserved - a one-octet field. The Reserved field MUST be zeroed
	Set to all zero value.		on transmit and MUST be ignored on receipt.
	Sender's Handle, Sequence Number, and Timestamp		Sender's Handle - a four-octet field. The Sender's Handle is
	The Sender's Handle is filled by the Initiator, and returned		filled by the Initiator, and returned unchanged by responder BFR.
	unchanged by responder BFR. This value can be used for matching		This value can be used for matching the replies to the request.
	the replies to the request.
	The Sequence Number is assigned by the Initiator and can be used		Sequence Number - a four-octet field. The value of the field is
	to detect any missed replies.		assigned by the Initiator and can be used to detect any missed
			replies.
	The Timestamp Sent is the time when the Echo Request is sent. The		Timestamp - each field (Sent and Received) is an eight-octet
	TimeStamp Received in Echo Reply is the time (accordingly to		field. The Timestamp Sent is the time when the Echo Request is
	responding BFR clock) that the corresponding Echo Request was		sent. The Timestamp Received in Echo Reply is the time
	received. The format depends on the QTF/RTF value.		(accordingly to responding BFR clock) that the corresponding Echo
			Request was received. The format depends on the QTF/RTF value.
	TLVs		TLVs - Carries the TLVs as defined in Section 3.3.
	Carries the TLVs as defined in Section 3.3.
	3.2. Return Code		3.2. Return Code
	The responder uses the Return Code field to reply with a validity		The responder uses the Return Code field to reply with a validity
	check or other error message to Initiator. It does not carry any		check or other error message to Initiator. It does not carry any
	meaning in Echo Request and MUST be set to zero.		meaning in Echo Request and MUST be set to zero. The Return Code can
			be one of the following:
	The Return Code can be one of the following:
	Value Value Meaning		Value Value Meaning
	------ ---------------		------ ---------------
	0 No return code		0 No return code
	1 Malformed Echo Request received		1 Malformed Echo Request received
	2 One or more of the TLVs is not supported		2 One or more of the TLVs is not supported
	3 Replying BFR is the only BFER in header Bitstring		3 Replying BFR is the only BFER in header BitString
	4 Replying BFR is one of the BFER in header Bitstring		4 Replying BFR is one of the BFERs in header BitString
	5 Packet-Forward-Success		5 Packet-Forward-Success
	6 Invalid Multipath Info Request		6 Invalid Multipath Info Request
	8 No matching entry in the forwarding table		8 No matching entry in the forwarding table
	9 Set-Identifier Mismatch		9 Set-Identifier Mismatch
	10 DDMAP Mismatch		10 DDMAP Mismatch
	"No return code" will be used by Initiator in the Echo Request. This		"No return code" will be used by Initiator in the Echo Request. This
	value MUST NOT be used in Echo Reply.		value MUST NOT be used in Echo Reply.
	"Malformed Echo Request received" will be used by any BFR if the		"Malformed Echo Request received" will be used by any BFR if the
	received Echo Request packet is not properly formatted.		received Echo Request packet is not properly formatted.
	When a receiver does not support any TLV included in the Echo		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		Request, the Return code will be set to "One or more of the TLVs is
	not supported" carrying the respective TLVs.		not supported" carrying the respective TLVs.
	When the received header BitString in the Echo Request packet		When the received header BitString in the Echo Request packet
	contains only its Bit-ID, "Replying BFR is the only BFER in header		contains only its Bit-ID, "Replying BFR is the only BFER in header
	BitString" is set in the reply. This value implies that the receiver		BitString" is set in the reply. This value implies that the receiver
	is BFER and the packet is not forwarded to any more neighbors.		is BFER, and the packet is not forwarded to any more neighbors.
	When the received header BitString in the Echo Request packet		When the received header BitString in the Echo Request packet
	contains its Bit-ID in addition to other Bit-IDs, "Replying BFR is		contains its Bit-ID in addition to other Bit-IDs, "Replying BFR is
	one of the BFER in header BitString" is set in the reply. This value		one of the BFERs in header BitString" is set in the reply. This
	implies that the responder is a BFER and the packet is further		value implies that the responder is a BFER and the packet is further
	forwarded to one or more neighbors.		forwarded to one or more neighbors.
	Any transit BFR will send the Echo Reply with "Packet-Forward-		Any transit BFR will send the Echo Reply with "Packet-Forward-
	Success", if the TLV in the received Echo Request is understood and		Success", if the TLV in the received Echo Request is understood and
	forwarding table has forwarding entries for the BitString. This		the forwarding table has forwarding entries for the BitString. This
	behavior is demonstrated by a transit BFR during traceroute mode.		behavior is demonstrated by a transit BFR during traceroute mode.
	When the Echo Request is received with multipath info for more than		When the Echo Request is received with multipath info for more than
	one BFER, the Return Code is set to "Invalid Multipath Info Request".		one BFER, the Return Code is set to "Invalid Multipath Info Request".
	If the BitString cannot be matched in the local forwarding table, the		If the BitString cannot be matched in the local forwarding table, the
	BFR will use "No matching entry in the forwarding table" in the		BFR will use "No matching entry in the forwarding table" in the
	reply.		reply.
	If the BIER-MPLS label in the received Echo Request is not the one		If the BIER-MPLS label in the received Echo Request is not the one
	assigned for SI in Original SI-BitString TLV, "Set-Identifier		assigned for SI in Original SI-BitString TLV, "Set-Identifier
	Mismatch" is set in order to report the mismatch.		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.3. BIER OAM TLV		3.3. BIER OAM TLV
	This section defines various TLVs that can be used in BIER OAM		This section defines various TLVs that can be used in BIER OAM
	packet. The TLVs (Type-Length-Value tuples) have the following		packet. The TLVs (Type-Length-Value tuples) have the following
	format:		format:
	0 1 2 3		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		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 |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Value ~		~ Value ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 3: Type-Length-Value Format Used in BIER Echo Request/Reply
	TLV Types are defined below; Length is the length of the Value field		TLV Types are defined below; Length is the length of the Value field
	in octets. The Value field depends on the TLV Type.		in octets. The Value field depends on the TLV Type.
	3.3.1. Original SI-BitString TLV		3.3.1. Original SI-BitString TLV
	The Original SI-BitString TLV carries the set of BFER and carries the		The Original SI-BitString TLV carries the set of BFERs and carries
	same BitString that Initiator includes in the BIER header. This TLV		the same BitString that the Initiator includes in the BIER header.
	has the following format:		This TLV has the following format:
	0 1 2 3		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		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 |		| Type = 1 | Length = variable |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Set ID | Sub-domain ID |BS Len| Reserved |		| Set ID | Sub-domain ID |BS Len | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BitString (first 32 bits) ~		| BitString (first 32 bits) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ~		~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BitString (last 32 bits) |		| BitString (last 32 bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 4: The Format of the Original SI-BitString TLV
	Set ID field is set to the value of the Set Identifier to which the		Set ID - a one-octet field that is set to the value of the Set
	BitString belongs to. This value is derived as defined in [RFC8279]		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		Sub-domain ID - a one-octet field that is set to the Sub-domain value
	BitString belongs to.		to which BFER in BitString belongs.
	BS Len is set based on the length of BitString as defined in		BS Len - a four-bit field that is set based on the length of
	[RFC8296]		BitString as defined in [RFC8296] reflected in four-octet words.
	The BitString field carries the set of BFR-IDs that Initiator will		Reserved - a twelve-bit field. Its value MUST be zeroed on
	include in the BIER header. This TLV MUST be included by Initiator		transmission and ignored on receipt.
	in Echo Request packet
			BitString - a variable length field. The BitString field carries the
			set of BFR-IDs that Initiator will include in the BIER header. This
			TLV MUST be included by the Initiator in the Echo Request packet.
	Any Initiator MUST include this TLV in the Echo Request packet.		Any Initiator MUST include this TLV in the Echo Request packet.
	3.3.2. Target SI-BitString TLV		3.3.2. Target SI-BitString TLV
	The Target SI-BitString TLV carries the set of BFER from which the		The Target SI-BitString TLV carries the set of BFERs from which the
	Initiator expects the reply from.This TLV has the following format:		Initiator expects the reply. This TLV has the following format:
	0 1 2 3		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		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 |		| Type = 2 | Length = variable |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Set ID | Sub-domain ID |BS Len| Reserved |		| Set ID | Sub-domain ID |BS Len | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BitString (first 32 bits) ~		| BitString (first 32 bits) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ~		~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BitString (last 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		Set ID field is set to the Set Identifier to which the BitString
	belongs to. This value is derived as defined in [RFC8279]		belongs.This value is derived as defined in [RFC8279].
	Sub-domain ID is set to the Sub-domain value to which BFER in		Sub-domain ID is set to the Sub-domain value to which BFER in
	BitString belongs to.		BitString belongs.
	BS Len is set based on the length of BitString as defined in		BS Len is set based on the length of BitString as defined in
	[RFC8296]		[RFC8296]
			Reserved - the value MUST be zeroed on transmission and ignored on
			receipt.
	The BitString field carries the set of BFR-IDs of BFER(s) that		The BitString field carries the set of BFR-IDs of BFER(s) that
	Initiator expects the response from. The BitString in this TLV may		Initiator expects a response. The BitString in this TLV may be
	be different from the BitString in the BIER header and allows to		different from the BitString in the BIER header and allows control of
	control the BFER responding to the Echo Request. This TLV MUST be		the BFER responding to the Echo Request. This TLV MUST be included
	included by Initiator in BIER OAM packet if the Downstream Mapping		by Initiator in the BIER OAM packet if the Downstream Mapping TLV
	TLV (section 3.3.4) is included.		(Section 3.3.4) is included.
	3.3.3. Incoming SI-BitString TLV		3.3.3. Incoming SI-BitString TLV
	The Incoming SI-BitString TLV will be included by Responder BFR in		The Incoming SI-BitString TLV will be included by Responder BFR in
	Reply message and copies the BitString from BIER header of incoming		Reply message and copies the BitString from the BIER header of
	Echo Request message. This TLV has the following format:		incoming Echo Request message. This TLV has the following format:
	0 1 2 3		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		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 |		| Type = 3 | Length = variable |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Set ID | Sub-domain ID |BS Len| Reserved |		| Set ID | Sub-domain ID |BS Len | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BitString (first 32 bits) ~		| BitString (first 32 bits) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ~		~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BitString (last 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		Set ID field is set to the Set Identifier to which the BitString
	belongs to. This value is derived as defined in [RFC8279]		belongs. This value is derived as defined in [RFC8279]
	Sub-domain ID is set to the Sub-domain value to which BFER in		Sub-domain ID is set to the Sub-domain value to which BFER in
	BitString belongs to.		BitString belongs.
	BS Len is set based on the length of BitString as defined in		BS Len is set based on the length of BitString as defined in
	[RFC8296]		[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		The BitString field copies the BitString from the BIER header of the
	incoming Echo Request. A Responder BFR SHOULD include this TLV in		incoming Echo Request. A Responder BFR SHOULD include this TLV in
	Echo Reply if the Echo Request is received with I flag set in		Echo Reply if the Echo Request is received with the I flag set in
	Downstream Mapping TLV.		Downstream Mapping TLV.
	An Initiator MUST NOT include this TLV in Echo Request.		An Initiator MUST NOT include this TLV in Echo Request.
	3.3.4. Downstream Mapping TLV		3.3.4. Downstream Mapping TLV
	This TLV has the following format:		This TLV has the following format:
	0 1 2 3		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		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 |		| Type = 4 | Length = variable |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MTU | Address Type | Flags |		| MTU | Address Type | Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Downstream Address (4 or 16 octets) |		| Downstream Address (4 or 16 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Downstream Interface Address (4 or 16 octets) |		| Downstream Interface Address (4 or 16 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sub-tlv Length | |		| Sub-TLVs Length | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	. .		. .
	. List of Sub-TLVs .		. List of Sub-TLVs .
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	MTU		Figure 7: The Format of the Downstream Mapping TLV
	Set to MTU value of outgoing interface.
	Address Type		MTU A two-octet field. The value is the Maximum Transmission Unit
			(MTU) value of the egress interface.
	The Address Type indicates the address type and length of IP		Address Type A one-octet field. The Address Type indicates the
	address for the downstream interface. The Address type is set to		address type and length of the IP address for the downstream
	one of the below:		interface. The Address type is set to one of the following
			values:
	Type Addr. Type DA Length DIA Length		Type Addr. Type DA Length DIA Length
	------- --------------- ---------- ----------		------- --------------- ---------- ----------
	1 IPv4 Numbered 4 4		1 IPv4 Numbered 4 4
	2 IPv4 Unnumbered 4 4		2 IPv4 Unnumbered 4 4
	3 IPv6 Numbered 16 16		3 IPv6 Numbered 16 16
	4 IPv6 Unnumbered 16 4		4 IPv6 Unnumbered 16 4
	DA Length - Downstream Address field Length		DA Length
	DIA Length - Downstream Interface Address field Length		Downstream Address (DA) field Length
			DIA Length
			Downstream Interface Address (DIA) field Length
	Flags		Flags
	The Flags field has the following format:		The Flags field has the following format:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Rsvd |I|		| Reserved |I|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	When I flag is set, the Responding BFR MUST include the Incoming SI-		Figure 8: The Flags Field Format
	BitString TLV in Echo Reply message.
			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		Downstream Address and Downstream Interface Address
			each field is either four-octet or sixteen-octet, depending on the
			value of Address Type field.
	If the Address Type is 1, the Downstream Address MUST be set to		If the Address Type is 1, the Downstream Address MUST be set to
	IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address		IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address
	is set to the downstream interface address.		is set to the downstream interface address.
	If the Address Type is 2, the Downstream Address MUST be set to		If the Address Type is 2, the Downstream Address MUST be set to
	IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address		IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address
	is set to the index assigned by upstream BFR to the interface.		is set to the index assigned by upstream BFR to the interface.
	If the Address Type is 3, the Downstream Address MUST be set to		If the Address Type is 3, the Downstream Address MUST be set to
	IPV6 BFR-Prefix of downstream BFR and Downstream Interface Address		IPV6 BFR-Prefix of downstream BFR and Downstream Interface Address
	skipping to change at page 12, line 34 ¶		skipping to change at page 14, line 7 ¶
	This section defines the optional Sub-TLVs that can be included in		This section defines the optional Sub-TLVs that can be included in
	Downstream Mapping TLV.		Downstream Mapping TLV.
	Sub-TLV Type Value		Sub-TLV Type Value
	------------ -------------		------------ -------------
	1 Multipath Entropy Data		1 Multipath Entropy Data
	2 Egress BitString		2 Egress BitString
	3.3.4.1.1. Multipath Entropy Data		3.3.4.1.1. Multipath Entropy Data
	0 1 2 3		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		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 | |		|M| Reserved | |
	+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+ |
	| |		| |
	| (Multipath Information) |		| (Multipath Information) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	M Flag		Figure 9: The Format of the Multipath Data Blob
	This flag is set to 0 if all packets will be forwarded out through		M Flag This flag is set to 0 if all packets will be forwarded out
	the interface defined in the Downstream Mapping TLV. When set to		through the interface defined in the Downstream Mapping TLV. When
	1, Multipath Information will be defined by the Bit masked Entropy		set to 1, Multipath Information will be defined by the Bit masked
	data.		Entropy data.
	Multipath Information		Reserved The value MUST be zeroed on transmission and ignored on
	Entropy Data encoded as defined in section 3.4		receipt.
	3.3.4.1.2. Egress BitString		Multipath Information Entropy Data is encoded as defined in
			Section 3.4.
			3.3.4.1.2. Egress BitString Sub-TLV
	Responder BFR MAY include this Sub-TLV with the rewritten BitString		Responder BFR MAY include this Sub-TLV with the rewritten BitString
	in the outgoing interface as defined in section 6.1 of [RFC8279]		in the outgoing interface as defined in Section 6.1 of [RFC8279].
	0 1 2 3		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Set ID | Sub-domain ID |BS Len| Reserved |		| Type = 2 | Length = variable |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Set ID | Sub-domain ID |BS Len | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BitString (first 32 bits) ~		| BitString (first 32 bits) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ~		~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BitString (last 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 outgoing
			interface as defined in Section 6.1 of [RFC8279].
	3.3.5. Responder BFER TLV		3.3.5. Responder BFER TLV
	The BFER replying to the request MAY include the 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		This TLV identifies the originator of BIER Echo Reply. This TLV has
	the following format:		the following format:
	0 1 2 3		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		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 |		| Type = 5 | Length = 4 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | BFR-ID |		| Reserved | BFR-ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	BFR-ID		Figure 11: The Responder BFER TLV Format
	The BFR-ID field carries the BFR-ID of replying BFER. This TLV		Length A two-octet field. The value MUST be set to four.
	MAY be included by Responding BFER in BIER Echo Reply packet.
			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.3.6. Responder BFR TLV		3.3.6. Responder BFR TLV
	Any transit BFR replying to the request MAY include the Responder BFR		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. This is used to identify the replying BFR without BFR-ID. This
	TLV has the following format:		TLV has the following format:
	0 1 2 3		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		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 = variable |		| TLV Type = 6 | Length = 8 or 20 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | Address Type |		| Reserved | Address Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ BFR-Prefix (4 or 16 bytes) ~		~ BFR-Prefix (4 or 16 bytes) ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Length		Figure 12: The Responder BFD TLV Format
	The Length field varies depending on the Address Type.
	Address Type		Length The Length field, depending on the Address Type value - 8 or
			20.
	Set to 1 for IPv4 or 2 for IPv6.		Reserved A two-octet field. The value MUST be zeroed on
			transmission and ignored on receipt.
	BFR-Prefix		Address Type A two-octet field. Set to 1 for IPv4 or 2 for IPv6.
	This field carries the local BFR-Prefix of the replying BFR. This		BFR-Prefix This field carries the local BFR-Prefix of the replying
	TLV MAY be included by Responding BFR in BIER Echo Reply packet.		BFR. This TLV MAY be included by Responding BFR in BIER Echo
			Reply packet.
	3.3.7. Upstream Interface TLV		3.3.7. Upstream Interface TLV
	The BFR replying to the request MUST include the Upstream Interface		The BFR replying to the request MUST include the Upstream Interface
	TLV. This TLV identifies the incoming interface and the BIER-MPLS		TLV. This TLV identifies the incoming interface and the BIER-MPLS
	label in the incoming Echo Request. This TLV has the following		label in the incoming Echo Request. This TLV has the following
	format:		format:
	0 1 2 3		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		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 = variable |		| TLV Type = 7 | Length = 8 or 20 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | Address Type |		| Reserved | Address Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Upstream Address (4 or 16 bytes) ~		~ Upstream Address (4 or 16 bytes) ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Length		Figure 13: The Upstream Interface TLV Format
	The Length field varies depending on the Address Type.		Length The Length field, depending on the Address Type value - 8 or
			20.
	Address Type		Reserved A two-octet field. The value MUST be zeroed on
			transmission and ignored on receipt.
	Set to 1 for IPv4 numbered, 2 for IPv4 Unnumbered 3 for IPv6		Address Type A two-octet field. Set to 1 for IPv4 numbered, 2 for
	numbered or 4 for IPv6 Unnumbered.		IPv4 Unnumbered, 3 for IPv6 numbered, or 4 for IPv6 Unnumbered.
	Upstream Address		Upstream Address
	As defined in Section 3.3.4		As defined in Section 3.3.4
	3.3.8. Reply-To TLV
	The Initiator BFR MAY include Reply-To TLV in the Echo Request. This
	TLV is used by transit BFR or BFER when the reply mode is 2. The IP
	address will be used to generate the 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TLV Type = 8 | Length = variable |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | Address Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	~ Reply-To Address (4 or 16 bytes) ~
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Length
	The Length field varies depending on the Address Type.
	Address Type
	Set to 1 for IPv4 or 2 for IPv6.
	Reply-To Address
	Set to any locally configured address to which the Echo reply
	should be sent.
	3.4. Multipath Entropy Data Encoding		3.4. Multipath Entropy Data Encoding
	The size of the Entropy field in the BIER header is 20 bits as		The size of the Entropy field in the BIER header is 20 bits, as
	defined in section 2 of [RFC8296]. This encoding is similar to the		defined in Section 2 of [RFC8296]. This encoding is the same as the
	Multipath Type 9 encoding defined in Section 3.4.1.1.1 of [RFC8029].		Multipath Type 9 encoding, defined in Section 3.4.1.1.1 of [RFC8029].
	4. Procedures		4. Procedures
	This section describes aspects of Ping and traceroute operations.		This section describes aspects of Ping and traceroute operations.
	4.1. BIER OAM Processing		4.1. BIER OAM Processing
	A BIER OAM packet MUST be sent to the BIER control plane for OAM		A BIER OAM packet MUST be sent to the BIER control plane for OAM
	processing if one of the following conditions is true:		processing if one of the following conditions is true:
	* The receiving BFR is a BFER.		* The receiving BFR is a BFER.
	* TTL of BIER-MPLS Label expired.		* TTL of BIER-MPLS Label (Section 2.1.1.1 [RFC8296]) expired.
	* Router Alert label is present in the label stack.		The use of the Router Alert label to be deprecated as proposed in
			[I-D.ietf-mpls-lspping-norao].
	4.2. Per BFER ECMP Discovery		4.2. Per BFER ECMP Discovery
	As defined in [RFC8279], BIER follows the unicast forwarding path and		As defined in [RFC8279], BIER follows the unicast forwarding path and
	allows load balancing over ECMP paths between BFIR and BFER. BIER		allows load balancing over ECMP paths between BFIR and BFER. BIER
	OAM MUST support ECMP path discovery between a BFIR and a given BFER		OAM is expected to support ECMP path discovery between a BFIR and a
	and MUST support path validation and failure detection of any		given BFER and MUST support path validation and failure detection of
	particular ECMP path between BFIR and BFER.		any particular ECMP path between BFIR and BFER.
	[RFC8296] proposes the BIER header with the Entropy field that can be		[RFC8296] proposes the BIER header with the Entropy field that can be
	leveraged to exercise all ECMP paths. The Initiator/BFIR will use		leveraged to exercise all ECMP paths. The Initiator/BFIR will use a
	traceroute message to query each hop about the Entropy information		traceroute message to query each hop about the Entropy information
	for each of the downstream paths. To avoid complexity, it is		for each of the downstream paths. To avoid complexity, it is
	suggested that the ECMP query is performed per BFER by carrying		suggested that the ECMP query is performed per BFER by carrying the
	required information in BIER OAM message.		required information in the BIER OAM message.
	The Initiator MUST include Multipath Entropy Data Sub-TLV in		The Initiator MUST include Multipath Entropy Data Sub-TLV in
	Downstream Mapping TLV. It MUST also include the BFER in BitString		Downstream Mapping TLV. It MUST also include the BFER in BitString
	TLV to which the Multipath query is performed.		TLV to which the Multipath query is performed.
	Any transit BFR will reply with Bit-masked Entropy for each		Any transit BFR will reply with Bit-masked Entropy for each
	downstream path as defined in [RFC8029]		downstream path as defined in [RFC8029]
	4.3. Sending BIER Echo Request		4.3. Sending BIER Echo Request
	The Initiator MUST set the Message Type as 1 and Return Code as 0.		The Initiator MUST set the Message Type as 1 and Return Code as 0.
	The Proto field in OAM packet MUST be set to 0. The choice of the		The Proto field in the OAM packet MUST be set to 0. The choice of
	Sender's Handle and Sequence Number is a local matter to the		the Sender's Handle and Sequence Number is a local matter to the
	Initiator and SHOULD increment the Sequence Number by 1 for every		Initiator and SHOULD increment the Sequence Number by 1 for every
	subsequent Echo Request. The QTF field is set to Initiator's local		subsequent Echo Request. The QTF field is set to Initiator's local
	timestamp format and TimeStamp Sent field is set to the time that the		timestamp format, and the TimeStamp Sent field is set to the time
	Echo Request is sent.		that the Echo Request is sent.
	The Initiator MUST include Original SI-BitString TLV. The Initiator		The Initiator MUST include Original SI-BitString TLV. The Initiator
	MUST NOT include more than one Original SI-BitString TLV. The		MUST NOT include more than one Original SI-BitString TLV. The
	Initiator infers the Set Identifier value and Sub-domain ID value		Initiator infers the Set Identifier value and Sub-domain ID value
	from the respective BitString that will be included in the BIER		from the respective BitString that will be included in the BIER
	header of the packet and includes the values in "SI" and Sub-Domain		header of the packet and includes the values in "SI" and Sub-Domain
	ID fields respectively.		ID fields, respectively.
	In Ping mode, the Initiator MAY include Target SI-BitString TLV to		In Ping mode, the Initiator MAY include Target SI-BitString TLV to
	control the responding BFER(s) by listing all the BFERs from which		control the responding BFER(s) by listing all the BFERs from which
	the Initiator expects a response. In the trace route mode, the		the Initiator expects a response. In the traceroute mode, the
	Initiator MAY include Target SI-Bitstring TLV to control the path		Initiator MAY include Target SI-BitString TLV to control the path
	trace towards any specific BFER or set of BFERs. The Initiator on		trace towards any specific BFER or set of BFERs. The Initiator on
	receiving a reply with Return code as "Replying BFR is the only BFER		receiving a reply with the Return code "Replying BFR is the only BFER
	in header Bitstring" or "Replying router is one of the BFER in header		in the header BitString" or "Replying router is one of the BFERs in
	Bitstring", SHOULD unset the respective BFR-id from Target SI-		header BitString" SHOULD unset the respective BFR-id from Target SI-
	BitString for any subsequent Echo Request.		BitString for any subsequent Echo Request.
	When the Reply mode is set to 2, the Initiator MUST include Reply-To		The Initiator MAY include Downstream Mapping TLV (Section 3.3.4) in
	TLV (section 3.3.8) in the Echo Request. The Initiator MUST also
	listen to the UDP port defined in this TLV and process any segment
	received with destination port as the value defined in the TLV and
	sent to control plane for BIER OAM payload processing.
	The Initiator MAY include Downstream Mapping TLV (section 3.3.4) in
	the Echo Request to query additional information from transit BFRs		the Echo Request to query additional information from transit BFRs
	and BFERs. In case of ECMP discovery, the Initiator MUST include the		and BFERs. In case of ECMP discovery, the Initiator MUST include the
	Multipath Entropy Data Sub-TLV and SHOULD set the Target SI-BitString		Multipath Entropy Data Sub-TLV and SHOULD set the Target SI-BitString
	TLV carrying a specific BFER ID.		TLV carrying a specific BFER ID.
	The Initiator MUST encapsulate the OAM packet with BIER header and		The Initiator MUST encapsulate the OAM packet with the BIER header
	MUST set the Proto as 5 and further encapsulates with BIER-MPLS		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		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		traceroute mode, the BIER-MPLS Label TTL is set successively,
	from 1 and MUST stop sending the Echo Request if it receives a reply		starting from 1 and MUST stop sending the Echo Request if it receives
	with Return code as "Replying router is the only BFER in BIER header		a reply with Return code as "Replying router is the only BFER in BIER
	Bitstring" from all BFER listed in Target SI-BitString TLV.		header BitString" from all BFER listed in Target SI-BitString TLV.
	4.4. Receiving BIER Echo Request		4.4. Receiving BIER Echo Request
	Sending a BIER OAM Echo Request to control plane for payload		Sending a BIER OAM Echo Request to control plane for payload
	processing is triggered as mentioned in section 4.1.		processing is triggered as mentioned in Section 4.1.
	Any BFR on receiving Echo Request MUST perform the basic sanity		Any BFR on receiving Echo Request MUST perform the basic sanity
	check. If the BFR cannot parse the OAM Dependent data payload		check. If the BFR cannot parse the OAM Dependent data payload
	completely because the value in the OAM Message Length field is		completely because the value in the OAM Message Length field is
	incorrect, BFR MUST send Echo Reply with Return Code set to		incorrect, BFR MUST send Echo Reply with Return Code set to
	"Malformed Echo Request received" if the OAM Message Length is		"Malformed Echo Request received" if the OAM Message Length is
	incorrect. If the packet sanity check is fine, it SHOULD initiate		incorrect. If the packet sanity check is fine, it SHOULD initiate
	the below set of variables:		the below set of variables:
	Reply-Flag		Reply-Flag
	This flag is initially set to 1.		This flag is initially set to 1.
	Interface-I		Interface-I
	The incoming interface on which the Echo Request was received.		The incoming interface on which the Echo Request was received.
	This MAY be used to validate the Downstream Detailed Mapping TLV		This MAY be used to validate the Downstream Detailed Mapping TLV
	(DDMAP) info and to populate the Upstream Interface TLV.		(DDMAP) info and populate the Upstream Interface TLV.
	BIER-Label-L		BIER-Label-L
	The BIER-MPLS Label received as the top label of the received Echo		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		Request. This MAY be used to validate if the packet is traversing
	the desired Set Identifier and sub-domain path.		the desired Set Identifier and sub-domain path.
	Header-H		Header-H
	The BIER header of the received Echo Request. It can be used to		The BIER header of the received Echo Request. It can be used to
	validate the DDMAP info and to populate the Incoming SI-BitString		validate the DDMAP info and to populate the Incoming SI-BitString
	TLV. Also, it can be used to perform Entropy calculation		TLV. Also, it can be used to perform entropy calculation
	considering a different field in the header and reply via		considering a different field in the header and replying with
	Multipath Entropy Data Sub-TLV.		Multipath Entropy Data Sub-TLV.
	BFR MUST initialize the Best-return-code variable to the null value.		BFR MUST initialize the Best-return-code variable to the null value.
	BFR will populate the Interface-I with the identifier of the		BFR will populate the Interface-I with the identifier of the
	interface over which the Echo Request is received, the top label in		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		the MPLS stack of the received Echo Request to BIER-Label-L, and the
	BIER header to BIER-Header. If the received Echo Request carries		BIER header to BIER-Header. If the received Echo Request carries
	Target SI-BitString TLV, a BFR SHOULD run boolean AND operation		Target SI-BitString TLV, a BFR SHOULD run the boolean AND operation
	between BitString in Header-H and BitString in Target SI-BitString		between BitString in Header-H and BitString in Target SI-BitString
	TLV. If the resulting BitString is all-zero, reset Reply-Flag=0 and		TLV. If the resulting BitString is all-zero, reset Reply-Flag=0 and
	go to section 4.5. Else:		go to Section 4.5. Else:
	* If the BIER-Label-L does not correspond to the local label		* If the BIER-Label-L does not correspond to the local label
	assigned for {sub-domain, BitStringLen, SI} in Original SI-		assigned for {sub-domain, BitStringLen, SI} in Original SI-
	BitString TLV, Set the Best-return-code to "Set-Identifier		BitString TLV, Set the Best-return-code to "Set-Identifier
	Mismatch" and Go to section 4.5.		Mismatch" and Go to Section 4.5.
	* /* This step allows the detection of a synchronization problem in		This step allows the detection of a synchronization problem in the
	the upstream BFR between BIER-Label and {sub-domain, BitStringLen,		upstream BFR between BIER-Label and {sub-domain, BitStringLen, SI}
	SI} that might cause an unintended packet leak between sub-domains.		that might cause an unintended packet leak between sub-domains.
	*/
	* Set the Best-return-code to "One or more of the TLVsis not		* Set the Best-return-code to "One or more of the TLVsis not
	supported" if any of the TLVs in the Echo Request message is not		supported" if any of the TLVs in the Echo Request message is not
	supported. Go to section 4.5.		supported. Go to Section 4.5.
	* If the BitString in Header-H does not match the BitString in		* 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		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		"DDMAP Mismatch" and go to Section 4.5. When there are more than
	one DDMAP TLV in the received Request packet, the Downstream		one DDMAP TLV in the received Request packet, the Downstream
	Address and Downstream Interface Address should be matched with		Address and Downstream Interface Address should be matched with
	Interface-I to identify the right DDMAP TLV and then perform the		Interface-I to identify the right DDMAP TLV and then perform the
	BitString match.		BitString match.
	* /* This step allows the detection of a deviation between the BIER		This step allows the detection of a deviation between the BIER
	control plane and the BIER forwarding plane in the upstream node that		control plane and the BIER forwarding plane in the upstream node that
	may result in a forwarding loop or packet duplication. */		may result in a forwarding loop or packet duplication.
	* Set the Best-return-code to "Invalid Multipath Info Request", when		* Set the Best-return-code to "Invalid Multipath Info Request", when
	the DDMAP TLV carries Multipath Entropy Data Sub-TLV, and if the		the DDMAP TLV carries Multipath Entropy Data Sub-TLV, and if the
	Target SI-BitString TLV in the received Echo Request carries more		Target SI-BitString TLV in the received Echo Request carries more
	than 1 BFER id. Go to section 4.5. Else, list the ECMP		than 1 BFER id. Go to Section 4.5. Else, list the ECMP
	downstream neighbors to reach BFR-id in Target SI-BitString TLV,		downstream neighbors to reach BFR-id in Target SI-BitString TLV,
	calculate the Entropy considering the BitString in Header-H and		calculate the Entropy considering the BitString in Header-H and
	Multipath Entropy Data Sub-TLV from received Echo Request. Store		Multipath Entropy Data Sub-TLV from received Echo Request. Store
	the Data for each Downstream interface in a temporary variable.		the Data for each Downstream interface in a temporary variable.
	Set the Best-return-code to 5 (Packet-Forward-Success) and goto		Set the Best-return-code to 5 (Packet-Forward-Success) and goto
	Section 4.5		Section 4.5
	* /* This step instructs the node to calculate the Entropy Data for		This step instructs the node to calculate the Entropy Data for each
	each downstream interface to reach the BFER in Target SI-BitString		downstream interface to reach the BFER in Target SI-BitString TLV by
	TLV by considering the incoming BitString and Entropy Data.*/		considering the incoming BitString and Entropy Data.
	* Set the Best-return-code to "Replying router is the only BFER in		* 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		BIER header BitString", and go to Section 4.5 if the responder is
	BFER and there are no more bits in BIER header Bitstring left for		BFER and there are no more bits in the BIER header BitString left
	forwarding.		for forwarding.
	* Set the Best-return-code to "Replying router is one of the BFER in		* Set the Best-return-code to "Replying router is one of the BFERs
	BIER header Bitstring", and include Downstream Mapping TLV, if the		in BIER header BitString", and include Downstream Mapping TLV if
	responder is BFER and there are more bits in BitString left for		the responder is BFER and there are more bits in BitString left
	forwarding. Also, include the Multipath information as defined in		for forwarding. Also, include the Multipath information as
	Section 4.2 if the received Echo Request carries Multipath Entropy		defined in Section 4.2 if the received Echo Request carries
	Data Sub-TLV. Go to section 4.5.		Multipath Entropy Data Sub-TLV. Go to Section 4.5.
	* Set the Best-return-code to "No matching entry in the forwarding		* Set the Best-return-code to "No matching entry in the forwarding
	table", if the forwarding lookup defined in section 6.5 of		table", if the forwarding lookup, defined in Section 6.5 of
	[RFC8279] does not match any entry for the received BitString in		[RFC8279] does not match any entry for the received BitString in
	BIER header.		BIER header.
	* /* This step allows the detection of the missing BFR-id in the		This step allows the detection of the missing BFR-id in the node's
	node's BIER forwarding table. It is difficult to detect the absence		BIER forwarding table. It is difficult to detect the absence of the
	of the BFR-id if the Request includes more than one BFR-ids in the		BFR-id if the Request includes more than one BFR-ids in the BitString
	BitString and so may need to include the BFER-id that is not		and so may need to include the BFER-id that is not responding to
	responding to detect such failure. */		detect such failure.
	* Set the Best-return-code to "Packet-Forward-Success", and include		* Set the Best-return-code to "Packet-Forward-Success", and include
	Downstream Mapping TLV. Go to section 4.5		Downstream Mapping TLV. Go to Section 4.5.
	4.5. Sending Echo Reply		4.5. Sending Echo Reply
	If Reply-Flag=0, BFR MUST release the variables and MUST not send any		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:		response to the Initiator. If Reply-Flag=1, proceed as below:
	The Responder BFR SHOULD include the BitString from Header-H to		The Responder BFR SHOULD include the BitString from Header-H to
	Incoming SI-BitString TLV and include the Set ID, Sub-domain ID and		Incoming SI-BitString TLV and include the Set ID, Sub-domain ID and
	BS Len that corresponds to BIER-Label-L. Responder BFR SHOULD		BS Len that corresponds to BIER-Label-L. Responder BFR SHOULD
	include the Upstream Interface TLV and populate the address from		include the Upstream Interface TLV and populate the address from
	Interface-I.		Interface-I.
	When the Best-return-code is "Replying BFR is one of the BFER in		When the Best-return-code is "Replying BFR is one of the BFERs in
	header Bitstring", it MUST include Responder BFER TLV.		header BitString", it MUST include Responder BFER TLV.
	If the received Echo Request had DDMAP with Multipath Entropy Data		If the received Echo Request had DDMAP with Multipath Entropy Data
	Sub-TLV, Responder BFR MUST include DDMAP as defined in		Sub-TLV, Responder BFR MUST include DDMAP as defined in
	Section 3.3.4 for each outgoing interface over which the packet		Section 3.3.4 for each outgoing interface over which the packet
	will be replicated and include the respective Multipath Entropy		will be replicated and include the respective Multipath Entropy
	Data Sub-TLV. For each outgoing interface, respective Egress		Data Sub-TLV. For each outgoing interface, the respective Egress
	BitString MUST be included in DDMAP TLV.		BitString MUST be included in DDMAP TLV.
	If the received Echo Request had DDMAP without Multipath Entropy		If the received Echo Request had DDMAP without Multipath Entropy
	Data Sub-TLV, Responder BFR MUST include DDMAP as defined in		Data Sub-TLV, Responder BFR MUST include DDMAP as defined in
	Section 3.3.4 for each outgoing interface over which the packet		Section 3.3.4 for each outgoing interface over which the packet
	will be replicated. For each outgoing interface, respective		will be replicated. For each outgoing interface, respective
	Egress BitString MUST be included in DDMAP TLV.		Egress BitString MUST be included in DDMAP TLV.
	When the Best-return-code is "Replying BFR is the only BFER in header		When the Best-return-code is "Replying BFR is the only BFER in header
	Bitstring", it MUST include Responder BFER TLV.		BitString", it MUST include Responder BFER TLV.
	The Responder MUST set the Message Type as 2 and Return Code as Best-		The Responder MUST set the Message Type as 2 and Return Code as Best-
	return-code. The Proto field MUST be set to 0.		return-code. The Proto field MUST be set to 0.
	The Echo Reply can be sent either as BIER-encapsulated or IP/UDP		The Echo Reply can be sent as BIER-encapsulated, or IP/UDP
	encapsulated depending on the Reply mode in received Echo Request.		encapsulated, depending on the Reply Mode in the received Echo
	When the Reply mode in received Echo Request is set to 3, Responder		Request. When the Reply Mode in the received Echo Request is set to
	appends BIER header listing the BitString with BFIR ID (from Header-		3, Responder appends the BIER header listing the BitString with BFIR
	H), set the Proto to 5 and set the BFIR as 0. When the Reply mode in		ID (from Header- H), sets the Proto to 5, and sets the BFIR as 0.
	received Echo Request is set to 2, Responder encapsulates with IP/UDP		When the Reply Mode in the received Echo Request is set to 2,
	header. The UDP destination port MUST be set to TBD1, and the source		Responder encapsulates with the IP/UDP header. The UDP destination
	port MAY be set to TBD1 or other random local value. The source IP		port MUST be set to TBD1 (Section 5.1), and the source port MAY be
	is any local address of the responder and destination IP is derived		set to TBD1 or other value selected from the Dynamic range of port
	from Reply-To TLV.		numbers. The source IP is any local address of the responder, and
			the destination IP is derived from the BFIR-id of the BIER header
			[RFC8296] of the received Echo Request.
	4.6. Receiving Echo Reply		4.6. Receiving Echo Reply
	The Initiator upon receiving the Echo Reply will use the Sender's		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		Handle to match with Echo Request sent. If no match is found, the
	Initiator MUST ignore the Echo Reply.		Initiator MUST ignore the Echo Reply.
	If receiving Echo Reply have Downstream Mapping, the Initiator SHOULD		If receiving Echo Reply has Downstream Mapping, the Initiator SHOULD
	copy the same to subsequent Echo Request(s).		copy the same to subsequent Echo Request(s).
	If one of the Echo Reply is received with Return Code as "Replying		If one of the Echo Reply is received with Return Code as "Replying
	BFR is one of the BFER in header Bitstring", it SHOULD reset the BFR-		BFR is one of the BFERs in header BitString", it SHOULD reset the
	id of the responder from Target SI-BisString TLV in subsequent Echo		BFR- id of the responder from Target SI-BisString TLV in subsequent
	Request.		Echo Request. This step helps avoid any BFR that is both BFER and
			transit BFR to respond with Echo Reply continuously.
	/* This step helps avoid any BFR that is both BFER and transit BFR to
	respond with Echo Reply continuously. */
	5. IANA Considerations		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		This document requests a UDP port TBD1 to be allocated by IANA for
	BIER Echo.		BIER Echo.
	This document requests the IANA to create and manage the below		5.2. BIER OAM Parameters
	registries and sub-registries:
	5.1. BIER OAM Registry		IANA is requested to create and maintain the "BIER OAM Parameters"
			registry containing the sub-registries listed below.
	IANA is requested to create and maintain "BIER OAM Parameters"		5.3. BIER OAM Message Type
	registry.
	5.2. Message Types, Reply Modes, Return Codes		IANA is requested to create in the BIER OAM Parameters registry a
			sub-registry as follows:
	IANA is requested to create a "Message Type" sub-registry under "BIER		Sub-registry Name: BIER OAM Message Type.
	OAM Parameters" registry and assign the Message Types defined in
	section 3.1
	IANA is requested to create a "Echo Reply Mode" sub-registry under		Assignment Policy:
	"BIER OAM Parameters" registry and assign the Echo Reply Modes
	defined in section 3.1
	IANA is requested to create a "Echo Return Codes" sub-registry under		2-31 IETF Review
	"BIER OAM Parameters" registry and assign the Return Codes defined in
	section 3.2
	5.3. TLVs		32-62 First Come, First Served
	The TLVs and Sub-TLVs defined in this document is not limited to Echo		Reference: [this document]
	Request or Reply message types and is applicable for other message
	types. The TLVs and Sub-TLVs requested by this document for IANA		+========+==============================+===============+
			| Value | Description | Reference |
			+========+==============================+===============+
			| 0 | Reserved | This document |
			+--------+------------------------------+---------------+
			| 1 | BIER Echo Request/Echo Reply | This document |
			+--------+------------------------------+---------------+
			| 2 - 31 | Unassigned | This document |
			+--------+------------------------------+---------------+
			| 32-62 | Unassigned | This document |
			+--------+------------------------------+---------------+
			| 63 | Reserved | This document |
			+--------+------------------------------+---------------+
			Table 1: BIER OAM Message Type
			5.4. BIER Echo Request/Echo Reply Parameters
			IANA is requested to create in the BIER OAM registry the sub-registry
			BIER Echo Request/Echo Reply Parameters.
			5.4.1. BIER Echo Request/Echo Reply Message Types
			IANA is requested to create in the BIER Echo Request/Echo Reply
			Parameters the BIER Echo Request/Echo Reply Message Types sub-
			registry as follows:
			Sub-registry Name: BIER Echo Request/Echo Reply Message Types
			Assignment Policy:
			3 - 175 IETF Review
			176 - 239 First Come, First Served
			Reference: [this document]
			+===========+===================+===============+
			| 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 - 239 | Unassigned | This document |
			+-----------+-------------------+---------------+
			| 240 - 251 | Experimental | This document |
			+-----------+-------------------+---------------+
			| 252 - 254 | Private Use | This document |
			+-----------+-------------------+---------------+
			| 255 | Reserved | This document |
			+-----------+-------------------+---------------+
			Table 2: BIER Echo Request/Echo Reply Message
			Types
			5.4.2. BIER Echo Reply Modes
			IANA is requested to create in the BIER Echo Request/Echo Reply
			Parameters registry the new sub-registry as follows:
			Sub-registry Name: BIER Echo Reply Mode
			Assignment Policy:
			8 - 175 IETF Review
			176 - 239 First Come, First Served
			Reference: [this document]
			+===========+===================================+===============+
			| 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 - 239 | Unassigned | This document |
			+-----------+-----------------------------------+---------------+
			| 240 - 251 | Experiemntal | This document |
			+-----------+-----------------------------------+---------------+
			| 252 - 254 | Private Use | This document |
			+-----------+-----------------------------------+---------------+
			| 255 | Reserved | This document |
			+-----------+-----------------------------------+---------------+
			Table 3: SFC Echo Reply Modes
			5.4.3. BIER Echo Return Codes
			IANA is requested to create in the BIER Echo Request/Echo Reply
			Parameters registry the new sub-registry as follows:
			Sub-registry Name: BIER Echo Return Codes
			Assignment Policy:
			9 - 191 IETF Review
			192 - 251 First Come, First Served
			Reference: [this document]
			+=========+=================================+===============+
			| 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 |
			| 191 | | |
			+---------+---------------------------------+---------------+
			| 192-251 | Unassigned | This document |
			+---------+---------------------------------+---------------+
			| 252-254 | Private Use | This document |
			+---------+---------------------------------+---------------+
			| 255 | Reserved | This document |
			+---------+---------------------------------+---------------+
			Table 4: BIER Echo Return Codes
			5.5. TLVs
			IANA is requested to create in the BIER OAM registry a sub-registry
			for the Type field of top-level TLVs as well as for any 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.
			The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the
			ranges 0-16383 and 32768-49161 are made via Standards Action as
			defined in [RFC8126]; assignments in the ranges 16384-31743 and
			49162-64511 are made via "Specification Required"; values in the
			ranges 31744-32767 and 64512-65535 are for Private Use and MUST NOT
			be allocated.
			If a TLV or sub-TLV has a Type that falls in the range of Private
			Use, the Length MUST be at least 4, and the first four octets MUST be
			an SMI Private Enterprise Number that identifies the user, in network
			octet order. The rest of the Value field is private to the user.
			The TLVs and Sub-TLVs defined in this document are not limited to
			Echo Request or Reply message types are applicable to other message
			types. The TLVs and Sub-TLVs requested by this document for the IANA
	consideration are the following:		consideration are the following:
	Type Sub-Type Value Field		Type Sub-Type Value Field
	------- -------- -----------		------- -------- -----------
	1 Original SI-BitString		1 Original SI-BitString
	2 Target SI-BitString		2 Target SI-BitString
	3 Incoming SI-BitString		3 Incoming SI-BitString
	4 Downstream Mapping		4 Downstream Mapping
	4 1 Multipath Entropy Data		4 1 Multipath Entropy Data
	4 2 Egress BitString		4 2 Egress BitString
	5 Responder BFER		5 Responder BFER
	6 Responder BFR		6 Responder BFR
	7 Upstream Interface		7 Upstream Interface
	6. Security Considerations		6. Security Considerations
	The security consideration for BIER Ping is similar to ICMP [RFC0792]		The security consideration for BIER Ping is similar to ICMP [RFC0792]
	or LSP Ping [RFC8029], [RFC6425]. As with ICMP or LSP Ping, BFR can		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		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		to regulate the BIER Ping packet flow to the control plane. A rate
	limiter SHOULD be applied to avoid any attack.		limiter SHOULD be applied to avoid any attack. 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		As with ICMP or LSP Ping, a traceroute can be used to obtain network
	information. It is RECOMMENDED that the implementation checks the		information. It is RECOMMENDED that the implementation checks the
	integrity of BFIR of the Echo messages against any local secured list		integrity of BFIR of the Echo messages against any locally secured
	before processing the message further		list before processing the message further.
	7. Acknowledgement		7. Acknowledgement
	The authors would like to thank Antoni Przygienda, Eric Rosen, Faisal		The authors would like to thank Antoni Przygienda, Eric Rosen, Faisal
	Iqbal, Jeffrey (Zhaohui) Zhang,DIA Length - Downstream Interface		Iqbal, Jeffrey (Zhaohui) Zhang, and Shell Nakash for their review and
	Address field Length and Shell Nakash for their review and comments.		comments.
	The authors would like to thank Mankamana Mishra for his thorough		The authors would like to thank Mankamana Mishra for his thorough
	review and comments.		review and comments.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	skipping to change at page 24, line 23 ¶		skipping to change at page 29, line 11 ¶
	for Bit Index Explicit Replication (BIER) in MPLS and Non-		for Bit Index Explicit Replication (BIER) in MPLS and Non-
	MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January		MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
	2018, <https://www.rfc-editor.org/info/rfc8296>.		2018, <https://www.rfc-editor.org/info/rfc8296>.
	[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,		[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
	Yasukawa, S., and T. Nadeau, "Detecting Data-Plane		Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
	Failures in Point-to-Multipoint MPLS - Extensions to LSP		Failures in Point-to-Multipoint MPLS - Extensions to LSP
	Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,		Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,
	<https://www.rfc-editor.org/info/rfc6425>.		<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>.
			[IEEE.1588.2008]
			"Standard for a Precision Clock Synchronization Protocol
			for Networked Measurement and Control Systems",
			IEEE Standard 1588, March 2008.
	8.2. Informative References		8.2. Informative References
	[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,		[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
	RFC 792, DOI 10.17487/RFC0792, September 1981,		RFC 792, DOI 10.17487/RFC0792, September 1981,
	<https://www.rfc-editor.org/info/rfc792>.		<https://www.rfc-editor.org/info/rfc792>.
			[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
			Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
			May 2016, <https://www.rfc-editor.org/info/rfc7799>.
			[I-D.ietf-mpls-lspping-norao]
			Kompella, K., Bonica, R., and G. Mirsky, "Deprecating the
			Use of Router Alert in LSP Ping", Work in Progress,
			Internet-Draft, draft-ietf-mpls-lspping-norao-01, 11 March
			2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
			mpls-lspping-norao-01>.
	Authors' Addresses		Authors' Addresses
	Nagendra Kumar		Nagendra Kumar
	Cisco Systems, Inc.		Cisco Systems, Inc.
	7200 Kit Creek Road		7200 Kit Creek Road
	Research Triangle Park, NC 27709		Research Triangle Park, NC 27709
	US		US
	Email: naikumar@cisco.com		Email: naikumar@cisco.com
	Carlos Pignataro		Carlos Pignataro
End of changes. 163 change blocks.
	344 lines changed or deleted		611 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/