< draft-ietf-ippm-ioam-direct-export-01.txt		draft-ietf-ippm-ioam-direct-export-02.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: February 6, 2021 Mellanox Technologies, Inc.		Expires: May 5, 2021 Mellanox Technologies, Inc.
	T. Zhou		T. Zhou
	Z. Li		Z. Li
	Huawei		Huawei
	F. Brockners		F. Brockners
	S. Bhandari		S. Bhandari
	R. Sivakolundu		R. Sivakolundu
	Cisco		Cisco
	T. Mizrahi, Ed.		T. Mizrahi, Ed.
	Huawei Smart Platforms iLab		Huawei Smart Platforms iLab
	August 5, 2020		November 1, 2020
	In-situ OAM Direct Exporting		In-situ OAM Direct Exporting
	draft-ietf-ippm-ioam-direct-export-01		draft-ietf-ippm-ioam-direct-export-02
	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 without being		used as a trigger for IOAM data to be directly exported without being
	pushed into in-flight data packets.		pushed into in-flight data packets.
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 February 6, 2021.		This Internet-Draft will expire on May 5, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 34 ¶		skipping to change at page 2, line 34 ¶
	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.2. The DEX Option Format . . . . . . . . . . . . . . . . . . 5		3.2. The DEX Option Format . . . . . . . . . . . . . . . . . . 5
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	4.1. IOAM Type . . . . . . . . . . . . . . . . . . . . . . . . 6		4.1. IOAM Type . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.2. IOAM DEX Flags . . . . . . . . . . . . . . . . . . . . . 6		4.2. IOAM DEX Flags . . . . . . . . . . . . . . . . . . . . . 6
	5. Performance Considerations . . . . . . . . . . . . . . . . . 6		5. Performance Considerations . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7. Topics for Further Discussion . . . . . . . . . . . . . . . . 7		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		7.1. Normative References . . . . . . . . . . . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . 8		7.2. Informative References . . . . . . . . . . . . . . . . . 8
	8.2. Informative References . . . . . . . . . . . . . . . . . 8		Appendix A. Hop Limit and Hop Count in Direct Exporting . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	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
	skipping to change at page 7, line 37 ¶		skipping to change at page 7, line 37 ¶
	In order to mitigate the attacks described above, it should be		In order to mitigate the attacks described above, it should be
	possible for IOAM-enabled devices to limit the exported IOAM data to		possible for IOAM-enabled devices to limit the exported IOAM data to
	a configurable rate.		a configurable rate.
	IOAM is assumed to be deployed in a restricted administrative domain,		IOAM is assumed to be deployed in a restricted administrative domain,
	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. Topics for Further Discussion		7. References
	o Hop Limit / Hop Count: in order to help correlate and order the
	exported packets, it is possible to include a 1-octet Hop Count
	field in the DEX header (presumably by claiming some space from
	the Flags field). Its value starts from 0 at the encapsulating
	node and is incremented by each IOAM transit node that supports
	the DEX option. The Hop Count field value is also included in the
	exported packet. An alternative approach is to use the Hop_Lim/
	Node_ID data field; 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/Node_ID data field, which
	contains the TTL/Hop Limit value from a lower layer protocol. 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 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. It also explicitly
	allows to detect a case where an IOAM-capable node fails to export
	packets. In order to facilitate the Hop Count approach it is
	possible to use a flag to indicate an optional Hop Count field,
	which enables to control the tradeoff. On one hand it addresses
	the use cases that the Hop_Lim/Node_ID cannot cover, and on the
	other hand it does not require transit switches to update the
	option if it is not supported or disabled. Further discussion is
	required about the tradeoff between the two alternatives.
	8. References
	8.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-10 (work in		for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in
	progress), July 2020.		progress), July 2020.
	[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>.
	8.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-02		Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-03
	(work in progress), July 2020.		(work in progress), October 2020.
	[I-D.song-ippm-postcard-based-telemetry]		[I-D.song-ippm-postcard-based-telemetry]
	Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee,		Song, H., Zhou, T., Li, Z., Mirsky, G., Shin, J., and K.
	"Postcard-based On-Path Flow Data Telemetry", draft-song-		Lee, "Postcard-based On-Path Flow Data Telemetry using
	ippm-postcard-based-telemetry-07 (work in progress), April		Packet Marking", draft-song-ippm-postcard-based-
	2020.		telemetry-08 (work in progress), October 2020.
	[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-03 (work in progress),		draft-spiegel-ippm-ioam-rawexport-03 (work in progress),
	March 2020.		March 2020.
	[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
			In order to help correlate and order the exported packets, it is
			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
			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
			lower layer protocol.
			An alternative approach was considered during the design of this
			document, according to which a 1-octet Hop Count field would be
			included in the DEX header (presumably by claiming some space from
			the Flags field). The Hop Limit would starts from 0 at the
			encapsulating node and be incremented by each IOAM transit node that
			supports the DEX option. In this approach the Hop Count field value
			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@huawei.com		Email: haoyu.song@huawei.com
End of changes. 11 change blocks.
	47 lines changed or deleted		52 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/