< draft-ietf-ippm-ioam-direct-export-05.txt		draft-ietf-ippm-ioam-direct-export-06.txt >
	IPPM H. Song		IPPM H. Song
	Internet-Draft Futurewei		Internet-Draft Futurewei
	Intended status: Standards Track B. Gafni		Intended status: Standards Track B. Gafni
	Expires: January 13, 2022 Nvidia		Expires: February 9, 2022 Nvidia
	T. Zhou		T. Zhou
	Z. Li		Z. Li
	Huawei		Huawei
	F. Brockners		F. Brockners
	Cisco		Cisco
	S. Bhandari, Ed.		S. Bhandari, Ed.
	Thoughtspot		Thoughtspot
	R. Sivakolundu		R. Sivakolundu
	Cisco		Cisco
	T. Mizrahi, Ed.		T. Mizrahi, Ed.
	Huawei		Huawei
	July 12, 2021		August 8, 2021
	In-situ OAM Direct Exporting		In-situ OAM Direct Exporting
	draft-ietf-ippm-ioam-direct-export-05		draft-ietf-ippm-ioam-direct-export-06
	Abstract		Abstract
	In-situ Operations, Administration, and Maintenance (IOAM) is used		In-situ Operations, Administration, and Maintenance (IOAM) is used
	for recording and collecting operational and telemetry information.		for recording and collecting operational and telemetry information.
	Specifically, IOAM allows telemetry data to be pushed into data		Specifically, IOAM allows telemetry data to be pushed into data
	packets while they traverse the network. This document introduces a		packets while they traverse the network. This document introduces a
	new IOAM option type called the Direct Export (DEX) option, which is		new IOAM option type called the Direct Export (DEX) option, which is
	used as a trigger for IOAM data to be directly exported or locally		used as a trigger for IOAM data to be directly exported or locally
	aggregated without being pushed into in-flight data packets. The		aggregated without being pushed into in-flight data packets. The
	skipping to change at page 1, line 49 ¶		skipping to change at page 1, line 49 ¶
	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 January 13, 2022.		This Internet-Draft will expire on February 9, 2022.
	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 31 ¶		skipping to change at page 2, line 31 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Requirement Language . . . . . . . . . . . . . . . . . . 3		2.1. Requirement Language . . . . . . . . . . . . . . . . . . 3
	2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	3. The Direct Exporting (DEX) IOAM Option Type . . . . . . . . . 3		3. The Direct Exporting (DEX) IOAM Option Type . . . . . . . . . 3
	3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3		3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1.1. DEX Packet Selection . . . . . . . . . . . . . . . . 5		3.1.1. DEX Packet Selection . . . . . . . . . . . . . . . . 5
	3.1.2. Responding to the DEX Trigger . . . . . . . . . . . . 5		3.1.2. Responding to the DEX Trigger . . . . . . . . . . . . 5
	3.2. The DEX Option Format . . . . . . . . . . . . . . . . . . 6		3.2. The DEX Option Format . . . . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	4.1. IOAM Type . . . . . . . . . . . . . . . . . . . . . . . . 7		4.1. IOAM Type . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.2. IOAM DEX Flags . . . . . . . . . . . . . . . . . . . . . 8		4.2. IOAM DEX Flags . . . . . . . . . . . . . . . . . . . . . 8
	5. Performance Considerations . . . . . . . . . . . . . . . . . 8		4.3. IOAM DEX Extension-Flags . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Performance Considerations . . . . . . . . . . . . . . . . . 9
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	7.1. Normative References . . . . . . . . . . . . . . . . . . 9		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.2. Informative References . . . . . . . . . . . . . . . . . 10		7.1. Normative References . . . . . . . . . . . . . . . . . . 10
	Appendix A. Hop Limit and Hop Count in Direct Exporting . . . . 10		7.2. Informative References . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Appendix A. Hop Limit in Direct Exporting . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	IOAM [I-D.ietf-ippm-ioam-data] is used for monitoring traffic in the		IOAM [I-D.ietf-ippm-ioam-data] is used for monitoring traffic in the
	network, and for incorporating IOAM data fields into in-flight data		network, and for incorporating IOAM data fields into in-flight data
	packets.		packets.
	IOAM makes use of four possible IOAM options, defined in		IOAM makes use of four possible IOAM options, defined in
	[I-D.ietf-ippm-ioam-data]: Pre-allocated Trace Option, Incremental		[I-D.ietf-ippm-ioam-data]: Pre-allocated Trace Option, Incremental
	Trace Option, Proof of Transit (POT) Option, and Edge-to-Edge Option.		Trace Option, Proof of Transit (POT) Option, and Edge-to-Edge Option.
	skipping to change at page 6, line 26 ¶		skipping to change at page 6, line 26 ¶
	to prevent nested exporting and/or exporting loops.		to prevent nested exporting and/or exporting loops.
	A transit IOAM node that does not support the DEX option SHOULD		A transit IOAM node that does not support the DEX option SHOULD
	ignore it. A decapsulating node that does not support the DEX option		ignore it. A decapsulating node that does not support the DEX option
	MUST remove it, along with any other IOAM options carried in the		MUST remove it, along with any other IOAM options carried in the
	packet if such exist.		packet if such exist.
	3.2. The DEX Option Format		3.2. The DEX Option Format
	The format of the DEX option is depicted in Figure 2. The length of		The format of the DEX option is depicted in Figure 2. The length of
	the DEX option is either 8 octets or 16 octets, as the Flow ID and		the DEX option is at least 8 octets. The DEX option MAY include one
	the Sequence Number fields (summing up to 8 octets) are optional. It		or more optional fields. The existence of the optional fields is
	is assumed that the lower layer protocol indicates the length of the		indicated by the corresponding flags in the Extension-Flags field.
	DEX option, thus indicating whether the two optional fields are		Two optional fields are defined in this document, the Flow ID and the
	present.		Sequence Number fields. Every optional field MUST be exactly 4
			octets long. Thus, the Extension-Flags field explicitly indicates
			the length of the DEX option. Defining a new optional field requires
			an allocation of a corresponding flag in the Extension-Flags field,
			as specified in Section 4.2.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Namespace-ID | Flags |		| Namespace-ID | Flags |Extension-Flags|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IOAM-Trace-Type | Reserved |		| IOAM-Trace-Type | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flow ID (optional) |		| Flow ID (optional) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence Number (Optional) |		| Sequence Number (Optional) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: DEX Option Format		Figure 2: DEX Option Format
	Namespace-ID A 16-bit identifier of the IOAM namespace, as defined		Namespace-ID A 16-bit identifier of the IOAM namespace, as defined
	in [I-D.ietf-ippm-ioam-data].		in [I-D.ietf-ippm-ioam-data].
	Flags A 16-bit field, comprised of 16 one-bit subfields.		Flags An 8-bit field, comprised of 8 one-bit subfields.
	Flags are allocated by IANA, as defined in		Flags are allocated by IANA, as defined in
	Section 4.2.		Section 4.2.
			Extension-Flags An 8-bit field, comprised of 8 one-bit subfields.
			Extension-Flags are allocated by IANA, as defined in
			Section 4.3. Every bit in the Extension-Flag field
			that is set to 1 indicates the existence of a
			corresponding optional 4-octet field. An IOAM node
			that receives a DEX option with an unknown flag set
			to 1 MUST ignore the corresponding optional field.
	IOAM-Trace-Type A 24-bit identifier which specifies which data fields		IOAM-Trace-Type A 24-bit identifier which specifies which data fields
	should be exported. The format of this field is as		should be exported. The format of this field is as
	defined in [I-D.ietf-ippm-ioam-data]. Specifically,		defined in [I-D.ietf-ippm-ioam-data]. Specifically,
	bit 23, which corresponds to the Checksum Complement		the bit that corresponds to the Checksum Complement
	data field, should be assigned to be zero by the IOAM		data field should be assigned to be zero by the IOAM
	encapsulating node, and ignored by transit and		encapsulating node, and ignored by transit and
	decapsulating nodes. The reason for this is that the		decapsulating nodes. The reason for this is that the
	Checksum Complement is intended for in-flight packet		Checksum Complement is intended for in-flight packet
	modifications and is not relevant for direct		modifications and is not relevant for direct
	exporting.		exporting.
	Reserved This field SHOULD be ignored by the receiver.		Reserved This field SHOULD be ignored by the receiver.
	Flow ID A 32-bit flow identifier. If the actual Flow ID is		Optional fields The optional fields, if present, reside after the
	shorter than 32 bits, it is zero padded in its most		Reserved field. The order of the optional fields is
	significant bits. The field is set at the		according to the respective bits that are enabled in
	encapsulating node. The Flow ID can be uniformly		the Extension-Flags field. Each optional field is 4
	assigned by a central controller or algorithmically		octets long.
	generated by the encapsulating node. The latter
	approach cannot guarantee the uniqueness of Flow ID,
	yet the conflict probability is small due to the
	large Flow ID space. The Flow ID can be used to
	correlate the exported data of the same flow from
	multiple nodes and from multiple packets.
	Sequence Number A 32-bit sequence number starting from 0 and		Flow ID An optional 32-bit field representing the flow
	increasing by 1 for each following monitored packet		identifier. If the actual Flow ID is shorter than 32
	from the same flow at the encapsulating node. The		bits, it is zero padded in its most significant bits.
	Sequence Number, when combined with the Flow ID,		The field is set at the encapsulating node. The Flow
			ID can be uniformly assigned by a central controller
			or algorithmically generated by the encapsulating
			node. The latter approach cannot guarantee the
			uniqueness of Flow ID, yet the conflict probability
			is small due to the large Flow ID space. The Flow ID
			can be used to correlate the exported data of the
			same flow from multiple nodes and from multiple
			packets.
			Sequence Number An optional 32-bit sequence number starting from 0
			and increasing by 1 for each following monitored
			packet from the same flow at the encapsulating node.
			The Sequence Number, when combined with the Flow ID,
	provides a convenient approach to correlate the		provides a convenient approach to correlate the
	exported data from the same user packet.		exported data from the same user packet.
	4. IANA Considerations		4. IANA Considerations
	4.1. IOAM Type		4.1. IOAM Type
	The "IOAM Type Registry" was defined in Section 7.2 of		The "IOAM Type Registry" was defined in Section 7.2 of
	[I-D.ietf-ippm-ioam-data]. IANA is requested to allocate the		[I-D.ietf-ippm-ioam-data]. IANA is requested to allocate the
	following code point from the "IOAM Type Registry" as follows:		following code point from the "IOAM Type Registry" as follows:
	TBD-type IOAM Direct Export (DEX) Option Type		TBD-type IOAM Direct Export (DEX) Option Type
	If possible, IANA is requested to allocate code point 4 (TBD-type).		If possible, IANA is requested to allocate code point 4 (TBD-type).
	4.2. IOAM DEX Flags		4.2. IOAM DEX Flags
	IANA is requested to define an "IOAM DEX Flags" registry. This		IANA is requested to define an "IOAM DEX Flags" registry. This
	registry includes 16 flag bits. Allocation should be performed based		registry includes 8 flag bits. Allocation is based on the "RFC
	on the "RFC Required" procedure, as defined in [RFC8126].		Required" procedure, as defined in [RFC8126].
			New registration requests MUST use the following template:
			Bit: Desired bit to be allocated in the 8 bit Flags field of the DEX
			option.
			Description: Brief description of the newly registered bit.
			Reference: Reference to the document that defines the new bit.
			4.3. IOAM DEX Extension-Flags
			IANA is requested to define an "IOAM DEX Extension-Flags" registry.
			This registry includes 8 flag bits. Bit 0 (the most significant bit)
			and bit 1 in the registry are allocated by this document, and
			described in Section 3.2. Allocation of the other bits should be
			performed based on the "RFC Required" procedure, as defined in
			[RFC8126].
			Bit 0 "Flow ID [RFC XXXX] [RFC Editor: please replace with the RFC
			number of the current document]"
			Bit 1 "Sequence Number [RFC XXXX] [RFC Editor: please replace with
			the RFC number of the current document]"
			New registration requests MUST use the following template:
			Bit: Desired bit to be allocated in the 8 bit Extension-Flags field
			of the DEX option.
			Description: Brief description of the newly registered bit.
			Reference: Reference to the document that defines the new bit.
	5. Performance Considerations		5. Performance Considerations
	The DEX option triggers IOAM data to be collected and/or exported		The DEX option triggers IOAM data to be collected and/or exported
	packets to be exported to a receiving entity (or entities). In some		packets to be exported to a receiving entity (or entities). In some
	cases this may impact the receiving entity's performance, or the		cases this may impact the receiving entity's performance, or the
	performance along the paths leading to it.		performance along the paths leading to it.
	Therefore, the performance impact of these exported packets is		Therefore, the performance impact of these exported packets is
	limited by taking two measures: at the encapsulating nodes, by		limited by taking two measures: at the encapsulating nodes, by
	skipping to change at page 9, line 39 ¶		skipping to change at page 10, line 42 ¶
	thus limiting the scope of the threats above and their affect. This		thus limiting the scope of the threats above and their affect. This
	is a fundamental assumption with respect to the security aspects of		is a fundamental assumption with respect to the security aspects of
	IOAM, as further discussed in [I-D.ietf-ippm-ioam-data].		IOAM, as further discussed in [I-D.ietf-ippm-ioam-data].
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ietf-ippm-ioam-data]		[I-D.ietf-ippm-ioam-data]
	Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields		Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
	for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in		for In-situ OAM", draft-ietf-ippm-ioam-data-14 (work in
	progress), February 2021.		progress), June 2021.
	[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>.
	[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F.		[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F.
	Raspall, "Sampling and Filtering Techniques for IP Packet		Raspall, "Sampling and Filtering Techniques for IP Packet
	Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009,		Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009,
	<https://www.rfc-editor.org/info/rfc5475>.		<https://www.rfc-editor.org/info/rfc5475>.
	skipping to change at page 10, line 18 ¶		skipping to change at page 11, line 23 ¶
	[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>.
	7.2. Informative References		7.2. Informative References
	[I-D.ietf-ippm-ioam-flags]		[I-D.ietf-ippm-ioam-flags]
	Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R.,		Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R.,
	Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J.		Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J.
	Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-04		Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-05
	(work in progress), February 2021.		(work in progress), July 2021.
	[I-D.song-ippm-postcard-based-telemetry]		[I-D.song-ippm-postcard-based-telemetry]
	Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou,		Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou,
	T., Li, Z., Shin, J., and K. Lee, "Postcard-based On-Path		T., Li, Z., Shin, J., and K. Lee, "Postcard-based On-Path
	Flow Data Telemetry using Packet Marking", draft-song-		Flow Data Telemetry using Packet Marking", draft-song-
	ippm-postcard-based-telemetry-09 (work in progress),		ippm-postcard-based-telemetry-10 (work in progress), July
	February 2021.		2021.
	[I-D.spiegel-ippm-ioam-rawexport]		[I-D.spiegel-ippm-ioam-rawexport]
	Spiegel, M., Brockners, F., Bhandari, S., and R.		Spiegel, M., Brockners, F., Bhandari, S., and R.
	Sivakolundu, "In-situ OAM raw data export with IPFIX",		Sivakolundu, "In-situ OAM raw data export with IPFIX",
	draft-spiegel-ippm-ioam-rawexport-04 (work in progress),		draft-spiegel-ippm-ioam-rawexport-05 (work in progress),
	November 2020.		July 2021.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	Appendix A. Hop Limit and Hop Count in Direct Exporting		Appendix A. Hop Limit in Direct Exporting
	In order to help correlate and order the exported packets, it is		In order to help correlate and order the exported packets, it is
	possible to include the Hop_Lim/Node_ID data field in exported		possible to include the Hop_Lim/Node_ID data field in exported
	packets; if the IOAM-Trace-Type [I-D.ietf-ippm-ioam-data] has the		packets; if the IOAM-Trace-Type [I-D.ietf-ippm-ioam-data] has the
	Hop_Lim/Node_ID bit set, then exported packets include the Hop_Lim/		Hop_Lim/Node_ID bit set, then exported packets include the Hop_Lim/
	Node_ID data field, which contains the TTL/Hop Limit value from a		Node_ID data field, which contains the TTL/Hop Limit value from a
	lower layer protocol.		lower layer protocol.
	An alternative approach was considered during the design of this		An alternative approach was considered during the design of this
	document, according to which a 1-octet Hop Count field would be		document, according to which a 1-octet Hop Count field would be
	included in the DEX header (presumably by claiming some space from		included in the DEX header (presumably by claiming some space from
	the Flags field). The Hop Limit would starts from 0 at the		the Flags field). The Hop Limit would starts from 0 at the
	encapsulating node and be incremented by each IOAM transit node that		encapsulating node and be incremented by each IOAM transit node that
	supports the DEX option. In this approach the Hop Count field value		supports the DEX option. In this approach the Hop Count field value
	would also be included in the exported packet.		would also be included in the exported packet.
	The main advantage of the Hop_Lim/Node_ID approach is that it
	provides information about the current hop count without requiring
	each transit node to modify the DEX option, thus simplifying the data
	plane functionality of Direct Exporting. The main advantage of the
	Hop Count approach that was considered is that it counts the number
	of IOAM-capable nodes without relying on the lower layer TTL,
	especially when the lower layer cannot prvide the accurate TTL
	information, e.g., Layer 2 Ethernet or hierarchical VPN. The Hop
	Count approach would also explicitly allow to detect a case where an
	IOAM-capable node fails to export packets. It would also be possible
	to use a flag to indicate an optional Hop Count field, which enables
	to control the tradeoff. On one hand it would address the use cases
	that the Hop_Lim/Node_ID cannot cover, and on the other hand it would
	not require transit switches to update the option if it was not
	supported or disabled. For the sake of simplicity the Hop Count
	approach was not pursued, and this field is not incorporated in the
	DEX header.
	Authors' Addresses		Authors' Addresses
	Haoyu Song		Haoyu Song
	Futurewei		Futurewei
	2330 Central Expressway		2330 Central Expressway
	Santa Clara 95050		Santa Clara 95050
	USA		USA
	Email: haoyu.song@futurewei.com		Email: haoyu.song@futurewei.com
End of changes. 20 change blocks.
	66 lines changed or deleted		101 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/