< draft-ietf-6man-ipv6-alt-mark-12.txt		draft-ietf-6man-ipv6-alt-mark-13.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: April 25, 2022 M. Cociglio		Expires: October 2, 2022 M. Cociglio
	Telecom Italia		Telecom Italia
	F. Qin		F. Qin
	China Mobile		China Mobile
	R. Pang		R. Pang
	China Unicom		China Unicom
	October 22, 2021		March 31, 2022
	IPv6 Application of the Alternate Marking Method		IPv6 Application of the Alternate Marking Method
	draft-ietf-6man-ipv6-alt-mark-12		draft-ietf-6man-ipv6-alt-mark-13
	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 a passive performance measurement tool in an IPv6 domain. It		as a passive performance measurement tool in an IPv6 domain. It
	defines a new Extension Header Option to encode Alternate Marking		defines a new Extension Header Option to encode Alternate Marking
	information in both the Hop-by-Hop Options Header and Destination		information in both the Hop-by-Hop Options Header and Destination
	Options Header.		Options Header.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 April 25, 2022.		This Internet-Draft will expire on October 2, 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 24 ¶		skipping to change at page 2, line 24 ¶
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Alternate Marking application to IPv6 . . . . . . . . . . . . 3		2. Alternate Marking application to IPv6 . . . . . . . . . . . . 3
	2.1. Controlled Domain . . . . . . . . . . . . . . . . . . . . 5		2.1. Controlled Domain . . . . . . . . . . . . . . . . . . . . 5
	2.1.1. Alternate Marking Measurement Domain . . . . . . . . 6		2.1.1. Alternate Marking Measurement Domain . . . . . . . . 6
	3. Definition of the AltMark Option . . . . . . . . . . . . . . 7		3. Definition of the AltMark Option . . . . . . . . . . . . . . 7
	3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 7		3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 7
	4. Use of the AltMark Option . . . . . . . . . . . . . . . . . . 8		4. Use of the AltMark Option . . . . . . . . . . . . . . . . . . 8
	5. Alternate Marking Method Operation . . . . . . . . . . . . . 10		5. Alternate Marking Method Operation . . . . . . . . . . . . . 10
	5.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 10		5.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 10
	5.2. Packet Delay Measurement . . . . . . . . . . . . . . . . 11		5.2. Packet Delay Measurement . . . . . . . . . . . . . . . . 12
	5.3. Flow Monitoring Identification . . . . . . . . . . . . . 13		5.3. Flow Monitoring Identification . . . . . . . . . . . . . 13
	5.4. Multipoint and Clustered Alternate Marking . . . . . . . 15		5.4. Multipoint and Clustered Alternate Marking . . . . . . . 15
	5.5. Data Collection and Calculation . . . . . . . . . . . . . 16		5.5. Data Collection and Calculation . . . . . . . . . . . . . 16
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 16		6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	9.1. Normative References . . . . . . . . . . . . . . . . . . 20		9.1. Normative References . . . . . . . . . . . . . . . . . . 20
	9.2. Informative References . . . . . . . . . . . . . . . . . 20		9.2. Informative References . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	[RFC8321] and [RFC8889] describe a passive performance measurement		[I-D.fioccola-rfc8321bis] and [I-D.fioccola-rfc8889bis] describe a
	method, which can be used to measure packet loss, latency and jitter		passive performance measurement method, which can be used to measure
	on live traffic. Since this method is based on marking consecutive		packet loss, latency and jitter on live traffic. Since this method
	batches of packets, the method is often referred to as the Alternate		is based on marking consecutive batches of packets, the method is
	Marking Method.		often referred to as the Alternate Marking Method.
	This document defines how the Alternate Marking Method can be used to		This document defines how the Alternate Marking Method can be used to
	measure performance metrics in IPv6. The rationale is to apply the		measure performance metrics in IPv6. The rationale is to apply the
	Alternate Marking methodology to IPv6 and therefore allow detailed		Alternate Marking methodology to IPv6 and therefore allow detailed
	packet loss, delay and delay variation measurements both hop-by-hop		packet loss, delay and delay variation measurements both hop-by-hop
	and end-to-end to exactly locate the issues in an IPv6 network.		and end-to-end to exactly locate the issues in an IPv6 network.
	The Alternate Marking is an on-path telemetry technique and consists		The Alternate Marking is an on-path telemetry technique and consists
	of synchronizing the measurements in different points of a network by		of synchronizing the measurements in different points of a network by
	switching the value of a marking bit and therefore dividing the		switching the value of a marking bit and therefore dividing the
	skipping to change at page 3, line 30 ¶		skipping to change at page 3, line 30 ¶
	domain.		domain.
	The threat model for the application of the Alternate Marking Method		The threat model for the application of the Alternate Marking Method
	in an IPv6 domain is reported in Section 6. As with all on-path		in an IPv6 domain is reported in Section 6. As with all on-path
	telemetry techniques, the only definitive solution is that this		telemetry techniques, the only definitive solution is that this
	methodology MUST be applied in a controlled domain.		methodology MUST be applied in a controlled domain.
	1.1. Terminology		1.1. Terminology
	This document uses the terms related to the Alternate Marking Method		This document uses the terms related to the Alternate Marking Method
	as defined in [RFC8321] and [RFC8889].		as defined in [I-D.fioccola-rfc8321bis] and
			[I-D.fioccola-rfc8889bis].
	1.2. Requirements Language		1.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.
	2. Alternate Marking application to IPv6		2. Alternate Marking application to IPv6
	skipping to change at page 10, line 12 ¶		skipping to change at page 10, line 16 ¶
	Hop Option should not affect the throughput. However, in practice,		Hop Option should not affect the throughput. However, in practice,
	it is important to be aware that the things may be different in the		it is important to be aware that the things may be different in the
	implementation and it can happen that packets with Hop-by-Hop are		implementation and it can happen that packets with Hop-by-Hop are
	forced onto the slow path, but this is a general issue, as also		forced onto the slow path, but this is a general issue, as also
	explained in [I-D.hinden-6man-hbh-processing]. It is also worth		explained in [I-D.hinden-6man-hbh-processing]. It is also worth
	mentioning that the application to a controlled domain should avoid		mentioning that the application to a controlled domain should avoid
	the risk of arbitrary nodes dropping packets with Hop-by-Hop Options.		the risk of arbitrary nodes dropping packets with Hop-by-Hop Options.
	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.
	several applicable methods which are reported below, and a new field		[I-D.fioccola-rfc8321bis] introduces several applicable methods which
	is introduced to facilitate the deployment and improve the		are reported below, and a new field is introduced to facilitate the
	scalability.		deployment and improve the scalability.
	5.1. Packet Loss Measurement		5.1. Packet Loss Measurement
	The measurement of the packet loss is really straightforward in		The measurement of the packet loss is really straightforward in
	comparison to the existing mechanisms, as detailed in [RFC8321]. The		comparison to the existing mechanisms, as detailed in
	packets of the flow are grouped into batches, and all the packets		[I-D.fioccola-rfc8321bis]. The packets of the flow are grouped into
	within a batch are marked by setting the L bit (Loss flag) to a same		batches, and all the packets within a batch are marked by setting the
	value. The source node can switch the value of the L bit between 0		L bit (Loss flag) to a same value. The source node can switch the
	and 1 after a fixed number of packets or according to a fixed timer,		value of the L bit between 0 and 1 after a fixed number of packets or
	and this depends on the implementation. The source node is the only		according to a fixed timer, and this depends on the implementation.
	one that marks the packets to create the batches, while the		The source node is the only one that marks the packets to create the
	intermediate nodes only read the marking values and identify the		batches, while the intermediate nodes only read the marking values
	packet batches. By counting the number of packets in each batch and		and identify the packet batches. By counting the number of packets
	comparing the values measured by different network nodes along the		in each batch and comparing the values measured by different network
	path, it is possible to measure the packet loss occurred in any		nodes along the path, it is possible to measure the packet loss
	single batch between any two nodes. Each batch represents a		occurred in any single batch between any two nodes. Each batch
	measurable entity recognizable by all network nodes along the path.		represents a measurable entity recognizable by all network nodes
			along the path.
	Both fixed number of packets and fixed timer can be used by the		Both fixed number of packets and fixed timer can be used by the
	source node to create packet batches. But, as also explained in		source node to create packet batches. But, as also explained in
	[RFC8321], the timer-based batches are preferable because they are		[I-D.fioccola-rfc8321bis], the timer-based batches are preferable
	more deterministic than the counter-based batches. There is no		because they are more deterministic than the counter-based batches.
	definitive rule for counter-based batches, differently from timer-		There is no definitive rule for counter-based batches, differently
	based batches. Using a fixed timer for the switching offers better		from timer-based batches. Using a fixed timer for the switching
	control over the method, indeed the length of the batches can be		offers better control over the method, indeed the length of the
	chosen large enough to simplify the collection and the comparison of		batches can be chosen large enough to simplify the collection and the
	the measures taken by different network nodes. In the implementation		comparison of the measures taken by different network nodes. In the
	the counters can be sent out by each node to the controller that is		implementation the counters can be sent out by each node to the
	responsible for the calculation. It is also possible to exchange		controller that is responsible for the calculation. It is also
	this information by using other on-path techniques. But this is out		possible to exchange this information by using other on-path
	of scope for this document.		techniques. But this is out of scope for this document.
	Packets with different L values may get swapped at batch boundaries,		Packets with different L values may get swapped at batch boundaries,
	and in this case, it is required that each marked packet can be		and in this case, it is required that each marked packet can be
	assigned to the right batch by each router. It is important to		assigned to the right batch by each router. It is important to
	mention that for the application of this method there are two		mention that for the application of this method there are two
	elements to consider: the clock error between network nodes and the		elements to consider: the clock error between network nodes and the
	network delay. These can create offsets between the batches and out-		network delay. These can create offsets between the batches and out-
	of-order of the packets. The mathematical formula on timing aspects,		of-order of the packets. The mathematical formula on timing aspects,
	explained in section 3.2 of [RFC8321], must be satisfied and it takes		explained in section 5 of [I-D.fioccola-rfc8321bis], must be
	into considerations the different causes of reordering such as clock		satisfied and it takes into considerations the different causes of
	error and network delay. The assumption is to define the available		reordering such as clock error and network delay. The assumption is
	counting interval where to get stable counters and to avoid these		to define the available counting interval where to get stable
	issues. Specifically, if the effects of network delay are ignored,		counters and to avoid these issues. Specifically, if the effects of
	the condition to implement the methodology is that the clocks in		network delay are ignored, the condition to implement the methodology
	different nodes MUST be synchronized to the same clock reference with		is that the clocks in different nodes MUST be synchronized to the
	an accuracy of +/- B/2 time units, where B is the fixed time duration		same clock reference with an accuracy of +/- B/2 time units, where B
	of the batch, which refers to the original marking interval at the		is the fixed time duration of the batch, which refers to the original
	source node considering that this interval could fluctuate along the		marking interval at the source node considering that this interval
	path. In this way each marked packet can be assigned to the right		could fluctuate along the path. In this way each marked packet can
	batch by each node. Usually the counters can be taken in the middle		be assigned to the right batch by each node. Usually the counters
	of the batch period to be sure to take still counters. In a few		can be taken in the middle of the batch period to be sure to take
	words this implies that the length of the batches MUST be chosen		still counters. In a few words this implies that the length of the
	large enough so that the method is not affected by those factors.		batches MUST be chosen large enough so that the method is not
	The length of the batches can be determined based on the specific		affected by those factors. The length of the batches can be
	deployment scenario.		determined based on the specific deployment scenario.
	L bit=1 ----------+ +-----------+ +----------		L bit=1 ----------+ +-----------+ +----------
	| | | |		| | | |
	L bit=0 +-----------+ +-----------+		L bit=0 +-----------+ +-----------+
	Batch n ... Batch 3 Batch 2 Batch 1		Batch n ... Batch 3 Batch 2 Batch 1
	<---------> <---------> <---------> <---------> <--------->		<---------> <---------> <---------> <---------> <--------->
	Traffic Flow		Traffic Flow
	===========================================================>		===========================================================>
	L bit ...1111111111 0000000000 11111111111 00000000000 111111111...		L bit ...1111111111 0000000000 11111111111 00000000000 111111111...
	skipping to change at page 15, line 39 ¶		skipping to change at page 15, line 46 ¶
	When all values in the FlowMonID space are consumed, the centralized		When all values in the FlowMonID space are consumed, the centralized
	controller can keep track and reassign the values that are not used		controller can keep track and reassign the values that are not used
	any more by old flows, while if the FlowMonID is pseudo randomly		any more by old flows, while if the FlowMonID is pseudo randomly
	generated by the source, conflicts and collisions are possible.		generated by the source, conflicts and collisions are possible.
	5.4. Multipoint and Clustered Alternate Marking		5.4. Multipoint and Clustered Alternate Marking
	The Alternate Marking method can also be extended to any kind of		The Alternate Marking method can also be extended to any kind of
	multipoint to multipoint paths, and the network clustering approach		multipoint to multipoint paths, and the network clustering approach
	allows a flexible and optimized performance measurement, as described		allows a flexible and optimized performance measurement, as described
	in [RFC8889].		in [I-D.fioccola-rfc8889bis].
	The Cluster is the smallest identifiable subnetwork of the entire		The Cluster is the smallest identifiable subnetwork of the entire
	Network graph that still satisfies the condition that the number of		Network graph that still satisfies the condition that the number of
	packets that goes in is the same that goes out. With network		packets that goes in is the same that goes out. With network
	clustering, it is possible to use the partition of the network into		clustering, it is possible to use the partition of the network into
	clusters at different levels in order to perform the needed degree of		clusters at different levels in order to perform the needed degree of
	detail. So, for Multipoint Alternate Marking, FlowMonID can identify		detail. So, for Multipoint Alternate Marking, FlowMonID can identify
	in general a multipoint-to-multipoint flow and not only a point-to-		in general a multipoint-to-multipoint flow and not only a point-to-
	point flow.		point flow.
	skipping to change at page 20, line 17 ¶		skipping to change at page 20, line 22 ¶
	The authors would like to thank Bob Hinden, Ole Troan, Martin Duke,		The authors would like to thank Bob Hinden, Ole Troan, Martin Duke,
	Lars Eggert, Roman Danyliw, Alvaro Retana, Eric Vyncke, Warren		Lars Eggert, Roman Danyliw, Alvaro Retana, Eric Vyncke, Warren
	Kumari, Benjamin Kaduk, Stewart Bryant, Christopher Wood, Yoshifumi		Kumari, Benjamin Kaduk, Stewart Bryant, Christopher Wood, Yoshifumi
	Nishida, Tom Herbert, Stefano Previdi, Brian Carpenter, Greg Mirsky,		Nishida, Tom Herbert, Stefano Previdi, Brian Carpenter, Greg Mirsky,
	Ron Bonica for the precious comments and suggestions.		Ron Bonica for the precious comments and suggestions.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
			[I-D.fioccola-rfc8321bis]
			Fioccola, G., Cociglio, M., Mirsky, G., Mizrahi, T., Zhou,
			T., and X. Min, "Alternate-Marking Method", draft-
			fioccola-rfc8321bis-03 (work in progress), February 2022.
			[I-D.fioccola-rfc8889bis]
			Fioccola, G., Cociglio, M., Sapio, A., Sisto, R., and T.
			Zhou, "Multipoint Alternate-Marking Method", draft-
			fioccola-rfc8889bis-03 (work in progress), February 2022.
	[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>.
	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,		(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017,		DOI 10.17487/RFC8200, July 2017,
	<https://www.rfc-editor.org/info/rfc8200>.		<https://www.rfc-editor.org/info/rfc8200>.
	9.2. Informative References		9.2. Informative References
	[I-D.chen-pce-pcep-ifit]		[I-D.chen-pce-pcep-ifit]
	Yuan, H., Zhou, T., Li, W., Fioccola, G., and Y. Wang,		Yuan, H., Zhou, T., Li, W., Fioccola, G., and Y. Wang,
	"Path Computation Element Communication Protocol (PCEP)		"Path Computation Element Communication Protocol (PCEP)
	Extensions to Enable IFIT", draft-chen-pce-pcep-ifit-04		Extensions to Enable IFIT", draft-chen-pce-pcep-ifit-06
	(work in progress), July 2021.		(work in progress), February 2022.
	[I-D.fz-spring-srv6-alt-mark]		[I-D.fz-spring-srv6-alt-mark]
	Fioccola, G., Zhou, T., and M. Cociglio, "Segment Routing		Fioccola, G., Zhou, T., and M. Cociglio, "Segment Routing
	Header encapsulation for Alternate Marking Method", draft-		Header encapsulation for Alternate Marking Method", draft-
	fz-spring-srv6-alt-mark-01 (work in progress), July 2021.		fz-spring-srv6-alt-mark-02 (work in progress), February
			2022.
	[I-D.hinden-6man-hbh-processing]		[I-D.hinden-6man-hbh-processing]
	Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options		Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
	Processing Procedures", draft-hinden-6man-hbh-		Processing Procedures", draft-hinden-6man-hbh-
	processing-01 (work in progress), June 2021.		processing-01 (work in progress), June 2021.
	[I-D.ietf-idr-sr-policy-ifit]		[I-D.ietf-idr-sr-policy-ifit]
	Qin, F., Yuan, H., Zhou, T., Fioccola, G., and Y. Wang,		Qin, F., Yuan, H., Zhou, T., Fioccola, G., and Y. Wang,
	"BGP SR Policy Extensions to Enable IFIT", draft-ietf-idr-		"BGP SR Policy Extensions to Enable IFIT", draft-ietf-idr-
	sr-policy-ifit-02 (work in progress), July 2021.		sr-policy-ifit-03 (work in progress), January 2022.
	[I-D.peng-v6ops-hbh]		[I-D.peng-v6ops-hbh]
	Peng, S., Li, Z., Xie, C., Qin, Z., and G. Mishra,		Peng, S., Li, Z., Xie, C., Qin, Z., and G. Mishra,
	"Processing of the Hop-by-Hop Options Header", draft-peng-		"Processing of the Hop-by-Hop Options Header", draft-peng-
	v6ops-hbh-06 (work in progress), August 2021.		v6ops-hbh-06 (work in progress), August 2021.
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, DOI 10.17487/RFC4291, February		Architecture", RFC 4291, DOI 10.17487/RFC4291, February
	2006, <https://www.rfc-editor.org/info/rfc4291>.		2006, <https://www.rfc-editor.org/info/rfc4291>.
	skipping to change at page 21, line 37 ¶		skipping to change at page 22, line 14 ¶
	[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing		[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
	of IPv6 Extension Headers", RFC 7045,		of IPv6 Extension Headers", RFC 7045,
	DOI 10.17487/RFC7045, December 2013,		DOI 10.17487/RFC7045, December 2013,
	<https://www.rfc-editor.org/info/rfc7045>.		<https://www.rfc-editor.org/info/rfc7045>.
	[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in		[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
	Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,		Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
	October 2014, <https://www.rfc-editor.org/info/rfc7384>.		October 2014, <https://www.rfc-editor.org/info/rfc7384>.
	[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
	L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
	"Alternate-Marking Method for Passive and Hybrid
	Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
	January 2018, <https://www.rfc-editor.org/info/rfc8321>.
	[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,		[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
	Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header		Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
	(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,		(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
	<https://www.rfc-editor.org/info/rfc8754>.		<https://www.rfc-editor.org/info/rfc8754>.
	[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet		[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
	Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,		Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
	<https://www.rfc-editor.org/info/rfc8799>.		<https://www.rfc-editor.org/info/rfc8799>.
	[RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto,
	"Multipoint Alternate-Marking Method for Passive and
	Hybrid Performance Monitoring", RFC 8889,
	DOI 10.17487/RFC8889, August 2020,
	<https://www.rfc-editor.org/info/rfc8889>.
	[RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.		[RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
	Sundblad, "Network Time Security for the Network Time		Sundblad, "Network Time Security for the Network Time
	Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,		Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
	<https://www.rfc-editor.org/info/rfc8915>.		<https://www.rfc-editor.org/info/rfc8915>.
	Authors' Addresses		Authors' Addresses
	Giuseppe Fioccola		Giuseppe Fioccola
	Huawei		Huawei
	Riesstrasse, 25		Riesstrasse, 25
End of changes. 19 change blocks.
	74 lines changed or deleted		75 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/