rfc9947v1.txt		rfc9947.txt
	skipping to change at line 12 ¶		skipping to change at line 12 ¶
	Independent Submission G. Fioccola		Independent Submission G. Fioccola
	Request for Comments: 9947 T. Zhou		Request for Comments: 9947 T. Zhou
	Category: Experimental Huawei		Category: Experimental Huawei
	ISSN: 2070-1721 G. Mishra		ISSN: 2070-1721 G. Mishra
	Verizon Inc.		Verizon Inc.
	X. Wang		X. Wang
	Ruijie		Ruijie
	G. Zhang		G. Zhang
	China Mobile		China Mobile
	M. Cociglio		M. Cociglio
	February 2026		March 2026
	Application of the Alternate-Marking Method to the Segment Routing		Application of the Alternate-Marking Method to the Segment Routing
	Header		Header
	Abstract		Abstract
	This document describes an alternative experimental approach for the		This document describes an alternative experimental approach for the
	application of the Alternate-Marking Method to Segment Routing for		application of the Alternate-Marking Method to Segment Routing for
	IPv6 (SRv6). It uses an experimental TLV in the Segment Routing		IPv6 (SRv6). It uses an experimental TLV in the Segment Routing
	Header (SRH); thus, participation in this experiment should be		Header (SRH); thus, participation in this experiment should be
	skipping to change at line 35 ¶		skipping to change at line 35 ¶
	described in RFC 9343, and the scope of the experiment is to		described in RFC 9343, and the scope of the experiment is to
	determine whether those are significant and attractive to the		determine whether those are significant and attractive to the
	community.		community.
	This protocol extension has been developed outside the IETF as an		This protocol extension has been developed outside the IETF as an
	alternative to the IETF's Standards Track specification RFC 9343 and		alternative to the IETF's Standards Track specification RFC 9343 and
	it does not have IETF consensus. It is published here to guide		it does not have IETF consensus. It is published here to guide
	experimental implementation and ensure interoperability among		experimental implementation and ensure interoperability among
	implementations to better determine the value of this approach.		implementations to better determine the value of this approach.
	Researchers are invited to submit their evaluations of this work to		Researchers are invited to submit their evaluations of this work to
	the RFC Editor for consideration as Independent Submissions or to the		the Independent Submissions Editor or to the IETF SPRING Working
	IETF SPRING Working Group as Internet-Drafts.		Group as Internet-Drafts.
	Status of This Memo		Status of This Memo
	This document is not an Internet Standards Track specification; it is		This document is not an Internet Standards Track specification; it is
	published for examination, experimental implementation, and		published for examination, experimental implementation, and
	evaluation.		evaluation.
	This document defines an Experimental Protocol for the Internet		This document defines an Experimental Protocol for the Internet
	community. This is a contribution to the RFC Series, independently		community. This is a contribution to the RFC Series, independently
	of any other RFC stream. The RFC Editor has chosen to publish this		of any other RFC stream. The RFC Editor has chosen to publish this
	skipping to change at line 104 ¶		skipping to change at line 104 ¶
	[RFC9341] and [RFC9342] describe a passive performance measurement		[RFC9341] and [RFC9342] describe a passive performance measurement
	method, which can be used to measure packet loss, latency, and jitter		method, which can be used to measure packet loss, latency, and jitter
	on live traffic. Since this method is based on marking consecutive		on live traffic. Since this method is based on marking consecutive
	batches of packets, the method is often referred as the "Alternate-		batches of packets, the method is often referred as the "Alternate-
	Marking Method".		Marking Method".
	The Alternate-Marking Method requires a marking field so that packet		The Alternate-Marking Method requires a marking field so that packet
	flows can be distinguished and identified. [RFC9343] defines the		flows can be distinguished and identified. [RFC9343] defines the
	standard for how the marking field can be encoded in a new TLV in		standard for how the marking field can be encoded in a new TLV in
	either Hop-by-Hop or Destination Options Headers of IPv6 packets in		either Hop-by-Hop or Destination Options Headers of IPv6 packets in
	order to achieve Alternate Marking. The mechanism to carry is		order to achieve Alternate Marking. This mechanism is equally
	equally applicable to Segment Routing for IPv6 (SRv6) networks		applicable to Segment Routing for IPv6 (SRv6) networks [RFC8402].
	[RFC8402].
	This document describes an alternative experimental approach that		This document describes an alternative experimental approach that
	encodes the marking field in a new TLV carried in the Segment Routing		encodes the marking field in a new TLV carried in the Segment Routing
	Header (SRH) [RFC8754] of an SRv6 packet. This approach is		Header (SRH) [RFC8754] of an SRv6 packet. This approach is
	applicable only to SRv6 deployments. It is intended to capitalize on		applicable only to SRv6 deployments. It is intended to capitalize on
	the assumption that Segment Routing (SR) nodes are supposed to		the assumption that Segment Routing (SR) nodes are supposed to
	support fast parsing and processing of the SRH, while the SR nodes		support fast parsing and processing of the SRH, while the SR nodes
	may not properly handle Destination Options, as discussed in		may not properly handle Destination Options, as discussed in
	[RFC9098] and [EH-LIMITS]. The experiment is to determine whether or		[RFC9098] and [EH-LIMITS]. The experiment is to determine whether or
	not there are significant and attractive advantages to the community:		not there are significant and attractive advantages to the community:
	if there are, the work may be brought back for IETF consideration.		if there are, the work may be brought back for IETF consideration.
	This protocol extension has been developed outside the IETF as an		This protocol extension has been developed outside the IETF as an
	alternative to the IETF's Standards Track specification [RFC9343]; it		alternative to the IETF's Standards Track specification [RFC9343]; it
	does not have IETF consensus. It is published here to guide		does not have IETF consensus. It is published here to guide
	experimental implementation and ensure interoperability among		experimental implementation and ensure interoperability among
	implementations to better determine the value of this approach. As		implementations to better determine the value of this approach. As
	also highlighted in [IETF-EXPERIMENTS], when two protocol extensions		also highlighted in [IETF-EXPERIMENTS], when two protocol extensions
	are proposed to solve a single problem, an experiment can be		are proposed to solve a single problem, an experiment can be
	initiated, and this is the purpose of this document. See Section 5		initiated to gather operational experience and "determine which, if
	for more details about the experimentation.		either, of the protocols should be progressed to the standards
			track." This is the purpose of this document. See Section 5 for
			more details about the experiment.
	1.1. Observations on RFC 9343		1.1. Observations on RFC 9343
	Like any other IPv6 use case, Hop-by-Hop and Destination Options can		Like any other IPv6 use case, Hop-by-Hop and Destination Options can
	also be used when the SRH is present. As specified in [RFC8200], the		also be used when the SRH is present. As specified in [RFC8200], the
	Hop-by-Hop Options Header is used to carry optional information that		Hop-by-Hop Options Header is used to carry optional information that
	needs to be examined at every hop along the path, while the		needs to be examined at every hop along the path, while the
	Destination Options Header is used to carry optional information that		Destination Options Header is used to carry optional information that
	needs to be examined only by the packet's destination node(s).		needs to be examined only by the packet's destination node(s).
	skipping to change at line 156 ¶		skipping to change at line 157 ¶
	configured to do so. Both the Destination Options Header before the		configured to do so. Both the Destination Options Header before the
	SRH and the SRH TLV are processed at the node being indicated in the		SRH and the SRH TLV are processed at the node being indicated in the
	destination address field of the IPv6 header.		destination address field of the IPv6 header.
	The distinction between the alternatives is most notable for SRv6		The distinction between the alternatives is most notable for SRv6
	packets that traverse a network where the paths between sequential		packets that traverse a network where the paths between sequential
	segment endpoints include multiple hops. If the Hop-by-Hop Option is		segment endpoints include multiple hops. If the Hop-by-Hop Option is
	used, then every hop along the path will process the AltMark data.		used, then every hop along the path will process the AltMark data.
	If the Destination Option positioned before the SRH is used, or the		If the Destination Option positioned before the SRH is used, or the
	SRH AltMark TLV is used, then only the segment endpoints will process		SRH AltMark TLV is used, then only the segment endpoints will process
	the AltMark data.		the AltMark data, unless the intermediate node has a different
			priority rule.
	Both [RFC9343] and the approach specified in this document can		Both [RFC9343] and the approach specified in this document can
	coexist. Indeed, this document does not change or invalidate any		coexist. Indeed, this document does not change or invalidate any
	procedures defined in [RFC9343]. However, deployment issues may		procedures defined in [RFC9343]. However, deployment issues may
	arise, as further discussed below.		arise, as further discussed below.
	The rest of this document is structured as follows:		The rest of this document is structured as follows:
	* Section 2 covers the application of the Alternate-Marking Method		* Section 2 covers the application of the Alternate-Marking Method
	to SRv6,		to SRv6,
	skipping to change at line 196 ¶		skipping to change at line 198 ¶
	SRv6 leverages the IPv6 SRH, which can embed TLVs to provide metadata		SRv6 leverages the IPv6 SRH, which can embed TLVs to provide metadata
	for segment processing, as described in [RFC8754]. This document		for segment processing, as described in [RFC8754]. This document
	defines the SRH AltMark TLV to carry Alternate-Marking data fields		defines the SRH AltMark TLV to carry Alternate-Marking data fields
	for use in SRv6 networks, and it is an alternative to the method		for use in SRv6 networks, and it is an alternative to the method
	described in [RFC9343]. [RFC9343] defines how the Alternate-Marking		described in [RFC9343]. [RFC9343] defines how the Alternate-Marking
	Method can be carried in the Option Headers (Hop-by-Hop or		Method can be carried in the Option Headers (Hop-by-Hop or
	Destination) of an IPv6 packet. The AltMark data fields format		Destination) of an IPv6 packet. The AltMark data fields format
	defined in [RFC9343] is the basis of the AltMark SRH TLV introduced		defined in [RFC9343] is the basis of the AltMark SRH TLV introduced
	in Section 3.		in Section 3.
	In addition to the base data fields of [RFC9343], it is also allowed		In addition to the base data fields of [RFC9343], the insertion of
	the insertion of optional extended data fields that are not present		optional extended data fields that are not present in [RFC9343] is
	in [RFC9343]. These extended data fields can support metadata for		also allowed. These extended data fields can support metadata for
	additional telemetry requirements, as further described below.		additional telemetry requirements, as further described below.
	2.1. Controlled Domain		2.1. Controlled Domain
	[RFC8799] introduces the concept of specific limited domain solutions		[RFC8799] introduces the concept of specific limited domain solutions
	and notes the application of the Alternate-Marking Method as an		and notes the application of the Alternate-Marking Method as an
	example.		example.
	Despite the flexibility of IPv6, when innovative applications are		Despite the flexibility of IPv6, when innovative applications are
	proposed, they are often applied within controlled domains to help		proposed, they are often applied within controlled domains to help
	constrain the domain-wide policies, options supported, the style of		constrain the domain-wide policies, options supported, the style of
	network management, and security requirements. This is also the case		network management, and security requirements. This is also the case
	for applying the Alternate-Marking Method to SRv6.		for applying the Alternate-Marking Method to SRv6.
	Therefore, the experimentation of the Alternate-Marking Method to		Therefore, the experiment of applying the Alternate-Marking Method to
	SRv6 MUST be deployed only within a controlled domain. For SRv6, the		SRv6 MUST only be deployed within a controlled domain. For SRv6, the
	controlled domain corresponds to an SR domain, as defined in		controlled domain corresponds to an SR domain, as defined in
	[RFC8402]. The Alternate-Marking measurement domain overlaps with		[RFC8402]. The Alternate-Marking measurement domain overlaps with
	the controlled domain.		the controlled domain.
	The use of a controlled domain is also appropriate for the deployment		The use of a controlled domain is also appropriate for the deployment
	of an experimental protocol extension. Carefully bounding the domain		of an experimental protocol extension. Carefully bounding the domain
	reduces the risk of the experiment leaking out and clashing with		reduces the risk of the experiment leaking out and clashing with
	other experiments of causing unforeseen consequences in wider		other experiments or causing unforeseen consequences in wider
	deployments.		deployments.
	3. Definition of the SRH AltMark TLV		3. Definition of the SRH AltMark TLV
	The AltMark SRH TLV is defined to carry the data fields associated		The AltMark SRH TLV is defined to carry the data fields associated
	with the Alternate-Marking Method. The TLV has some initial fields		with the Alternate-Marking Method. The TLV has some initial fields
	that are always present and further extension fields that are present		that are always present and further extension fields that are present
	when Enhanced Alternate Marking is in use.		when Enhanced Alternate Marking is in use.
	Figure 1 shows the format of the AltMark TLV.		Figure 1 shows the format of the AltMark TLV.
	skipping to change at line 251 ¶		skipping to change at line 253 ¶
	~ Optional extended data fields (variable) ~		~ Optional extended data fields (variable) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: The AltMark SRH TLV for Alternate Marking		Figure 1: The AltMark SRH TLV for Alternate Marking
	The fields of this TLV are as follows:		The fields of this TLV are as follows:
	SRH TLV Type: The 8-bit identifier of the Alternate-Marking SRH TLV.		SRH TLV Type: The 8-bit identifier of the Alternate-Marking SRH TLV.
	The value for this field is taken from the range 124-126. It is		The value for this field is taken from the range 124-126. It is
	an Experimental code point that indicates a TLV that does not		an Experimental code point that indicates a TLV that does not
	change en route. Experimentation of this document must coordinate		change en route. Deployment of this document must coordinate the
	the value used by all implementations participating in the		value used by all implementations participating in the experiment.
	experiment. Therefore, experiments should carefully consider any		Therefore, experiments should carefully consider any other
	other implementations running in the controlled domain to avoid		implementations running in the controlled domain to avoid clashes
	clashes with other SRH TLVs.		with other SRH TLVs.
	SRH TLV Len: The length of the Data Fields of this TLV in bytes.		SRH TLV Len: The length of the Data Fields of this TLV in bytes.
	This is set to 6 when Enhanced Alternate Marking is not in use.		This is set to 6 when Enhanced Alternate Marking is not in use.
	Reserved: Reserved for future use. These bits MUST be set to zero		Reserved: Reserved for future use. These bits MUST be set to zero
	on transmission and ignored on receipt.		on transmission and ignored on receipt.
	FlowMonID: The Flow Monitoring Identification field. It is a 20-bit		FlowMonID: The Flow Monitoring Identification field. It is a 20-bit
	unsigned integer as defined in [RFC9343].		unsigned integer as defined in [RFC9343].
	skipping to change at line 355 ¶		skipping to change at line 357 ¶
	W bit: Flow direction identification. This flag is used if		W bit: Flow direction identification. This flag is used if
	backward direction flow monitoring is requested to be set up		backward direction flow monitoring is requested to be set up
	automatically, so that the egress node is instructed to setup		automatically, so that the egress node is instructed to setup
	the backward flow monitoring. If W=1, it indicates that the		the backward flow monitoring. If W=1, it indicates that the
	flow direction is forward. If W=0, it indicates that the flow		flow direction is forward. If W=0, it indicates that the flow
	direction is backward.		direction is backward.
	R bit: Reserved. This bit MUST be set to zero and ignored on		R bit: Reserved. This bit MUST be set to zero and ignored on
	receipt.		receipt.
	Len: Length. Indicates the length of the extended data fields in		Len: Length. Indicates the length of the extended data fields for
	bytes for Enhanced Alternate Marking. It includes all of the		Enhanced Alternate Marking as a multiple of 4 bytes. It includes
	fields shown in Figure 2 including any metadata that is present.		all of the fields shown in Figure 2 including any metadata that is
			present.
	Rsvd: Reserved for further use. These bits MUST be set to zero on		Rsvd: Reserved for further use. These bits MUST be set to zero on
	transmission and ignored on receipt.		transmission and ignored on receipt.
	MetaInfo: A 16-bit Bitmap to indicate more metadata attached in the		MetaInfo: A 16-bit Bitmap to indicate more metadata attached in the
	Optional MetaData field for enhanced functions. More than one bit		Optional MetaData field for enhanced functions. More than one bit
	may be set, in which case the additional metadata is present in		may be set, in which case the additional metadata is present in
	the order that the bits are set. MetaInfo bits are numbered from		the order that the bits are set. MetaInfo bits are numbered from
	0 as the most significant bit. Three bits and associated metadata		0 as the most significant bit. Three bits and associated metadata
	are defined as follows:		are defined as follows:
	skipping to change at line 512 ¶		skipping to change at line 515 ¶
	As highlighted in Section 1.1, the use of the Destination Option to		As highlighted in Section 1.1, the use of the Destination Option to
	carry the AltMark data preceding the SRH is equivalent to the SRH		carry the AltMark data preceding the SRH is equivalent to the SRH
	AltMark TLV. Therefore, it is important to analyze what happens when		AltMark TLV. Therefore, it is important to analyze what happens when
	both the SRH AltMark TLV and the Destination Option are present, and		both the SRH AltMark TLV and the Destination Option are present, and
	how that would impact processing and complexity.		how that would impact processing and complexity.
	It is worth mentioning that the SRH AltMark TLV and the Destination		It is worth mentioning that the SRH AltMark TLV and the Destination
	Option carrying AltMark data can coexist without problems. If both		Option carrying AltMark data can coexist without problems. If both
	are present, the only issue could be the duplication of information,		are present, the only issue could be the duplication of information,
	but this will not affect in any way the device and the network		but this will not affect in any way the device and the network
	services. The security requirement of controlled domain applies to		services. Both this document and [RFC9343] require a controlled
	both this document and [RFC9343], and it also confines this		domain for security purposes, which confines this duplication to a
	duplication to single service provider networks. However,		single service provider network. Duplication of the same information
	duplication of the same information in different places should be		in different places should be avoided, and analyzing the use of only
	avoided, and it is recommended to only analyze the use of the SRH		the SRH AltMark TLV is recommended as part of this experiment.
	AltMark TLV for the experimentation.
	5. Experimentation Overview		5. Experimentation Overview
	The protocol extension described in this document is built on		The protocol extension described in this document is built on
	existing technology using an Experimental code point.		existing technology using an Experimental code point. Experiment
	Experimentation of this document must use a code point chosen from		participants must use a code point chosen from the Experimental
	the Experimental range, as noted in Section 3, and should make it		range, as noted in Section 3, and should make it possible for the
	possible for the operator to configure the value used in a deployment		operator to configure the value used in a deployment such that it is
	such that it is possible to conduct multiple non-conflicting		possible to conduct multiple non-conflicting experiments within the
	experiments within the same network.		same network.
	This experiment aims to determine whether or not the use of the SRH		This experiment aims to determine whether or not the use of the SRH
	AltMark TLV brings advantages, in particular, in consideration of		AltMark TLV brings advantages, in particular, in consideration of
	implementations that cannot support multiple IPv6 extension headers		implementations that cannot support multiple IPv6 extension headers
	in the same packet, or which do not support Destination Options		in the same packet, or which do not support Destination Options
	Header processing, or which process the Destination Options Header on		Header processing, or which process the Destination Options Header on
	the slow path.		the slow path.
	This experiment also needs to determine whether the proposed protocol		This experiment also needs to determine whether the proposed protocol
	extensions achieve the desired function and can be supported in the		extensions achieve the desired function and can be supported in the
	skipping to change at line 551 ¶		skipping to change at line 553 ¶
	It is anticipated that this experiment will be contained within a		It is anticipated that this experiment will be contained within a
	single service provider network in keeping with the constraints of an		single service provider network in keeping with the constraints of an
	SR domain, and also in keeping with the limits in sharing performance		SR domain, and also in keeping with the limits in sharing performance
	monitoring data collected on the path of packets in the network. The		monitoring data collected on the path of packets in the network. The
	scope of the experimental deployment may depend on the availability		scope of the experimental deployment may depend on the availability
	of implementations and the willingness of operators to deploy it on		of implementations and the willingness of operators to deploy it on
	live networks.		live networks.
	The results of this experiment will be collected and shared with the		The results of this experiment will be collected and shared with the
	RFC Editor for consideration as an Independent Submission or with the		Independent Submissions Editor or with the IETF SPRING Working Group
	IETF SPRING Working Group as an Internet-Draft, to help forward the		as Internet-Drafts to help progress the discussions that will
	discussions that will determine the correct development of Alternate-		determine the correct development of Alternate-Marking Method
	Marking Method solutions in SRv6 networks. It is expected that		solutions in SRv6 networks. It is expected that initial results will
	initial results will be made available within two years of the		be made available within two years of the publication of this
	publication of this document as an RFC.		document as an RFC.
	5.1. Objective of the Experiment		5.1. Objective of the Experiment
	Researchers are invited to evaluate the SRH AltMark TLV against the		Researchers are invited to evaluate the SRH AltMark TLV against the
	existing approach in [RFC9343]. There are several potential areas of		existing approach in [RFC9343]. There are several potential areas of
	exploration for this experimentation that need to be analyzed:		exploration for this experimentation that need to be analyzed:
	* Does the use of the SRH AltMark TLV survive across a network		* Does the use of the SRH AltMark TLV survive across a network
	better or worse than the use of an extension header?		better or worse than the use of an extension header?
	* Does the SRH TLV processing represent a performance improvement or		* Does the SRH TLV processing represent a performance improvement or
	hindrance on the device as compared to the Destination Option?		hindrance on the device as compared to the Destination Option?
	* Is the forwarding plane performance impacted across different		* Is the forwarding plane performance impacted across different
	device architecture types compared to the use of the SRH TLV and		device architecture types when comparing the use of the SRH TLV
	Destination Option?		with the use of Destination Option?
	* How does use of the extended data fields, introduced in		* How does use of the extended data fields, introduced in
	Section 3.2, compare to other on-path telemetry methods from the		Section 3.2, compare to other on-path telemetry methods from the
	point of view of the operators?		point of view of the operators?
	6. Security Considerations		6. Security Considerations
	The security considerations of SRv6 are discussed in [RFC8754] and		The security considerations of SRv6 are discussed in [RFC8754] and
	[RFC8986], and the security considerations of Alternate Marking in		[RFC8986], and the security considerations of Alternate Marking in
	general and its application to IPv6 are discussed in [RFC9341] and		general and its application to IPv6 are discussed in [RFC9341] and
	skipping to change at line 714 ¶		skipping to change at line 716 ¶
	Contributors		Contributors
	The following people provided relevant contributions to this		The following people provided relevant contributions to this
	document:		document:
	Fabio Bulgarella		Fabio Bulgarella
	Telecom Italia		Telecom Italia
	Email: fabio.bulgarella@guest.telecomitalia.it		Email: fabio.bulgarella@guest.telecomitalia.it
	Massimo Nilo		Massimo Nilo
	Telecom Italia		FiberCop
	Email: massimo.nilo@telecomitalia.it		Email: massimo.nilo@fibercop.com
	Fabrizio Milan		Fabrizio Milan
	Telecom Italia		FiberCop
	Email: fabrizio.milan@telecomitalia.it		Email: fabrizio.milan@fibercop.com
	Authors' Addresses		Authors' Addresses
	Giuseppe Fioccola		Giuseppe Fioccola
	Huawei		Huawei
	Viale Martesana, 12		Viale Martesana, 12
	20055 Vimodrone (Milan)		20055 Vimodrone (Milan)
	Italy		Italy
	Email: giuseppe.fioccola@huawei.com		Email: giuseppe.fioccola@huawei.com
End of changes. 16 change blocks.
	47 lines changed or deleted		49 lines changed or added
This html diff was produced by rfcdiff 1.48.