< draft-mirsky-ippm-hybrid-two-step-09.txt		draft-mirsky-ippm-hybrid-two-step-10.txt >
	IPPM Working Group G. Mirsky		IPPM Working Group G. Mirsky
	Internet-Draft ZTE Corp.		Internet-Draft ZTE Corp.
	Intended status: Standards Track W. Lingqiang		Intended status: Standards Track W. Lingqiang
	Expires: 1 October 2021 G. Zhui		Expires: 18 November 2021 G. Zhui
	ZTE Corporation		ZTE Corporation
	H. Song		H. Song
	Futurewei Technologies		Futurewei Technologies
	30 March 2021		17 May 2021
	Hybrid Two-Step Performance Measurement Method		Hybrid Two-Step Performance Measurement Method
	draft-mirsky-ippm-hybrid-two-step-09		draft-mirsky-ippm-hybrid-two-step-10
	Abstract		Abstract
	Development of, and advancements in, automation of network operations		Development of, and advancements in, automation of network operations
	brought new requirements for measurement methodology. Among them is		brought new requirements for measurement methodology. Among them is
	the ability to collect instant network state as the packet being		the ability to collect instant network state as the packet being
	processed by the networking elements along its path through the		processed by the networking elements along its path through the
	domain. This document introduces a new hybrid measurement method,		domain. This document introduces a new hybrid measurement method,
	referred to as hybrid two-step, as it separates the act of measuring		referred to as hybrid two-step, as it separates the act of measuring
	and/or calculating the performance metric from the act of collecting		and/or calculating the performance metric from the act of collecting
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 1 October 2021.		This Internet-Draft will expire on 18 November 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 (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 5, line 49 ¶		skipping to change at page 5, line 49 ¶
	HTS Trigger. The nature of the HTS Trigger is a transport network		HTS Trigger. The nature of the HTS Trigger is a transport network
	layer-specific, and its description is outside the scope of this		layer-specific, and its description is outside the scope of this
	document. The packet that includes the HTS Trigger in this document		document. The packet that includes the HTS Trigger in this document
	is also referred to as the trigger packet.		is also referred to as the trigger packet.
	The HTS method uses the HTS Follow-up packet, referred to as the		The HTS method uses the HTS Follow-up packet, referred to as the
	follow-up packet, to collect measurement and network state data from		follow-up packet, to collect measurement and network state data from
	the nodes. The node that creates the HTS Trigger also generates the		the nodes. The node that creates the HTS Trigger also generates the
	HTS Follow-up packet. The follow-up packet contains characteristic		HTS Follow-up packet. The follow-up packet contains characteristic
	information, copied from the trigger packet, sufficient for		information, copied from the trigger packet, sufficient for
	participating HTS nodes to associate it with the original packet.		participating HTS nodes to associate it with the original packet. As
	The exact composition of the characteristic information is specific		the follow-up packet is expected to traverse the same sequence of
	for each transport network, and its definition is outside the scope		nodes, one element of the characteristic information is the
	of this document. The follow-up packet also uses the same		information that determines the path in the data plane. For example,
	encapsulation as the data packet. If not payload but only network		in a segment routing domain [RFC8402], a list of segment identifiers
	information used to load-balance flows in equal cost multipath		of the trigger packet is applied to the follow-up packet. And in the
	(ECMP), use of the network encapsulation identical to the trigger		case of the service function chain based on the Network Service
	packet should guarantee that the follow-up packet remains in-band,		Header [RFC8300], the Base Header and Service Path Header of the
	i.e., traverses the same set of network elements, with the original		trigger packet will be applied to the follow-up packet. Also, when
	data packet with the HTS Trigger. Only one outstanding follow-up		HTS is used to collect the telemetry information in an IOAM domain,
	packet MUST be on the node for the given path. That means that if		the IOAM trace option header [I-D.ietf-ippm-ioam-data] of the trigger
	the node receives an HTS Trigger for the flow on which it still waits		packet is applied in the follow-up packet. The follow-up packet also
	for the follow-up packet to the previous HTS Trigger, the node will		uses the same network information used to load-balance flows in
	originate the follow-up packet to transport the former set of the		equal-cost multipath (ECMP) as the trigger packet, e.g., IPv6 Flow
	network state data and transmit it before it sends the follow-up		Label [RFC6437] or an entropy label [RFC6790]. The exact composition
	packet with the latest collection of network state information.		of the characteristic information is specific for each transport
			network, and its definition is outside the scope of this document.
			Only one outstanding follow-up packet MUST be on the node for the
			given path. That means that if the node receives an HTS Trigger for
			the flow on which it still waits for the follow-up packet to the
			previous HTS Trigger, the node will originate the follow-up packet to
			transport the former set of the network state data and transmit it
			before it sends the follow-up packet with the latest collection of
			network state information.
	4.1. Operation of the HTS Ingress Node		4.1. Operation of the HTS Ingress Node
	A node that originates the HTS Trigger is referred to as the HTS		A node that originates the HTS Trigger is referred to as the HTS
	ingress node. As stated, the ingress node originates the follow-up		ingress node. As stated, the ingress node originates the follow-up
	packet. The follow-up packet has the transport network encapsulation		packet. The follow-up packet has the transport network encapsulation
	identical with the trigger packet followed by the HTS shim and one or		identical with the trigger packet followed by the HTS shim and one or
	more telemetry information elements encoded as Type-Length-Value		more telemetry information elements encoded as Type-Length-Value
	{TLV}. Figure 1 displays an example of the follow-up packet format.		{TLV}. Figure 1 displays an example of the follow-up packet format.
	skipping to change at page 16, line 48 ¶		skipping to change at page 16, line 48 ¶
	based-telemetry-09>.		based-telemetry-09>.
	[P4.INT] "In-band Network Telemetry (INT)", P4.org Specification,		[P4.INT] "In-band Network Telemetry (INT)", P4.org Specification,
	October 2017.		October 2017.
	[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-		[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
	384, and HMAC-SHA-512 with IPsec", RFC 4868,		384, and HMAC-SHA-512 with IPsec", RFC 4868,
	DOI 10.17487/RFC4868, May 2007,		DOI 10.17487/RFC4868, May 2007,
	<https://www.rfc-editor.org/info/rfc4868>.		<https://www.rfc-editor.org/info/rfc4868>.
			[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
			"IPv6 Flow Label Specification", RFC 6437,
			DOI 10.17487/RFC6437, November 2011,
			<https://www.rfc-editor.org/info/rfc6437>.
			[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
			L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
			RFC 6790, DOI 10.17487/RFC6790, November 2012,
			<https://www.rfc-editor.org/info/rfc6790>.
	[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with		[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
	Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,		Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
	May 2016, <https://www.rfc-editor.org/info/rfc7799>.		May 2016, <https://www.rfc-editor.org/info/rfc7799>.
	[RFC8169] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S.,		[RFC8169] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S.,
	and A. Vainshtein, "Residence Time Measurement in MPLS		and A. Vainshtein, "Residence Time Measurement in MPLS
	Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017,		Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017,
	<https://www.rfc-editor.org/info/rfc8169>.		<https://www.rfc-editor.org/info/rfc8169>.
	[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,		[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
	Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation		Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
	for Bit Index Explicit Replication (BIER) in MPLS and Non-		for Bit Index Explicit Replication (BIER) in MPLS and Non-
	MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January		MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
	2018, <https://www.rfc-editor.org/info/rfc8296>.		2018, <https://www.rfc-editor.org/info/rfc8296>.
			[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
			"Network Service Header (NSH)", RFC 8300,
			DOI 10.17487/RFC8300, January 2018,
			<https://www.rfc-editor.org/info/rfc8300>.
	[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,		[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
	L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,		L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
	"Alternate-Marking Method for Passive and Hybrid		"Alternate-Marking Method for Passive and Hybrid
	Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,		Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
	January 2018, <https://www.rfc-editor.org/info/rfc8321>.		January 2018, <https://www.rfc-editor.org/info/rfc8321>.
			[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
			Decraene, B., Litkowski, S., and R. Shakir, "Segment
			Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
			July 2018, <https://www.rfc-editor.org/info/rfc8402>.
	Authors' Addresses		Authors' Addresses
	Greg Mirsky		Greg Mirsky
	ZTE Corp.		ZTE Corp.
	Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com		Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com
	Wang Lingqiang		Wang Lingqiang
	ZTE Corporation		ZTE Corporation
	No 19 ,East Huayuan Road		No 19 ,East Huayuan Road
	Beijing		Beijing
	Phone: +86 10 82963945		Phone: +86 10 82963945
	Email: wang.lingqiang@zte.com.cn		Email: wang.lingqiang@zte.com.cn
	Guo Zhui		Guo Zhui
	ZTE Corporation		ZTE Corporation
End of changes. 9 change blocks.
	21 lines changed or deleted		49 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/