draft-ietf-ippm-ioam-flags-06.txt		draft-ietf-ippm-ioam-flags-07.txt
	IPPM T. Mizrahi		IPPM T. Mizrahi
	Internet-Draft Huawei		Internet-Draft Huawei
	Intended status: Standards Track F. Brockners		Intended status: Standards Track F. Brockners
	Expires: March 1, 2022 Cisco		Expires: April 16, 2022 Cisco
	S. Bhandari, Ed.		S. Bhandari, Ed.
	Thoughtspot		Thoughtspot
	R. Sivakolundu		R. Sivakolundu
	C. Pignataro		C. Pignataro
	Cisco		Cisco
	A. Kfir		A. Kfir
	B. Gafni		B. Gafni
	Nvidia		Nvidia
	M. Spiegel		M. Spiegel
	Barefoot Networks		Barefoot Networks, an Intel company
	J. Lemon		J. Lemon
	Broadcom		Broadcom
	August 28, 2021		October 13, 2021
	In-situ OAM Loopback and Active Flags		In-situ OAM Loopback and Active Flags
	draft-ietf-ippm-ioam-flags-06		draft-ietf-ippm-ioam-flags-07
	Abstract		Abstract
	In-situ Operations, Administration, and Maintenance (IOAM) records		In-situ Operations, Administration, and Maintenance (IOAM) collects
	operational and telemetry information in packets while they traverse		operational and telemetry information in packets while they traverse
	a path between two points in the network. This document defines two		a path between two points in the network. This document defines two
	new flags in the IOAM Trace Option headers, specifically the the		new flags in the IOAM Trace Option headers, specifically the Loopback
	Loopback and Active flags.		and Active flags.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 March 1, 2022.		This Internet-Draft will expire on April 16, 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 30 ¶		skipping to change at page 2, line 30 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	3. New IOAM Trace Option Flags . . . . . . . . . . . . . . . . . 3		3. New IOAM Trace Option Flags . . . . . . . . . . . . . . . . . 3
	4. Loopback in IOAM . . . . . . . . . . . . . . . . . . . . . . 3		4. Loopback in IOAM . . . . . . . . . . . . . . . . . . . . . . 3
	4.1. Loopback: Encapsulating Node Functionality . . . . . . . 4		4.1. Loopback: Encapsulating Node Functionality . . . . . . . 4
	4.1.1. Loopback Packet Selection . . . . . . . . . . . . . . 5		4.1.1. Loopback Packet Selection . . . . . . . . . . . . . . 5
	4.2. Receiving and Processing Loopback . . . . . . . . . . . . 5		4.2. Receiving and Processing Loopback . . . . . . . . . . . . 6
	4.3. Loopback on the Return Path . . . . . . . . . . . . . . . 6		4.3. Loopback on the Return Path . . . . . . . . . . . . . . . 7
	4.4. Terminating a Looped Back Packet . . . . . . . . . . . . 6		4.4. Terminating a Looped Back Packet . . . . . . . . . . . . 7
	5. Active Measurement with IOAM . . . . . . . . . . . . . . . . 7		5. Active Measurement with IOAM . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7. Performance Considerations . . . . . . . . . . . . . . . . . 9		7. Performance Considerations . . . . . . . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 9		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . 11		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9.2. Informative References . . . . . . . . . . . . . . . . . 11		10.1. Normative References . . . . . . . . . . . . . . . . . . 11
			10.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		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 by incorporating IOAM data fields into in-flight data		network by incorporating IOAM data fields into in-flight data
	packets.		packets.
	IOAM data may be represented in one of four possible IOAM options:		IOAM data may be represented in one of four possible IOAM options:
	Pre-allocated Trace Option, Incremental Trace Option, Proof of		Pre-allocated Trace Option, Incremental Trace Option, Proof of
	Transit (POT) Option, and Edge-to-Edge Option. This document defines		Transit (POT) Option, and Edge-to-Edge Option. This document defines
	two new flags in the Pre-allocated and Incremental Trace options: the		two new flags in the Pre-allocated and Incremental Trace options: the
	Loopback and Active flags.		Loopback and Active flags.
			The Loopback flag is used to request that each transit device along
			the path loops back a truncated copy of the data packet to the
			sender. The Active flag indicates that a packet is used for active
			measurement. The term active measurement in the context of this
			document is as defined in [RFC7799].
	2. Conventions		2. Conventions
	2.1. Requirements Language		2.1. 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.
	skipping to change at page 3, line 41 ¶		skipping to change at page 3, line 49 ¶
	Bit 2 "Active" (A-bit). When set, the Active flag indicates that a		Bit 2 "Active" (A-bit). When set, the Active flag indicates that a
	packet is an active measurement packet rather than a data packet,		packet is an active measurement packet rather than a data packet,
	where "active" is used in the sense defined in [RFC7799]. The		where "active" is used in the sense defined in [RFC7799]. The
	packet may be an IOAM probe packet, or a replicated data packet		packet may be an IOAM probe packet, or a replicated data packet
	(the second and third use cases of Section 5).		(the second and third use cases of Section 5).
	4. Loopback in IOAM		4. Loopback in IOAM
	The Loopback flag is used to request that each transit device along		The Loopback flag is used to request that each transit device along
	the path loops back a copy of the data packet to the sender.		the path loops back a truncated copy of the data packet to the
	Loopback allows an IOAM encapsulating node to trace the path to a		sender. Loopback allows an IOAM encapsulating node to trace the path
	given destination, and to receive per-hop data about both the forward		to a given destination, and to receive per-hop data about both the
	and the return path. Loopback is intended to provide an accelerated		forward and the return path. Loopback is intended to provide an
	alternative to Traceroute, that allows the encapsulating node to		accelerated alternative to Traceroute, that allows the encapsulating
	receive responses from multiple transit nodes along the path in less		node to receive responses from multiple transit nodes along the path
	then one round-trip-time, and by sending a single packet.		in less then one round-trip-time, and by sending a single packet.
	As illustrated in Figure 1, an IOAM encapsulating node can push an		As illustrated in Figure 1, an IOAM encapsulating node can push an
	IOAM encapsulation that includes the Loopback flag onto some or all		IOAM encapsulation that includes the Loopback flag onto some or all
	of the packets it forwards. The IOAM transit node and the		of the packets it forwards. The IOAM transit node and the
	decapsulating node both creates copies of the packet and loop them		decapsulating node both creates copies of the packet and loop them
	back to the encapsulating node. The decapsulating node also		back to the encapsulating node. The decapsulating node also
	terminates the IOAM encapsulation, and then forwards the packet		terminates the IOAM encapsulation, and then forwards the packet
	towards the destination. The two IOAM looped back copies are		towards the destination. The two IOAM looped back copies are
	terminated by the encapsulating node.		terminated by the encapsulating node.
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 14 ¶
	either proactively or on-demand, i.e., when a failure is detected.		either proactively or on-demand, i.e., when a failure is detected.
	The encapsulating node also needs to ensure that sufficient space is		The encapsulating node also needs to ensure that sufficient space is
	available in the IOAM header for loopback operation, which includes		available in the IOAM header for loopback operation, which includes
	transit nodes adding trace data on the original path and then again		transit nodes adding trace data on the original path and then again
	on the return path.		on the return path.
	An IOAM trace option that has the Loopback flag set MUST have the		An IOAM trace option that has the Loopback flag set MUST have the
	value '1' in the most significant bit of IOAM-Trace-Type, and '0' in		value '1' in the most significant bit of IOAM-Trace-Type, and '0' in
	the rest of the bits of IOAM-Trace-Type. Thus, every transit node		the rest of the bits of IOAM-Trace-Type. Thus, every transit node
	that processes this trace option only adds a single data field, which		that processes this trace option only adds a single data field, which
	is the Hop_Lim and node_id data field. The reason for allowing a		is the Hop_Lim and node_id data field. A transit node that receives
	single data field per hop is to minimize the impact of amplification		a packet with an IOAM trace option that has the Loopback flag set and
	attacks.		the IOAM-Trace-Type is not equal to '1' in the most significant bit
			and '0' in the rest of the bits, MUST NOT loop back a copy of the
			packet. The reason for allowing a single data field per hop is to
			minimize the impact of amplification attacks.
	IOAM encapsulating nodes MUST NOT push an IOAM encapsulation with the		IOAM encapsulating nodes MUST NOT push an IOAM encapsulation with the
	Loopback flag onto data packets that already include an IOAM		Loopback flag onto data packets that already include an IOAM
	encapsulation. This requirement is intended to prevent IOAM Loopback		encapsulation. This requirement is intended to prevent IOAM Loopback
	nesting, where looped back packets may be subject to loopback in a		nesting, where looped back packets may be subject to loopback in a
	nested IOAM domain.		nested IOAM domain.
	4.1.1. Loopback Packet Selection		4.1.1. Loopback Packet Selection
	If an IOAM encapsulating node incorporates the Loopback flag into all		If an IOAM encapsulating node incorporates the Loopback flag into all
	skipping to change at page 5, line 47 ¶		skipping to change at page 6, line 11 ¶
	network operators. If there is an upper bound, M, on the number of		network operators. If there is an upper bound, M, on the number of
	IOAM transit nodes in any path in the network, then it is recommended		IOAM transit nodes in any path in the network, then it is recommended
	to use an N such that N >> M. The rationale is that a packet that		to use an N such that N >> M. The rationale is that a packet that
	includes the Loopback flag triggers a looped back packet from each		includes the Loopback flag triggers a looped back packet from each
	IOAM transit node along the path for a total of M looped back		IOAM transit node along the path for a total of M looped back
	packets. Thus, if N >> M then the number of looped back packets is		packets. Thus, if N >> M then the number of looped back packets is
	significantly lower than the number of data packets forwarded by the		significantly lower than the number of data packets forwarded by the
	IOAM encapsulating node. If there is no prior knowledge about the		IOAM encapsulating node. If there is no prior knowledge about the
	network topology or size, it is recommended to use N>100.		network topology or size, it is recommended to use N>100.
			The loopback flag MUST NOT be set if it is not guaranteed that there
			is a return path from each of the IOAM transit and IOAM decapsulating
			nodes, or if the encapsulating node's identity is not available in
			the encapsulation header.
	4.2. Receiving and Processing Loopback		4.2. Receiving and Processing Loopback
	A Loopback flag that is set indicates to the transit nodes processing		A Loopback flag that is set indicates to the transit nodes processing
	this option that they are to create a copy of the received packet and		this option that they are to create a copy of the received packet and
	send the copy back to the source of the packet. In this context the		send the copy back to the source of the packet. In this context the
	source is the IOAM encapsulating node, and it is assumed that the		source is the IOAM encapsulating node, and it is assumed that the
	source address is available in the encapsulation header. Thus, the		source address is available in the encapsulation header. Thus, the
	source address of the original packet is used as the destination		source address of the original packet is used as the destination
	address in the copied packet. The address of the node performing the		address in the copied packet. If the address of the encapsulating
	copy operation is used as the source address. The IOAM transit node		node is not available in the encapsulation header, then the transit/
	pushes the required data field *after* creating the copy of the		decapsulating node does not loop back a copy of the original packet.
	packet, in order to allow any egress-dependent information to be set		The address of the node performing the copy operation is used as the
	based on the egress of the copy rather than the original packet. The		source address. The IOAM transit node pushes the required data field
	copy is also truncated, i.e., any payload that resides after the IOAM		*after* creating the copy of the packet, in order to allow any
	option(s) is removed before transmitting the looped back packet back		egress-dependent information to be set based on the egress of the
	towards the encapsulating node. The original packet continues		copy rather than the original packet. The copy is also truncated,
	towards its destination. The L-bit MUST be cleared in the copy of		i.e., any payload that resides after the IOAM option(s) is removed
	the packet that a node sends back towards the source.		before transmitting the looped back packet back towards the
			encapsulating node. The original packet continues towards its
			destination. The L-bit MUST be cleared in the copy of the packet
			that a node sends back towards the source.
	An IOAM node that supports the reception and processing of the		An IOAM node that supports the reception and processing of the
	Loopback flag MUST support the ability to limit the rate of the		Loopback flag MUST support the ability to limit the rate of the
	looped back packets. The rate of looped back packets SHOULD be		looped back packets. The rate of looped back packets SHOULD be
	limited so that the number of looped back packets is significantly		limited so that the number of looped back packets is significantly
	lower than the number of packets that are forwarded by the device.		lower than the number of packets that are forwarded by the device.
	The looped back data rate SHOULD NOT exceed 1/N of the interface		The looped back data rate SHOULD NOT exceed 1/N of the interface
	capacity on any of the IOAM node's interfaces. It is recommended to		capacity on any of the IOAM node's interfaces. It is recommended to
	use N>100. Depending on the IOAM node's architecture considerations,		use N>100. Depending on the IOAM node's architecture considerations,
	the loopback response rate may be limited to a lower number in order		the loopback response rate may be limited to a lower number in order
	skipping to change at page 6, line 44 ¶		skipping to change at page 7, line 20 ¶
	space).		space).
	4.4. Terminating a Looped Back Packet		4.4. Terminating a Looped Back Packet
	Once the return packet reaches the IOAM domain boundary, IOAM		Once the return packet reaches the IOAM domain boundary, IOAM
	decapsulation occurs as with any other packet containing IOAM		decapsulation occurs as with any other packet containing IOAM
	information. Note that the looped back packet does not have the		information. Note that the looped back packet does not have the
	L-bit set. The IOAM encapsulating node that initiated the original		L-bit set. The IOAM encapsulating node that initiated the original
	loopback packet recognizes a received packet as an IOAM looped-back		loopback packet recognizes a received packet as an IOAM looped-back
	packet by checking the Node ID in the Hop_Lim/node_id field that		packet by checking the Node ID in the Hop_Lim/node_id field that
	corresponds to the first hop. If the Node ID matches the current		corresponds to the first hop. If the Node ID and IOAM-Namespace
	IOAM node, it indicates that this is a looped back packet that was		match the current IOAM node, it indicates that this is a looped back
	initiated by the current IOAM node, and processed accordingly. If		packet that was initiated by the current IOAM node, and processed
	there is no match in the Node ID, the packet is processed like a		accordingly. If there is no match in the Node ID, the packet is
	conventional IOAM-encapsulated packet.		processed like a conventional IOAM-encapsulated packet.
	Note that an IOAM encapsulating node may either be an endpoint (such		Note that an IOAM encapsulating node may either be an endpoint (such
	as an IPv6 host), or a switch/router that pushes a tunnel		as an IPv6 host), or a switch/router that pushes a tunnel
	encapsulation onto data packets. In both cases, the functionality		encapsulation onto data packets. In both cases, the functionality
	that was described above avoids IOAM data leaks from the IOAM domain.		that was described above avoids IOAM data leaks from the IOAM domain.
	Specificallly, if an IOAM looped-back packet reaches an IOAM boundary		Specificallly, if an IOAM looped-back packet reaches an IOAM boundary
	node that is not the IOAM node that initiated the loopback, the node		node that is not the IOAM node that initiated the loopback, the node
	does not process the packet as a loopback; the IOAM encapsulation is		does not process the packet as a loopback; the IOAM encapsulation is
	removed, and since the packet does not have any payload it is		removed, and since the packet does not have any payload it is
	terminated. In either case, when the packet reaches the IOAM		terminated. In either case, when the packet reaches the IOAM
	skipping to change at page 9, line 46 ¶		skipping to change at page 10, line 18 ¶
	the network bandwidth, and does not overload the source node in the		the network bandwidth, and does not overload the source node in the
	case of loopback.		case of loopback.
	8. Security Considerations		8. Security Considerations
	The security considerations of IOAM in general are discussed in		The security considerations of IOAM in general are discussed in
	[I-D.ietf-ippm-ioam-data]. Specifically, an attacker may try to use		[I-D.ietf-ippm-ioam-data]. Specifically, an attacker may try to use
	the functionality that is defined in this document to attack the		the functionality that is defined in this document to attack the
	network.		network.
	An attacker may attempt to overload network devices by injecting		IOAM is assumed to be deployed in a restricted administrative domain,
	synthetic packets that include an IOAM Trace Option with one or more		thus limiting the scope of the threats above and their effect. This
	of the flags defined in this document. Similarly, an on-path		is a fundamental assumption with respect to the security aspects of
	attacker may maliciously set one or more of the flags of transit		IOAM, as further discussed in [I-D.ietf-ippm-ioam-data]. However,
	packets.		even given this limited scope, security threats should still be
			considered and mitigated. Specifically, an attacker may attempt to
			overload network devices by injecting synthetic packets that include
			an IOAM Trace Option with one or more of the flags defined in this
			document. Similarly, an on-path attacker may maliciously set one or
			more of the flags of transit packets.
	o Loopback flag: an attacker that sets this flag, either in		o Loopback flag: an attacker that sets this flag, either in
	synthetic packets or transit packet, can potentially cause an		synthetic packets or transit packet, can potentially cause an
	amplification, since each device along the path creates a copy of		amplification, since each device along the path creates a copy of
	the data packet and sends it back to the source. The attacker can		the data packet and sends it back to the source. The attacker can
	potentially leverage the Loopback flag for a Distributed Denial of		potentially leverage the Loopback flag for a Distributed Denial of
	Service (DDoS) attack, as multiple devices send looped-back copies		Service (DDoS) attack, as multiple devices send looped-back copies
	of a packet to a single source.		of a packet to a single source.
	o Active flag: the impact of synthetic packets with the Active flag		o Active flag: the impact of synthetic packets with the Active flag
	skipping to change at page 11, line 10 ¶		skipping to change at page 11, line 34 ¶
	decapsulating nodes), as discussed in Section 4.2.		decapsulating nodes), as discussed in Section 4.2.
	o Limit the rate of IOAM packets with the Active flag (IOAM		o Limit the rate of IOAM packets with the Active flag (IOAM
	encapsulating nodes), as discussed in Section 5.		encapsulating nodes), as discussed in Section 5.
	As defined in Section 4, transit nodes that process a packet with the		As defined in Section 4, transit nodes that process a packet with the
	Loopback flag only add a single data field, and truncate any payload		Loopback flag only add a single data field, and truncate any payload
	that follows the IOAM option(s), thus significanly limiting the		that follows the IOAM option(s), thus significanly limiting the
	possible impact of an amplification attack.		possible impact of an amplification attack.
	IOAM is assumed to be deployed in a restricted administrative domain,		9. Acknowledgments
	thus limiting the scope of the threats above and their affect. This
	is a fundamental assumtion with respect to the security aspects of
	IOAM, as further discussed in [I-D.ietf-ippm-ioam-data].
	9. References		The authors thank Martin Duke, Tommy Pauly, Greg Mirsky, and other
			members of the IPPM working group for many helpful comments.
	9.1. Normative References		10. References
			10.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-14 (work in		for In-situ OAM", draft-ietf-ippm-ioam-data-15 (work in
	progress), June 2021.		progress), October 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>.
	[RFC7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow		[RFC7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow
	Selection Techniques", RFC 7014, DOI 10.17487/RFC7014,		Selection Techniques", RFC 7014, DOI 10.17487/RFC7014,
	September 2013, <https://www.rfc-editor.org/info/rfc7014>.		September 2013, <https://www.rfc-editor.org/info/rfc7014>.
	[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>.
	9.2. Informative References		10.2. Informative References
	[I-D.ietf-ippm-ioam-ipv6-options]		[I-D.ietf-ippm-ioam-ipv6-options]
	Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options",		Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options",
	draft-ietf-ippm-ioam-ipv6-options-06 (work in progress),		draft-ietf-ippm-ioam-ipv6-options-06 (work in progress),
	July 2021.		July 2021.
	[I-D.ietf-sfc-ioam-nsh]		[I-D.ietf-sfc-ioam-nsh]
	Brockners, F. and S. Bhandari, "Network Service Header		Brockners, F. and S. Bhandari, "Network Service Header
	(NSH) Encapsulation for In-situ OAM (IOAM) Data", draft-		(NSH) Encapsulation for In-situ OAM (IOAM) Data", draft-
	ietf-sfc-ioam-nsh-06 (work in progress), July 2021.		ietf-sfc-ioam-nsh-06 (work in progress), July 2021.
	skipping to change at page 13, line 16 ¶		skipping to change at page 14, line 4 ¶
	7200-11 Kit Creek Road		7200-11 Kit Creek Road
	Research Triangle Park, NC 27709		Research Triangle Park, NC 27709
	United States		United States
	Email: cpignata@cisco.com		Email: cpignata@cisco.com
	Aviv Kfir		Aviv Kfir
	Nvidia		Nvidia
	Email: avivk@nvidia.com		Email: avivk@nvidia.com
	Barak Gafni		Barak Gafni
	Nvidia		Nvidia
	350 Oakmead Parkway, Suite 100		350 Oakmead Parkway, Suite 100
	Sunnyvale, CA 94085		Sunnyvale, CA 94085
	U.S.A.		U.S.A.
	Email: gbarak@nvidia.com		Email: gbarak@nvidia.com
	Mickey Spiegel		Mickey Spiegel
	Barefoot Networks		Barefoot Networks, an Intel company
	4750 Patrick Henry Drive		4750 Patrick Henry Drive
	Santa Clara, CA 95054		Santa Clara, CA 95054
	US		US
	Email: mspiegel@barefootnetworks.com		Email: mickey.spiegel@intel.com
	Jennifer Lemon		Jennifer Lemon
	Broadcom		Broadcom
	270 Innovation Drive		270 Innovation Drive
	San Jose, CA 95134		San Jose, CA 95134
	US		US
	Email: jennifer.lemon@broadcom.com		Email: jennifer.lemon@broadcom.com
End of changes. 24 change blocks.
	57 lines changed or deleted		79 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/