< draft-ietf-6man-ipv6-alt-mark-03.txt		draft-ietf-6man-ipv6-alt-mark-04.txt >
	6MAN Working Group G. Fioccola		6MAN Working Group G. Fioccola
	Internet-Draft T. Zhou		Internet-Draft T. Zhou
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: August 1, 2021 M. Cociglio		Expires: September 9, 2021 M. Cociglio
	Telecom Italia		Telecom Italia
	F. Qin		F. Qin
	China Mobile		China Mobile
	R. Pang		R. Pang
	China Unicom		China Unicom
	January 28, 2021		March 8, 2021
	IPv6 Application of the Alternate Marking Method		IPv6 Application of the Alternate Marking Method
	draft-ietf-6man-ipv6-alt-mark-03		draft-ietf-6man-ipv6-alt-mark-04
	Abstract		Abstract
	This document describes how the Alternate Marking Method can be used		This document describes how the Alternate Marking Method can be used
	as the passive performance measurement tool in an IPv6 domain and		as a passive performance measurement tool in an IPv6 domain. It
	reports implementation considerations. It proposes how to define a		defines a new Extension Header Option to encode alternate marking
	new Extension Header Option to encode alternate marking technique and		information in both the Hop-by-Hop Options Header and Destination
	both Hop-by-Hop Options Header and Destination Options Header are		Options Header.
	considered.
	Requirements Language		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", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in BCP 14 [RFC2119]		document are to be interpreted as described in BCP 14 [RFC2119]
	[RFC8174] when, and only when, they appear in all capitals, as shown		[RFC8174] when, and only when, they appear in all capitals, as shown
	here.		here.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 49 ¶		skipping to change at page 1, line 48 ¶
	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 August 1, 2021.		This Internet-Draft will expire on September 9, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 48 ¶		skipping to change at page 2, line 48 ¶
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	[RFC8321] and [RFC8889] describe a passive performance measurement		[RFC8321] and [RFC8889] 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 Alternate Marking		batches of packets, the method is often referred as the Alternate
	Method.		Marking Method.
	The Alternate Marking Method has became mature to be implemented and		This document defines how the Alternate Marking Method can be used to
	encoded in the IPv6 protocol and this document defines how it can be		measure packet loss and delay metrics in IPv6.
	used to measure packet loss and delay metrics in IPv6.
	The format of the IPv6 addresses is defined in [RFC4291] while		The format of IPv6 addresses is defined in [RFC4291] while [RFC8200]
	[RFC8200] defines the IPv6 Header, including a 20-bit Flow Label and		defines the IPv6 Header, including a 20-bit Flow Label and the IPv6
	the IPv6 Extension Headers. The Segment Routing Header (SRH) is		Extension Headers.
	defined in [RFC8754] to apply Segment Routing over IPv6 dataplane
	(SRv6).
	[I-D.fioccola-v6ops-ipv6-alt-mark] summarizes the possible		[I-D.fioccola-v6ops-ipv6-alt-mark] summarizes the possible
	implementation options for the application of the Alternate Marking		implementation options for the application of the Alternate Marking
	Method in an IPv6 domain. This document, starting from the outcome		Method in an IPv6 domain. This document, starting from the outcome
	of [I-D.fioccola-v6ops-ipv6-alt-mark], introduces a new TLV that can		of [I-D.fioccola-v6ops-ipv6-alt-mark], introduces a new TLV that can
	be encoded in the Options Headers (both Hop-by-Hop or Destination)		be encoded in the Options Headers (Hop-by-Hop or Destination) for the
	for the purpose of the Alternate Marking Method application in an		purpose of the Alternate Marking Method application in an IPv6
	IPv6 domain. The case of SRH ([RFC8754]) is also discussed, anyway		domain. While the case of Segment Routing Header (SRH), defined in
	this is valid for all the types of Routing Header (RH).		[RFC8754], is also discussed, it is valid for all the types of
			Routing Header (RH).
	2. Alternate Marking application to IPv6		2. Alternate Marking application to IPv6
	The Alternate Marking Method requires a marking field. As mentioned,		The Alternate Marking Method requires a marking field. As mentioned,
	several alternatives have been analysed in		several alternatives have been analysed in
	[I-D.fioccola-v6ops-ipv6-alt-mark] such as IPv6 Extension Headers,		[I-D.fioccola-v6ops-ipv6-alt-mark] such as IPv6 Extension Headers,
	IPv6 Address and Flow Label.		IPv6 Address and Flow Label.
	Consequently, it is possible to state that the only robust choice is		Consequently, a robust choice is to standardize a new Hop-by-Hop or
	to standardize a new Hop-by-Hop or Destination Option.		Destination Option.
	This approach is compliant with [RFC8200] indeed the Alternate		This approach is compliant with [RFC8200]. The Alternate Marking
	Marking application to IPv6 involves the following operations:		application to IPv6 involves the following operations:
	o The source node is the only one that writes the Option Header to		o The source node is the only one that writes the Option Header to
	mark alternately the flow (for both Hop-by-Hop and Destination		mark alternately the flow (for both Hop-by-Hop and Destination
	Option).		Option).
	o In case of Hop-by-Hop Option Header carrying Alternate Marking		o In case of Hop-by-Hop Option Header carrying Alternate Marking
	bits, it is not inserted or deleted, but can be read by any node		bits, it is not inserted or deleted, but can be read by any node
	along the path. The intermediate nodes may be configured to		along the path. The intermediate nodes may be configured to
	support this Option or not. Anyway this does not impact the		support this Option or not and the measurement can be done only
	traffic throughput since the measurement can be done only for the		for the nodes configured to read the Option. Anyway this should
	nodes configured to read the Option.		not affect the traffic throughput on nodes that do not recognize
			the Option, as further discussed in Section 4.
	o In case of Destination Option Header carrying Alternate Marking		o In case of Destination Option Header carrying Alternate Marking
	bits, it is not processed, inserted, or deleted by any node along		bits, it is not processed, inserted, or deleted by any node along
	the path until the packet reaches the destination node. Note		the path until the packet reaches the destination node. Note
	that, if there is also a Routing Header (RH), any visited		that, if there is also a Routing Header (RH), any visited
	destination in the route list can process the Option Header.		destination in the route list can process the Option Header.
	Hop-by-Hop Option Header is also useful to signal to routers on the		Hop-by-Hop Option Header is also useful to signal to routers on the
	path to process the Alternate Marking, anyway it is to be expected		path to process the Alternate Marking, anyway it is to be expected
	that some routers cannot process it unless explicitly configured.		that some routers cannot process it unless explicitly configured.
	skipping to change at page 5, line 46 ¶		skipping to change at page 5, line 44 ¶
	Type; for AltMark these two bits MUST be set to 00 (skip over this		Type; for AltMark these two bits MUST be set to 00 (skip over this
	Option and continue processing the header). The third-highest-		Option and continue processing the header). The third-highest-
	order bit specifies whether or not the Option Data can change en		order bit specifies whether or not the Option Data can change en
	route to the packet's final destination; for AltMark the value of		route to the packet's final destination; for AltMark the value of
	this bit MUST be set to 0 (Option Data does not change en route).		this bit MUST be set to 0 (Option Data does not change en route).
	o Opt Data Len: The length of the Option Data Fields of this Option		o Opt Data Len: The length of the Option Data Fields of this Option
	in bytes.		in bytes.
	o FlowMonID: 20 bits unsigned integer. The FlowMon identifier is		o FlowMonID: 20 bits unsigned integer. The FlowMon identifier is
	described hereinafter.		described in Section 5.3.
	o L: Loss flag for Packet Loss Measurement as described hereinafter;		o L: Loss flag for Packet Loss Measurement as described in
			Section 5.1;
	o D: Delay flag for Single Packet Delay Measurement as described		o D: Delay flag for Single Packet Delay Measurement as described in
	hereinafter;		Section 5.2;
	o Reserved: is reserved for future use. These bits MUST be set to		o Reserved: is reserved for future use. These bits MUST be set to
	zero on transmission and ignored on receipt.		zero on transmission and ignored on receipt.
	4. Use of the AltMark Option		4. Use of the AltMark Option
	The AltMark Option is the best way to implement the Alternate Marking		The AltMark Option is the best way to implement the Alternate Marking
	method and can be carried by the Hop-by-Hop Options header and the		method and can be carried by the Hop-by-Hop Options header and the
	Destination Options header. In case of Destination Option, it is		Destination Options header. In case of Destination Option, it is
	processed only by the source and destination nodes: the source node		processed only by the source and destination nodes: the source node
	inserts and the destination node removes it. While, in case of Hop-		inserts and the destination node removes it. While, in case of Hop-
	by-Hop Option, it may be examined by any node along the path, if		by-Hop Option, it may be examined by any node along the path, if
	explicitly configured to do so. In this way an unrecognized Hop-by-		explicitly configured to do so.
	Hop Option may be just ignored without any impact.
	So it is important to highlight that the Option Layout can be used		It is important to highlight that the Option Layout can be used both
	both as Destination Option and as Hop-by-Hop Option depending on the		as Destination Option and as Hop-by-Hop Option depending on the Use
	Use Cases and it is based on the chosen type of performance		Cases and it is based on the chosen type of performance measurement.
	measurement. In general, it is needed to perform both end to end and		In general, it is needed to perform both end to end and hop by hop
	hop by hop measurements, and the alternate marking methodology		measurements, and the alternate marking methodology allows, by
	allows, by definition, both performance measurements. Anyway, in		definition, both performance measurements. Anyway, in many cases the
	many cases the end-to-end measurement is not enough and it is		end-to-end measurement is not enough and it is required also the hop-
	required also the hop-by-hop measurement, so the most complete choice		by-hop measurement, so the most complete choice is the Hop-by-Hop
	is the Hop-by-Hop Options Header.		Options Header.
	IPv6, as specified in [RFC8200], allows nodes to optionally process		IPv6, as specified in [RFC8200], allows nodes to optionally process
	Hop-by-Hop headers. Specifically the Hop-by-Hop Options header is		Hop-by-Hop headers. Specifically the Hop-by-Hop Options header is
	not inserted or deleted, but may be examined or processed by any node		not inserted or deleted, but may be examined or processed by any node
	along a packet's delivery path, until the packet reaches the node (or		along a packet's delivery path, until the packet reaches the node (or
	each of the set of nodes, in the case of multicast) identified in the		each of the set of nodes, in the case of multicast) identified in the
	Destination Address field of the IPv6 header. Also, it is expected		Destination Address field of the IPv6 header. Also, it is expected
	that nodes along a packet's delivery path only examine and process		that nodes along a packet's delivery path only examine and process
	the Hop-by-Hop Options header if explicitly configured to do so.		the Hop-by-Hop Options header if explicitly configured to do so.
	The Hop-by-Hop Option defined in this document is designed to take		The Hop-by-Hop Option defined in this document is designed to take
	advantage of the property of how Hop-by-Hop options are processed.		advantage of the property of how Hop-by-Hop options are processed.
	Nodes that do not support this Option SHOULD ignore them. This can		Nodes that do not support this Option SHOULD ignore them. This can
	mean that, in this case, the performance measurement does not account		mean that, in this case, the performance measurement does not account
	for all links and nodes along a path.		for all links and nodes along a path.
	Another application that can be mentioned is the presence of a		Another application that can be mentioned is the presence of a
	Routing Header, in particular it is possible to consider SRv6. SRv6		Routing Header, in particular it is possible to consider SRv6. A new
	leverages the Segment Routing header which consists of a new type of		type of Routing Header, referred as SRH, has been defined for SRv6.
	routing header. Like any other use case of IPv6, Hop-by-Hop and		Like any other use case of IPv6, Hop-by-Hop and Destination Options
	Destination Options are useable when SRv6 header is present. Because		are useable when SRv6 header is present. Because SRv6 is implemented
	SRv6 is implemented through a Segment Routing Header (SRH),		through a Segment Routing Header (SRH), Destination Options before
	Destination Options before the Routing Header are processed by each		the Routing Header are processed by each destination in the route
	destination in the route list, that means, in case of SRH, by every		list, that means, in case of SRH, by every node that is an identity
	node that is an identity in the SR path.		in the SR path.
	In summary, it is possible to list the alternative possibilities:		In summary, it is possible to list the alternative possibilities:
	o Destination Option not preceding a Routing Header => measurement		o Destination Option not preceding a Routing Header => measurement
	only by node in Destination Address.		only by node in Destination Address.
	o Hop-by-Hop Option => every router on the path with feature		o Hop-by-Hop Option => every router on the path with feature
	enabled.		enabled.
	o Destination Option preceding a Routing Header => every destination		o Destination Option preceding a Routing Header => every destination
	skipping to change at page 7, line 47 ¶		skipping to change at page 7, line 47 ¶
	"skip if do not recognize and data do not change en route".		"skip if do not recognize and data do not change en route".
	[RFC8200] also mentions that the nodes only examine and process the		[RFC8200] also mentions that the nodes only examine and process the
	Hop-by-Hop Options header if explicitly configured to do so. For		Hop-by-Hop Options header if explicitly configured to do so. For
	these reasons, this HbH Option should not affect the throughput.		these reasons, this HbH Option should not affect the throughput.
	Anyway, in practice, it is important to be aware for the		Anyway, in practice, it is important to be aware for the
	implementation that the things may be different and it can happen		implementation that the things may be different and it can happen
	that packets with Hop-by-Hop are forced onto the slow path, but this		that packets with Hop-by-Hop are forced onto the slow path, but this
	is a general issue, as also explained in		is a general issue, as also explained in
	[I-D.hinden-6man-hbh-processing].		[I-D.hinden-6man-hbh-processing].
	In addition to the previous alternatives, for legacy network it is		In addition to the previous alternatives, it could be possible to
	possible to mention a non-conventional application of the Destination		consider a non-conventional application of the Destination Options
	Option for the hop by hop usage. [RFC8200] defines that the nodes		for hop by hop action, but this would cause worse performance than
	along a path examine and process the Hop-by-Hop Options header only		Hop-by-Hop. The only motivation for the hop by hop usage of
	if Hop-by-Hop processing is explicitly configured. On the other		Destination Options can be for compatibility reasons but in general
	hand, using the Destination Option for hop by hop action would cause		it is not recommended.
	worse performance than Hop-by-Hop. The only motivation for the hop
	by hop usage of Destination Options can be for compatibility reasons
	but in general it is not recommended.
	5. Alternate Marking Method Operation		5. Alternate Marking Method Operation
	This section describes how the method operates. [RFC8321] introduces		This section describes how the method operates. [RFC8321] introduces
	several alternatives but in this section the most applicable methods		several alternatives but in this section the most applicable methods
	are reported and a new field is introduced to facilitate the		are reported and a new field is introduced to facilitate the
	deployment and improve the scalability.		deployment and improve the scalability.
	5.1. Packet Loss Measurement		5.1. Packet Loss Measurement
End of changes. 19 change blocks.
	62 lines changed or deleted		57 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/