draft-gandhi-ippm-stamp-ber-00.txt		draft-gandhi-ippm-stamp-ber-01.txt
	IPPM Working Group R. Gandhi, Ed.		IPPM Working Group R. Gandhi, Ed.
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems, Inc.
	Intended status: Standards Track P. Schoenmaker		Intended status: Standards Track P. Schoenmaker
	Expires: 18 October 2025 Meta Platforms, Inc.		Expires: 28 November 2025 Meta Platforms, Inc.
	16 April 2025		27 May 2025
	Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Bit		Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Bit
	Error Detection and Bit Error Rate Measurement		Error Detection and Bit Error Rate Measurement
	draft-gandhi-ippm-stamp-ber-00		draft-gandhi-ippm-stamp-ber-01
	Abstract		Abstract
	The Simple Two-Way Active Measurement Protocol (STAMP), as defined in		The Simple Two-Way Active Measurement Protocol (STAMP), as defined in
	RFC 8762, along with its optional extensions specified in RFC 8972,		RFC 8762, along with its optional extensions specified in RFC 8972,
	can be utilized for active measurement. This document further		can be utilized for active measurement. This document further
	augments the STAMP extensions specified in RFC 8972 to enable the		augments the STAMP extensions specified in RFC 8972 to enable the
	detection of bit errors and the measurement of the bit error rate		detection of bit errors and the measurement of the bit error rate
	(BER) within the "Extra Padding Data" of STAMP packets.		(BER) within the "Extra Padding Data" of STAMP packets.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 18 October 2025.		This Internet-Draft will expire on 28 November 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2025 IETF Trust and the persons identified as the		Copyright (c) 2025 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 24 ¶		skipping to change at page 2, line 24 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions Used in This Document . . . . . . . . . . . . . . 3		2. Conventions Used in This Document . . . . . . . . . . . . . . 3
	2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3		2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
	2.3. STAMP Reference Topology . . . . . . . . . . . . . . . . 4		2.3. STAMP Reference Topology . . . . . . . . . . . . . . . . 4
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. STAMP Procedure . . . . . . . . . . . . . . . . . . . . . . . 5		4. STAMP Procedure . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. STAMP Session-Sender . . . . . . . . . . . . . . . . . . 6		4.1. STAMP Session-Sender . . . . . . . . . . . . . . . . . . 6
	4.2. STAMP Session-Reflector . . . . . . . . . . . . . . . . . 6		4.2. STAMP Session-Reflector . . . . . . . . . . . . . . . . . 7
	4.3. Considerations for Link Aggregation Group . . . . . . . . 7		4.3. Considerations for Link Aggregation Group . . . . . . . . 8
	5. STAMP Extensions . . . . . . . . . . . . . . . . . . . . . . 7		5. STAMP Extensions . . . . . . . . . . . . . . . . . . . . . . 8
	5.1. Bit Pattern in Padding Data STAMP TLV . . . . . . . . . . 7		5.1. Bit Pattern in Padding Data STAMP TLV . . . . . . . . . . 8
	5.2. Bit Error Count in Padding Data STAMP TLV . . . . . . . . 8		5.2. Bit Error Count in Padding Data STAMP TLV . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. Data Model Parameters . . . . . . . . . . . . . . . . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . 9		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.2. Informative References . . . . . . . . . . . . . . . . . 9		9.1. Normative References . . . . . . . . . . . . . . . . . . 10
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	The Simple Two-Way Active Measurement Protocol (STAMP) is designed to		The Simple Two-Way Active Measurement Protocol (STAMP) is designed to
	measure various performance metrics in IP networks without relying on		measure various performance metrics in IP networks without relying on
	a control channel to pre-signal session parameters, as specified in		a control channel to pre-signal session parameters, as specified in
	[RFC8762]. STAMP test packets are sent between a Session-Sender and		[RFC8762]. STAMP test packets are sent between a Session-Sender and
	a Session-Reflector to measure delay and packet loss along the path.		a Session-Reflector to measure delay and packet loss along the path.
	[RFC8972] introduces optional extensions for STAMP in the form of		[RFC8972] introduces optional extensions for STAMP in the form of
	skipping to change at page 4, line 45 ¶		skipping to change at page 4, line 45 ¶
	STAMP TLVs from the Session-Sender test packets. [RFC8972] defines		STAMP TLVs from the Session-Sender test packets. [RFC8972] defines
	an optional TLV extension specifically for transmitting "Extra		an optional TLV extension specifically for transmitting "Extra
	Padding Data" (Type=1) in the STAMP test packets. The "Extra Padding		Padding Data" (Type=1) in the STAMP test packets. The "Extra Padding
	Data" can be filled using either a predefined fixed pattern or a		Data" can be filled using either a predefined fixed pattern or a
	random pattern of bits [RFC8972].		random pattern of bits [RFC8972].
	This document defines a procedure to detect bit errors within the		This document defines a procedure to detect bit errors within the
	"Extra Padding Data" TLV. The process involves the Session-Sender		"Extra Padding Data" TLV. The process involves the Session-Sender
	transmitting the extra padding data filled with a predefined bit		transmitting the extra padding data filled with a predefined bit
	pattern. The Session-Reflector then checks for bit errors by		pattern. The Session-Reflector then checks for bit errors by
	comparing the received data against the predefined bit pattern. This		comparing the received padding data against the predefined bit
	allows for the detection of a single bit error or a burst of bit		pattern. This allows for the detection of a single bit error or a
	errors and the accurate measurement of the bit error rate. The		burst of bit errors and the measurement of the bit error rate. The
	Session-Reflector does not discard the STAMP test packet with bit		Session-Reflector does not discard the STAMP test packet with bit
	errors but instead reflects it back to the Session-Sender after		errors but instead reflects it back to the Session-Sender after
	correcting the errors. The Session-Reflector also returns the bit		correcting the bit errors. The Session-Reflector also returns the
	error count to the Session-Sender.		bit error count to the Session-Sender.
	Bit errors can be detected in both the forward and reverse directions		Bit errors are detected in both the forward and reverse directions
	between the Session-Sender and the Session-Reflector using the		between the Session-Sender and the Session-Reflector using the
	procedure and extensions defined in this document. The bit error		procedure and extensions defined in this document. The bit error
	rate is computed as the ratio of the number of bit errors detected to		rate is computed as the ratio of the number of bit errors detected to
	the number of bits transmitted in the extra padding data.		the number of bits received in the extra padding data.
	As specified in [RFC8972], the Session-Sender and Session-Reflector		As specified in [RFC8972], the Session-Sender and Session-Reflector
	test packets are symmetric in size. The Session-Sender and Session-		test packets are symmetric in size. The Session-Sender and Session-
	Reflector MUST ensure that the resulting test packets do not exceed		Reflector MUST ensure that the resulting test packets do not exceed
	the path MTU after adding the STAMP TLVs.		the path MTU after adding the STAMP TLVs.
	Note that the procedure and extensions defined in this document does		Note that the procedure and extensions defined in this document do
	not detect bit errors in the base STAMP packets, packet headers, and		not detect bit errors in the base STAMP packets, packet headers, or
	STAMP TLVs other than the "Extra Padding Data" TLV.		STAMP TLVs other than the "Extra Padding Data" TLV. It is possible
			that bit errors impact those non-measurement fields of the STAMP test
			packets. Bit errors in those fields result in the failure of
			validity checks. The corrupted STAMP test packets are discarded,
			reported using a different measurement metric, and not included in
			the bit error rate measurement.
			The integrity of those fields can be verified using the HMAC
			mechanisms defined in [RFC8762] and [RFC8972] (which exclude the
			"Extra Padding Data" TLV).
			The size of the non-measurement fields in the received STAMP test
			packet is excluded from the bit error rate measurement.
	4. STAMP Procedure		4. STAMP Procedure
	This document defines two TLV options for STAMP: "Bit Pattern in		This document defines two TLV options for STAMP: "Bit Pattern in
	Padding Data" STAMP TLV (Type=TBA1) and "Bit Error Count in Padding		Padding Data" STAMP TLV (Type=TBA1) and "Bit Error Count in Padding
	Data" STAMP TLV (Type=TBA2). An example of STAMP test packet used		Data" STAMP TLV (Type=TBA2). An example of STAMP test packet used
	for detecting bit errors is shown in Figure 2 using "Extra Padding		for detecting bit errors is shown in Figure 2 using "Extra Padding
	Data" TLV, "Bit Pattern in Padding Data" STAMP TLV, and "Bit Error		Data" TLV, "Bit Pattern in Padding Data" STAMP TLV, and "Bit Error
	Count in Padding Data" STAMP TLV.		Count in Padding Data" STAMP TLV.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| STAMP Packet RFC 8972 |		| STAMP Packet RFC 8972 |
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|STAMP TLV Flags| Type=1 | Length |		|STAMP TLV Flags| Type=1 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Extra Padding ~		~ Extra Padding ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|STAMP TLV Flags| Type=TBA1 | Length |		|STAMP TLV Flags| Type=TBA1 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Bit Pattern in Padding Data ~		~ Bit Pattern in Padding Data ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|STAMP TLV Flags| Type=TBA2 | Length=4 |		|STAMP TLV Flags| Type=TBA2 | Length=4 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Bit Error Count in Padding Data |		| Bit Error Count in Padding Data |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Example STAMP Packet to Detect Bit Errors		Figure 2: Example STAMP Packet to Detect Bit Errors
	4.1. STAMP Session-Sender		4.1. STAMP Session-Sender
	When a STAMP Session-Sender is set up to detect bit errors and		When a STAMP Session-Sender is set up to detect bit errors and
	measure bit error rate, it adds the STAMP TLVs for "Extra Padding		measure bit error rate, it adds the STAMP TLVs for "Extra Padding
	skipping to change at page 6, line 26 ¶		skipping to change at page 7, line 5 ¶
	"Bit Pattern in Padding Data" STAMP TLV MUST contain the bit pattern		"Bit Pattern in Padding Data" STAMP TLV MUST contain the bit pattern
	employed in the "Extra Padding Data" STAMP TLV. It is RECOMMENDED to		employed in the "Extra Padding Data" STAMP TLV. It is RECOMMENDED to
	have the length of the extra padding data as an integer multiple of		have the length of the extra padding data as an integer multiple of
	the length of the Bit Pattern to ease implementation.		the length of the Bit Pattern to ease implementation.
	The Session-Sender MUST also add the "Extra Padding Data" STAMP TLV		The Session-Sender MUST also add the "Extra Padding Data" STAMP TLV
	[RFC8972] when it adds the "Bit Error Count in Padding Data" STAMP		[RFC8972] when it adds the "Bit Error Count in Padding Data" STAMP
	TLV in the Session-Sender test packets. The data in the Bit Error		TLV in the Session-Sender test packets. The data in the Bit Error
	Count STAMP TLV MUST be set to 0.		Count STAMP TLV MUST be set to 0.
	The bit pattern employed in the extra padding data can be locally		It is possible that the bit pattern in the "Bit Pattern in Padding
	configured on the Session-Reflector. In that case, the "Bit Pattern		Data" STAMP TLV itself may contain bit errors. This can result in a
	in Padding Data" STAMP TLV need not be transmitted in the STAMP test		measurement error due to a mismatch between the bit pattern and the
	packets. However, the "Bit Error Count in Padding Data" STAMP TLV		extra padding data. One way to avoid this issue is for the Session-
	MUST be transmitted to reflect the detected bit error counts.		Reflector to use the local configuration or the default value of
			0xFF00 as the bit pattern. In this case, the "Bit Pattern in Padding
			Data" STAMP TLV need not be transmitted in the STAMP test packets.
			However, the "Bit Error Count in Padding Data" STAMP TLV MUST be
			transmitted to reflect the detected bit error counts.
			Note that the integrity of the "Bit Pattern in Padding Data" and "Bit
			Error Count in Padding Data" STAMP TLVs can be protected using the
			HMAC mechanisms defined in [RFC8972]. In this case, the computation
			of the bit error rate is only performed after verifying the integrity
			of these TLVs.
	4.2. STAMP Session-Reflector		4.2. STAMP Session-Reflector
	When the Session-Reflector receives a STAMP test packet with a "Bit		When the Session-Reflector receives a STAMP test packet with a "Bit
	Pattern in Padding Data" STAMP TLV, the Session-Reflector that		Pattern in Padding Data" STAMP TLV, the Session-Reflector that
	supports this TLV MUST check the extra padding data against the bit		supports this TLV MUST check the extra padding data against the bit
	pattern to detect any bits that do not match the bit pattern and		pattern to detect any bits that do not match the bit pattern and
	count them as bit errors.		count them as bit errors.
	When the Session-Reflector receives a STAMP test packet with a "Bit		When the Session-Reflector receives a STAMP test packet with a "Bit
	Error Count in Padding Data" STAMP TLV, the Session-Reflector that		Error Count in Padding Data" STAMP TLV, the Session-Reflector that
	supports this STAMP TLV MUST check the "Extra Padding Data" against		supports this STAMP TLV MUST check the "Extra Padding Data" against
	the expected bit pattern, either in the received test packet or the		the expected bit pattern to detect if there are any bits not matching
	local configuration, to detect if there are any bits not matching the		the bit pattern and count them as bit errors. The Session-Reflector
	bit pattern and count them as bit errors. The Session-Reflector
	updates the count of bit errors in the received "Bit Error Count in		updates the count of bit errors in the received "Bit Error Count in
	Padding Data" TLV and reflects the TLV back to the Session-Sender.		Padding Data" TLV and reflects the TLV back to the Session-Sender.
	If no bit errors are detected, the bit error count remains as 0 in		If no bit errors are detected, the bit error count is set to 0 in the
	the reflected "Bit Error Count in Padding Data" TLV.		reflected "Bit Error Count in Padding Data" TLV.
	The Session-Reflector corrects the bit errors in the "Extra Padding		The Session-Reflector corrects the bit errors in the "Extra Padding
	Data" STAMP TLV by matching the bit pattern and reflects the		Data" STAMP TLV by matching the bit pattern and reflects the
	corrected "Extra Padding Data" TLV to the Session-Sender. The		corrected "Extra Padding Data" TLV to the Session-Sender. The
	corrected "Extra Padding Data" is used to detect bit errors in the		corrected "Extra Padding Data" is used to detect bit errors in the
	reverse direction.		reverse direction.
	If the Session-Reflector receives a STAMP test packet with a "Bit		If the Session-Reflector receives a STAMP test packet with a "Bit
	Pattern in Padding Data" TLV or a "Bit Error Count in Padding Data"		Pattern in Padding Data" TLV or a "Bit Error Count in Padding Data"
	TLV without the "Extra Padding Data" TLV, it MUST set the U flag		TLV without the "Extra Padding Data" TLV, it MUST set the U flag
	(Unrecognized) in the STAMP TLV Flags in the reflected STAMP packet		(Unrecognized) in the STAMP TLV Flags in the reflected STAMP packet
	for those STAMP TLVs. Editor's Note: We could define a new TLV Flag		for those STAMP TLVs. Editor's Note: We could use the TLV Flag
	"Non-consistent message" for handling this condition.		"Conformance Check from draft-ietf-ippm-asymmetrical-pkts" for
			handling this condition.
	4.3. Considerations for Link Aggregation Group		4.3. Considerations for Link Aggregation Group
	Networks may experience transmission bit errors differently for		Networks may experience transmission bit errors differently for
	different link members in a Link Aggregation Group (LAG). The STAMP		different link members in a Link Aggregation Group (LAG). The STAMP
	extensions for LAG are defined in [RFC9534]. The procedure and		extensions for LAG are defined in [RFC9534]. The procedure and
	extensions defined in this document are equally applicable for		extensions defined in this document are equally applicable for
	detecting bit errors in each individual LAG member link by creating a		detecting bit errors in each individual LAG member link by creating a
	separate micro-session for each link, as defined in [RFC9534].		separate micro-session for each link, as defined in [RFC9534]. Note
			that in order to get a good approximation of the bit errors, it is
			desired to transmit the STAMP test packets that match the link MTU
			size.
	5. STAMP Extensions		5. STAMP Extensions
	5.1. Bit Pattern in Padding Data STAMP TLV		5.1. Bit Pattern in Padding Data STAMP TLV
	The "Bit Pattern in Padding Data" STAMP TLV is optional and is		The "Bit Pattern in Padding Data" STAMP TLV is optional and is
	carried by Session-Sender and Session-Reflector test packets. The		carried by Session-Sender and Session-Reflector test packets. The
	format of the TLV is shown in Figure 3.		format of the TLV is shown in Figure 3.
	0 1 2 3		0 1 2 3
	skipping to change at page 8, line 32 ¶		skipping to change at page 9, line 24 ¶
	The TLV fields are defined as follows:		The TLV fields are defined as follows:
	Type: Type (value TBA2)		Type: Type (value TBA2)
	STAMP TLV Flags: The STAMP TLV Flags follow the procedures described		STAMP TLV Flags: The STAMP TLV Flags follow the procedures described
	in [RFC8972].		in [RFC8972].
	Length: A two-octet field set to 4 for the Data.		Length: A two-octet field set to 4 for the Data.
	6. Security Considerations		6. Data Model Parameters
	The security considerations specified in [RFC8762], [RFC8972],		The configuration data model for bit error detection and bit error
	[RFC9534] apply to the procedure and extensions defined in this		rate measurement using STAMP MUST allow to set the following
	document.		parameters:
	7. IANA Considerations		- Padding data size
			- Padding bit pattern
			- Transmit interval for the STAMP test packets
			- Computation interval as a multiple of transmit interval for
			reporting bit error rate
			The operational data model for bit error detection and bit error rate
			measurement using STAMP MUST allow to telemetry the following
			parameters:
			- Number of total packets received in the computation interval
			- Number of total packets received with bit errors in the
			computation interval
			- Number of total bits in the padding TLV of all received packets
			in the computation interval
			- Number of total bit error count in the padding TLV of all
			received packets in the computation interval
			7. Security Considerations
			The security considerations specified in [RFC8762] and [RFC8972]
			apply to the procedure and extensions defined in this document.
			8. IANA Considerations
	IANA has created the "STAMP TLV Types" registry for [RFC8972]. IANA		IANA has created the "STAMP TLV Types" registry for [RFC8972]. IANA
	is requested to allocate a value for the "Bit Pattern in Padding		is requested to allocate a value for the "Bit Pattern in Padding
	Data" TLV Type and a value for the "Bit Error Count in Padding Data"		Data" TLV Type and a value for the "Bit Error Count in Padding Data"
	TLV Type from the IETF Review TLV range of the same registry.		TLV Type from the IETF Review TLV range of the same registry.
	+=======+=================================+===============+		+=======+=================================+===============+
	| Value | Description | Reference |		| Value | Description | Reference |
	+=======+=================================+===============+		+=======+=================================+===============+
	| TBA1 | Bit Pattern in Padding Data | This document |		| TBA1 | Bit Pattern in Padding Data | This document |
	+-------+---------------------------------+---------------+		+-------+---------------------------------+---------------+
	| TBA2 | Bit Error Count in Padding Data | This document |		| TBA2 | Bit Error Count in Padding Data | This document |
	+-------+---------------------------------+---------------+		+-------+---------------------------------+---------------+
	Table 1: STAMP TLV Types		Table 1: STAMP TLV Types
	8. References		9. References
	8.1. Normative References		9.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,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	skipping to change at page 9, line 39 ¶		skipping to change at page 10, line 51 ¶
	Two-Way Active Measurement Protocol", RFC 8762,		Two-Way Active Measurement Protocol", RFC 8762,
	DOI 10.17487/RFC8762, March 2020,		DOI 10.17487/RFC8762, March 2020,
	<https://www.rfc-editor.org/info/rfc8762>.		<https://www.rfc-editor.org/info/rfc8762>.
	[RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A.,		[RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A.,
	and E. Ruffini, "Simple Two-Way Active Measurement		and E. Ruffini, "Simple Two-Way Active Measurement
	Protocol Optional Extensions", RFC 8972,		Protocol Optional Extensions", RFC 8972,
	DOI 10.17487/RFC8972, January 2021,		DOI 10.17487/RFC8972, January 2021,
	<https://www.rfc-editor.org/info/rfc8972>.		<https://www.rfc-editor.org/info/rfc8972>.
	8.2. Informative References		9.2. Informative References
	[RFC9534] Li, Z., Zhou, T., Guo, J., Mirsky, G., and R. Gandhi,		[RFC9534] Li, Z., Zhou, T., Guo, J., Mirsky, G., and R. Gandhi,
	"Simple Two-Way Active Measurement Protocol Extensions for		"Simple Two-Way Active Measurement Protocol Extensions for
	Performance Measurement on a Link Aggregation Group",		Performance Measurement on a Link Aggregation Group",
	RFC 9534, DOI 10.17487/RFC9534, January 2024,		RFC 9534, DOI 10.17487/RFC9534, January 2024,
	<https://www.rfc-editor.org/info/rfc9534>.		<https://www.rfc-editor.org/info/rfc9534>.
	Acknowledgments		Acknowledgments
	The authors would like to thank Ianik Semco and Miloslav Kopka for		The authors would like to thank Ianik Semco and Miloslav Kopka for
	the discussions on the bit error rate measurements.		the discussions on the bit error rate measurements. The authors
			would also like to thank Ruediger Geib and William Hawkins for
			reviewing this document and providing many useful comments and
			suggestions.
	Authors' Addresses		Authors' Addresses
	Rakesh Gandhi (editor)		Rakesh Gandhi (editor)
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Canada		Canada
	Email: rgandhi@cisco.com		Email: rgandhi@cisco.com
	Peter Schoenmaker		Peter Schoenmaker
	Meta Platforms, Inc.		Meta Platforms, Inc.
End of changes. 25 change blocks.
	50 lines changed or deleted		108 lines changed or added
This html diff was produced by rfcdiff 1.49. The latest version is available from https://github.com/ietf-tools/rfcdiff