< draft-ietf-ippm-ioam-data-01.txt		draft-ietf-ippm-ioam-data-02.txt >
	ippm F. Brockners		ippm F. Brockners
	Internet-Draft S. Bhandari		Internet-Draft S. Bhandari
	Intended status: Standards Track C. Pignataro		Intended status: Standards Track C. Pignataro
	Expires: May 3, 2018 Cisco		Expires: September 6, 2018 Cisco
	H. Gredler		H. Gredler
	RtBrick Inc.		RtBrick Inc.
	J. Leddy		J. Leddy
	Comcast		Comcast
	S. Youell		S. Youell
	JPMC		JPMC
	T. Mizrahi		T. Mizrahi
	Marvell		Marvell
	D. Mozes		D. Mozes
	Mellanox Technologies Ltd.
	P. Lapukhov		P. Lapukhov
	Facebook		Facebook
	R. Chang		R. Chang
	Barefoot Networks		Barefoot Networks
	D. Bernier		D. Bernier
	Bell Canada		Bell Canada
	October 30, 2017		J. Lemon
			Broadcom
			March 5, 2018
	Data Fields for In-situ OAM		Data Fields for In-situ OAM
	draft-ietf-ippm-ioam-data-01		draft-ietf-ippm-ioam-data-02
	Abstract		Abstract
	In-situ Operations, Administration, and Maintenance (IOAM) records		In-situ Operations, Administration, and Maintenance (IOAM) records
	operational and telemetry information in the packet while the packet		operational and telemetry information in the packet while the packet
	traverses a path between two points in the network. This document		traverses a path between two points in the network. This document
	discusses the data fields and associated data types for in-situ OAM.		discusses the data fields and associated data types for in-situ OAM.
	In-situ OAM data fields can be embedded into a variety of transports		In-situ OAM data fields can be embedded into a variety of transports
	such as NSH, Segment Routing, Geneve, native IPv6 (via extension		such as NSH, Segment Routing, Geneve, native IPv6 (via extension
	header), or IPv4. In-situ OAM can be used to complement OAM		header), or IPv4. In-situ OAM can be used to complement OAM
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 May 3, 2018.		This Internet-Draft will expire on September 6, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Scope, Applicability, and Assumptions . . . . . . . . . . . . 4		3. Scope, Applicability, and Assumptions . . . . . . . . . . . . 4
	4. IOAM Data Types and Formats . . . . . . . . . . . . . . . . . 5		4. IOAM Data Types and Formats . . . . . . . . . . . . . . . . . 5
	4.1. IOAM Tracing Options . . . . . . . . . . . . . . . . . . 6		4.1. IOAM Tracing Options . . . . . . . . . . . . . . . . . . 6
	4.1.1. Pre-allocated Trace Option . . . . . . . . . . . . . 8		4.1.1. Pre-allocated and Incremental Trace Options . . . . . 8
	4.1.2. Incremental Trace Option . . . . . . . . . . . . . . 11		4.1.2. IOAM node data fields and associated formats . . . . 12
	4.1.3. IOAM node data fields and associated formats . . . . 14		4.1.3. Examples of IOAM node data . . . . . . . . . . . . . 17
	4.1.4. Examples of IOAM node data . . . . . . . . . . . . . 19		4.2. IOAM Proof of Transit Option . . . . . . . . . . . . . . 19
	4.2. IOAM Proof of Transit Option . . . . . . . . . . . . . . 21		4.2.1. IOAM Proof of Transit Type 0 . . . . . . . . . . . . 20
	4.3. IOAM Edge-to-Edge Option . . . . . . . . . . . . . . . . 23		4.3. IOAM Edge-to-Edge Option . . . . . . . . . . . . . . . . 22
	5. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 23		5. Timestamp Formats . . . . . . . . . . . . . . . . . . . . . . 23
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		5.1. PTP Truncated Timestamp Format . . . . . . . . . . . . . 23
	6.1. Creation of a new In-Situ OAM Protocol Parameters		5.2. NTP 64-bit Timestamp Format . . . . . . . . . . . . . . . 25
	Registry (IOAM) Protocol		5.3. POSIX-based Timestamp Format . . . . . . . . . . . . . . 26
	Parameters IANA registry . . . . . . . . . . . . . . . . 24		6. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 27
	6.2. IOAM Trace Type Registry . . . . . . . . . . . . . . . . 24		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	6.3. IOAM Trace Flags Registry . . . . . . . . . . . . . . . . 24		7.1. Creation of a new In-Situ OAM Protocol Parameters
	6.4. IOAM POT Type Registry . . . . . . . . . . . . . . . . . 25		Registry (IOAM) Protocol Parameters IANA registry . . . . 28
	6.5. IOAM E2E Type Registry . . . . . . . . . . . . . . . . . 25		7.2. IOAM Type Registry . . . . . . . . . . . . . . . . . . . 28
	7. Manageability Considerations . . . . . . . . . . . . . . . . 25		7.3. IOAM Trace Type Registry . . . . . . . . . . . . . . . . 29
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 25		7.4. IOAM Trace Flags Registry . . . . . . . . . . . . . . . . 29
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25		7.5. IOAM POT Type Registry . . . . . . . . . . . . . . . . . 29
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		7.6. IOAM POT Flags Registry . . . . . . . . . . . . . . . . . 29
	10.1. Normative References . . . . . . . . . . . . . . . . . . 25		7.7. IOAM E2E Type Registry . . . . . . . . . . . . . . . . . 29
	10.2. Informative References . . . . . . . . . . . . . . . . . 26		8. Manageability Considerations . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27		9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
			10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
			11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
			11.1. Normative References . . . . . . . . . . . . . . . . . . 30
			11.2. Informative References . . . . . . . . . . . . . . . . . 31
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
	1. Introduction		1. Introduction
	This document defines data fields for "in-situ" Operations,		This document defines data fields for "in-situ" Operations,
	Administration, and Maintenance (IOAM). In-situ OAM records OAM		Administration, and Maintenance (IOAM). In-situ OAM records OAM
	information within the packet while the packet traverses a particular		information within the packet while the packet traverses a particular
	network domain. The term "in-situ" refers to the fact that the OAM		network domain. The term "in-situ" refers to the fact that the OAM
	data is added to the data packets rather than is being sent within		data is added to the data packets rather than is being sent within
	packets specifically dedicated to OAM. A discussion of the		packets specifically dedicated to OAM. IOAM is to complement
	motivation and requirements for in-situ OAM can be found in
	[I-D.brockners-inband-oam-requirements]. IOAM is to complement
	mechanisms such as Ping or Traceroute, or more recent active probing		mechanisms such as Ping or Traceroute, or more recent active probing
	mechanisms as described in [I-D.lapukhov-dataplane-probe]. In terms		mechanisms as described in [I-D.lapukhov-dataplane-probe]. In terms
	of "active" or "passive" OAM, "in-situ" OAM can be considered a		of "active" or "passive" OAM, "in-situ" OAM can be considered a
	hybrid OAM type. While no extra packets are sent, IOAM adds		hybrid OAM type. While no extra packets are sent, IOAM adds
	information to the packets therefore cannot be considered passive.		information to the packets therefore cannot be considered passive.
	In terms of the classification given in [RFC7799] IOAM could be		In terms of the classification given in [RFC7799] IOAM could be
	portrayed as Hybrid Type 1. "In-situ" mechanisms do not require		portrayed as Hybrid Type 1. "In-situ" mechanisms do not require
	extra packets to be sent and hence don't change the packet traffic		extra packets to be sent and hence don't change the packet traffic
	mix within the network. IOAM mechanisms can be leveraged where		mix within the network. IOAM mechanisms can be leveraged where
	mechanisms using e.g. ICMP do not apply or do not offer the desired		mechanisms using e.g. ICMP do not apply or do not offer the desired
	skipping to change at page 5, line 41 ¶		skipping to change at page 5, line 43 ¶
	IOAM information retrieved from the packet back to the source address		IOAM information retrieved from the packet back to the source address
	of the packet or to the encapsulating node.		of the packet or to the encapsulating node.
	IOAM implementation: The IOAM data-field definitions take the		IOAM implementation: The IOAM data-field definitions take the
	specifics of devices with hardware data-plane and software data-plane		specifics of devices with hardware data-plane and software data-plane
	into account.		into account.
	4. IOAM Data Types and Formats		4. IOAM Data Types and Formats
	This section defines IOAM data types and data fields and associated		This section defines IOAM data types and data fields and associated
	data types required for IOAM. The different uses of IOAM require the		data types required for IOAM.
	definition of different types of data. The IOAM data fields for the
	data being carried corresponds to the three main categories of IOAM
	data defined in [I-D.brockners-inband-oam-requirements], which are:
	edge-to-edge, per node, and for selected nodes only.
	Transport options for IOAM data are outside the scope of this memo,		To accommodate the different uses of IOAM, IOAM data fields fall into
	and are discussed in [I-D.brockners-inband-oam-transport]. IOAM data		different categories, e.g. edge-to-edge, per node tracing, or for
	fields are fixed length data fields. A bit field determines the set		proof of transit. In IOAM these categories are referred to as IOAM-
	of OAM data fields embedded in a packet. Depending on the type of		Types. A common registry is maintained for IOAM-Types, see
	the encapsulation, a counter field indicates how many data fields are		Section 7.2 for details. Corresponding to these IOAM-Types,
	included in a particular packet.		different IOAM data fields are defined. IOAM data fields can be
			encapsulated into a variety of protocols, such as NSH, Geneve, IPv6,
			etc. The definition of how IOAM data fields are encapsulated into
			other protocols is outside the scope of this document.
	IOAM is expected to be deployed in a specific domain rather than on		IOAM is expected to be deployed in a specific domain rather than on
	the overall Internet. The part of the network which employs IOAM is		the overall Internet. The part of the network which employs IOAM is
	referred to as the "IOAM-domain". IOAM data is added to a packet		referred to as the "IOAM-domain". IOAM data is added to a packet
	upon entering the IOAM-domain and is removed from the packet when		upon entering the IOAM-domain and is removed from the packet when
	exiting the domain. Within the IOAM-domain, the IOAM data may be		exiting the domain. Within the IOAM-domain, the IOAM data may be
	updated by network nodes that the packet traverses. The device which		updated by network nodes that the packet traverses. The device which
	adds an IOAM data container to the packet to capture IOAM data is		adds an IOAM data container to the packet to capture IOAM data is
	called the "IOAM encapsulating node", whereas the device which		called the "IOAM encapsulating node", whereas the device which
	removes the IOAM data container is referred to as the "IOAM		removes the IOAM data container is referred to as the "IOAM
	skipping to change at page 7, line 17 ¶		skipping to change at page 7, line 21 ¶
	and sets the fields in the option header. The in situ OAM		and sets the fields in the option header. The in situ OAM
	encapsulating node allocates an array which is used to store		encapsulating node allocates an array which is used to store
	operational data retrieved from every node while the packet		operational data retrieved from every node while the packet
	traverses the domain. IOAM transit nodes update the content of		traverses the domain. IOAM transit nodes update the content of
	the array. A pointer which is part of the IOAM trace data points		the array. A pointer which is part of the IOAM trace data points
	to the next empty slot in the array, which is where the next IOAM		to the next empty slot in the array, which is where the next IOAM
	transit node fills in its data.		transit node fills in its data.
	Incremental Trace Option: This trace option is defined as a		Incremental Trace Option: This trace option is defined as a
	container of node data fields where each node allocates and pushes		container of node data fields where each node allocates and pushes
	its node data immediately following the option header. The		its node data immediately following the option header. This type
	maximum length of the node data list is written into the option		of trace recording is useful for some of the hardware
	header. This type of trace recording is useful for some of the		implementations as this eliminates the need for the transit
	hardware implementations as this eliminates the need for the		network elements to read the full array in the option and allows
	transit network elements to read the full array in the option and		for arbitrarily long packets as the MTU allows. The in-situ OAM
	allows for arbitrarily long packets as the MTU allows. The in-		encapsulating node allocates the option header. The in-situ OAM
	situ OAM encapsulating node allocates the option header. The in-		encapsulating node based on operational state and configuration
	situ OAM encapsulating node based on operational state and		sets the fields in the header that control what node data fields
	configuration sets the fields in the header to control how large		should be collected, and how large the node data list can grow.
	the node data list can grow. IOAM transit nodes push their node		The in-situ OAM transit nodes push their node data to the node
	data to the node data list and increment the number of node data		data list, decrease the remaining length available to subsequent
	fields in the header.		nodes, and adjust the lengths and possibly checksums in outer
			headers.
	Every node data entry is to hold information for a particular IOAM		Every node data entry is to hold information for a particular IOAM
	transit node that is traversed by a packet. The in-situ OAM		transit node that is traversed by a packet. The in-situ OAM
	decapsulating node removes the IOAM data and processes and/or exports		decapsulating node removes the IOAM data and processes and/or exports
	the metadata. IOAM data uses its own name-space for information such		the metadata. IOAM data uses its own name-space for information such
	as node identifier or interface identifier. This allows for a		as node identifier or interface identifier. This allows for a
	domain-specific definition and interpretation. For example: In one		domain-specific definition and interpretation. For example: In one
	case an interface-id could point to a physical interface (e.g., to		case an interface-id could point to a physical interface (e.g., to
	understand which physical interface of an aggregated link is used		understand which physical interface of an aggregated link is used
	when receiving or transmitting a packet) whereas in another case it		when receiving or transmitting a packet) whereas in another case it
	skipping to change at page 8, line 28 ¶		skipping to change at page 8, line 34 ¶
	o A mechanism to detect whether IOAM trace data was added at every		o A mechanism to detect whether IOAM trace data was added at every
	hop or whether certain hops in the domain weren't in-situ OAM		hop or whether certain hops in the domain weren't in-situ OAM
	transit nodes.		transit nodes.
	The "node data list" array in the packet is populated iteratively as		The "node data list" array in the packet is populated iteratively as
	the packet traverses the network, starting with the last entry of the		the packet traverses the network, starting with the last entry of the
	array, i.e., "node data list [n]" is the first entry to be populated,		array, i.e., "node data list [n]" is the first entry to be populated,
	"node data list [n-1]" is the second one, etc.		"node data list [n-1]" is the second one, etc.
	4.1.1. Pre-allocated Trace Option		4.1.1. Pre-allocated and Incremental Trace Options
	In-situ OAM pre-allocated trace option:
	Pre-allocated trace option header:		The in-situ OAM pre-allocated trace option and the in-situ OAM
			incremental trace option have similar formats. Except where noted
			below, the internal formats and fields of the two trace options are
			identical.
			Pre-allocated and incremental trace option headers:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IOAM-Trace-Type |NodeLen| Flags | Octets-left |		| IOAM-Trace-Type | NodeLen | Flags |RemainingLen |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Pre-allocated Trace Option Data MUST be 4-octet aligned:		The trace option data MUST be 4-octet aligned:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
	| | |		| | |
	| node data list [0] | |		| node data list [0] | |
	| | |		| | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D
	| | a		| | a
	| node data list [1] | t		| node data list [1] | t
	| | a		| | a
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ... ~ S		~ ... ~ S
	skipping to change at page 9, line 40 ¶		skipping to change at page 9, line 40 ¶
	| | |		| | |
	| node data list [n] | |		| node data list [n] | |
	| | |		| | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
	IOAM-Trace-Type: A 16-bit identifier which specifies which data		IOAM-Trace-Type: A 16-bit identifier which specifies which data
	types are used in this node data list.		types are used in this node data list.
	The IOAM-Trace-Type value is a bit field. The following bit		The IOAM-Trace-Type value is a bit field. The following bit
	fields are defined in this document, with details on each field		fields are defined in this document, with details on each field
	described in the Section 4.1.3. The order of packing the data		described in the Section 4.1.2. The order of packing the data
	fields in each node data element follows the bit order of the		fields in each node data element follows the bit order of the
	IOAM-Trace-Type field, as follows:		IOAM-Trace-Type field, as follows:
	Bit 0 (Most significant bit) When set indicates presence of		Bit 0 (Most significant bit) When set indicates presence of
	Hop_Lim and node_id in the node data.		Hop_Lim and node_id in the node data.
	Bit 1 When set indicates presence of ingress_if_id and		Bit 1 When set indicates presence of ingress_if_id and
	egress_if_id (short format) in the node data.		egress_if_id (short format) in the node data.
	Bit 2 When set indicates presence of timestamp seconds in the		Bit 2 When set indicates presence of timestamp seconds in the
	node data		node data.
	Bit 3 When set indicates presence of timestamp nanoseconds in		Bit 3 When set indicates presence of timestamp subseconds in
	the node data.		the node data.
	Bit 4 When set indicates presence of transit delay in the node		Bit 4 When set indicates presence of transit delay in the node
	data.		data.
	Bit 5 When set indicates presence of app_data (short format) in		Bit 5 When set indicates presence of app_data (short format) in
	the node data.		the node data.
	Bit 6 When set indicates presence of queue depth in the node		Bit 6 When set indicates presence of queue depth in the node
	data.		data.
	skipping to change at page 10, line 35 ¶		skipping to change at page 10, line 35 ¶
	Bit 9 When set indicates presence of ingress_if_id and		Bit 9 When set indicates presence of ingress_if_id and
	egress_if_id in wide format in the node data.		egress_if_id in wide format in the node data.
	Bit 10 When set indicates presence of app_data wide in the node		Bit 10 When set indicates presence of app_data wide in the node
	data.		data.
	Bit 11 When set indicates presence of the Checksum Complement		Bit 11 When set indicates presence of the Checksum Complement
	node data.		node data.
	Bit 12-15 Undefined in this draft.		Bit 12-15 Undefined. An IOAM encapsulating node must set the
			value of each of these bits to 0. If an IOAM transit
			node receives a packet with one or more of these bits set
			to 1, it must either:
	Section 4.1.3 describes the IOAM data types and their formats.		1. Add corresponding node data filled with the reserved
			value 0xFFFFFFFF, after the node data fields for the
			IOAM-Trace-Type bits defined above, such that the
			total node data added by this node in units of
			4-octets is equal to NodeLen, or
			2. Not add any node data fields to the packet, even for
			the IOAM-Trace-Type bits defined above.
			Section 4.1.2 describes the IOAM data types and their formats.
	Within an in-situ OAM domain possible combinations of these bits		Within an in-situ OAM domain possible combinations of these bits
	making the IOAM-Trace-Type can be restricted by configuration		making the IOAM-Trace-Type can be restricted by configuration
	knobs.		knobs.
	NodeLen: 4-bit unsigned integer. This field specifies the length of		NodeLen: 5-bit unsigned integer. This field specifies the length of
	data added by each node in multiples of 4-octets. For example, if		data added by each node in multiples of 4-octets, excluding the
	3 IOAM-Trace-Type bits are set and none of them is wide, then the		length of the "Opaque State Snapshot" field.
	NodeLen would be 3. If 3 IOAM-Trace-Type bits are set and 2 of
	them are wide, then the NodeLen would be 5.
	Flags 5-bit field. Following flags are defined:		If IOAM-Trace-Type bit 7 is not set, then NodeLen specifies the
			actual length added by each node. If IOAM-Trace-Type bit 7 is
			set, then the actual length added by a node would be (NodeLen +
			Opaque Data Length).
			For example, if 3 IOAM-Trace-Type bits are set and none of them
			are wide, then NodeLen would be 3. If 3 IOAM-Trace-Type bits are
			set and 2 of them are wide, then NodeLen would be 5.
			An IOAM encapsulating node must set NodeLen.
			A node receiving an IOAM Pre-allocated or Incremental Trace Option
			may rely on the NodeLen value, or it may ignore the NodeLen value
			and calculate the node length from the IOAM-Trace-Type bits.
			Flags 4-bit field. Following flags are defined:
	Bit 0 "Overflow" (O-bit) (most significant bit). This bit is set		Bit 0 "Overflow" (O-bit) (most significant bit). This bit is set
	by the network element if there is not enough number of octets		by the network element if there is not enough number of octets
	left to record node data, no field is added and the overflow		left to record node data, no field is added and the overflow
	"O-bit" must be set to "1" in the header. This is useful for		"O-bit" must be set to "1" in the header. This is useful for
	transit nodes to ignore further processing of the option.		transit nodes to ignore further processing of the option.
	Bit 1 "Loopback" (L-bit). Loopback mode is used to send a copy		Bit 1 "Loopback" (L-bit). Loopback mode is used to send a copy
	of a packet back towards the source. Loopback mode assumes		of a packet back towards the source. Loopback mode assumes
	that a return path from transit nodes and destination nodes		that a return path from transit nodes and destination nodes
	skipping to change at page 11, line 22 ¶		skipping to change at page 11, line 47 ¶
	for by setting the loopback bit. The encapsulating node also		for by setting the loopback bit. The encapsulating node also
	needs to ensure that sufficient space is available in the IOAM		needs to ensure that sufficient space is available in the IOAM
	header for loopback operation. The loopback bit when set		header for loopback operation. The loopback bit when set
	indicates to the transit nodes processing this option to create		indicates to the transit nodes processing this option to create
	a copy of the packet received and send this copy of the packet		a copy of the packet received and send this copy of the packet
	back to the source of the packet while it continues to forward		back to the source of the packet while it continues to forward
	the original packet towards the destination. The source		the original packet towards the destination. The source
	address of the original packet is used as destination address		address of the original packet is used as destination address
	in the copied packet. The address of the node performing the		in the copied packet. The address of the node performing the
	copy operation is used as the source address. The L-bit MUST		copy operation is used as the source address. The L-bit MUST
	be cleared in the copy of the packet a nodes sends it back		be cleared in the copy of the packet that a node sends back
	towards the source. On its way back towards the source, the		towards the source. On its way back towards the source, the
	packet is processed like a regular packet with IOAM		packet is processed like a regular packet with IOAM
	information. Once the return packet reaches the IOAM domain		information. Once the return packet reaches the IOAM domain
	boundary IOAM decapsulation occurs as with any other packet		boundary IOAM decapsulation occurs as with any other packet
	containing IOAM information.		containing IOAM information.
	Bit 2-4 Reserved: Must be zero.		Bit 2-3 Reserved: Must be zero.
	Octets-left: 7-bit unsigned integer. It is the data space in
	multiples of 4-octets remaining for recording the node data. This
	is used as an offset in data space to record the node data
	element.
	Node data List [n]: Variable-length field. The type of which is
	determined by the IOAM-Trace-Type representing the n-th node data
	in the node data list. The node data list is encoded starting
	from the last node data of the path. The first element of the
	node data list (node data list [0]) contains the last node of the
	path while the last node data of the node data list (node data
	list[n]) contains the first node data of the path traced. The
	index contained in "Octets-left" identifies the offset for current
	active node data to be populated.
	4.1.2. Incremental Trace Option
	In-situ OAM incremental trace option:
	In-situ OAM incremental trace option Header:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IOAM-Trace-Type |NodeLen| Flags | Max Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	IOAM Incremental Trace Option Data MUST be 4-octet aligned:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	| node data list [0] |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	| node data list [1] |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ... ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	| node data list [n-1] |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	| node data list [n] |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	IOAM-trace-type: A 16-bit identifier which specifies which data
	types are used in this node data list.
	The IOAM-Trace-Type value is a bit field. The following bit
	fields are defined in this document, with details on each field
	described in the Section 4.1.3. The order of packing the data
	fields in each node data element follows the bit order of the
	IOAM-Trace-Type field, as follows:
	Bit 0 (Most significant bit) When set indicates presence of
	Hop_Lim and node_id in the node data.
	Bit 1 When set indicates presence of ingress_if_id and
	egress_if_id (short format) in the node data.
	Bit 2 When set indicates presence of timestamp seconds in the
	node data.
	Bit 3 When set indicates presence of timestamp nanoseconds in
	the node data.
	Bit 4 When set indicates presence of transit delay in the node
	data.
	Bit 5 When set indicates presence of app_data in the node data.
	Bit 6 When set indicates presence of queue depth in the node
	data.
	Bit 7 When set indicates presence of variable length Opaque
	State Snapshot field.
	Bit 8 When set indicates presence of Hop_Lim and node_id wide
	in the node data.
	Bit 9 When set indicates presence of ingress_if_id and
	egress_if_id in wide format in the node data.
	Bit 10 When set indicates presence of app_data wide in the node
	data.
	Bit 11 When set indicates presence of the Checksum Complement
	node data.
	Bit 12-15 Undefined in this draft.
	Section 4.1.3 describes the IOAM data types and their formats.
	NodeLen: 4-bit unsigned integer. This field specifies the length of
	data added by each node in multiples of 4-octets. For example, if
	3 IOAM-Trace-Type bits are set and none of them is wide, then the
	NodeLen would be 3. If 3 IOAM-Trace-Type bits are set and 2 of
	them are wide, then the NodeLen would be 5.
	Flags 5-bit field. Following flags are defined:
	Bit 0 "Overflow" (O-bit) (most significant bit). This bit is set
	by the network element if there is not enough number of octets
	left to record node data, no field is added and the overflow
	"O-bit" must be set to "1" in the header. This is useful for
	transit nodes to ignore further processing of the option.
	Bit 1 "Loopback" (L-bit). This bit when set indicates to the
	transit nodes processing this option to send a copy of the
	packet back to the source of the packet while it continues to
	forward the original packet towards the destination. The L-bit
	MUST be cleared in the copy of the packet before sending it.
	Bit 2-4 Reserved. Must be zero.
	Maximum Length: 7-bit unsigned integer. This field specifies the		RemainingLen: 7-bit unsigned integer. This field specifies the data
	maximum length of the node data list in multiples of 4-octets.		space in multiples of 4-octets remaining for recording the node
	Given that the sender knows the minimum path MTU, the sender can		data, before the node data list is considered to have overflowed.
	set the maximum length according to the number of node data bytes		When RemainingLen reaches 0, nodes are no longer allowed to add
	allowed before exceeding the MTU. Thus, a simple comparison		node data. Given that the sender knows the minimum path MTU, the
	between "NodeLen" and "Max Length" allows to decide whether or not		sender MAY set the initial value of RemainingLen according to the
	data could be added.		number of node data bytes allowed before exceeding the MTU.
			Subsequent nodes can carry out a simple comparison between
			RemainingLen and NodeLen, along with the length of the "Opaque
			State Snapshot" if applicable, to determine whether or not data
			can be added by this node. When node data is added, the node MUST
			decrease RemainingLen by the amount of data added. In the pre-
			allocated trace option, this is used as an offset in data space to
			record the node data element.
	Node data List [n]: Variable-length field. The type of which is		Node data List [n]: Variable-length field. The type of which is
	determined by the OAM Type representing the n-th node data in the		determined by the IOAM-Trace-Type bit representing the n-th node
	node data list. The node data list is encoded starting from the		data in the node data list. The node data list is encoded
	last node data of the path. The first element of the node data		starting from the last node data of the path. The first element
	list (node data list [0]) contains the last node of the path while		of the node data list (node data list [0]) contains the last node
	the last node data of the node data list (node data list[n])		of the path while the last node data of the node data list (node
	contains the first node data of the path traced.		data list[n]) contains the first node data of the path traced. In
			the pre-allocated trace option, the index contained in
			RemainingLen identifies the offset for current active node data to
			be populated.
	4.1.3. IOAM node data fields and associated formats		4.1.2. IOAM node data fields and associated formats
	All the data fields MUST be 4-octet aligned. The IOAM encapsulating		All the data fields MUST be 4-octet aligned. If a node which is
	node MUST initialize data fields that it adds to the packet to zero.		supposed to update an IOAM data field is not capable of populating
	If a node which is supposed to update an IOAM data field is not		the value of a field set in the IOAM-Trace-Type, the field value MUST
	capable of populating the value of a field set in the IOAM-Trace-		be set to 0xFFFFFFFF for 4-octet fields or 0xFFFFFFFFFFFFFFFF for
	Type, the field value MUST be left unaltered except when explicitly		8-octet fields, indicating that the value is not populated, except
	specified in the field description below. In the description of data		when explicitly specified in the field description below.
	below if zero is valid value then a non-zero value to mean not
	populated is specified.
	Data field and associated data type for each of the data field is		Data field and associated data type for each of the data field is
	shown below:		shown below:
	Hop_Lim and node_id: 4-octet field defined as follows:		Hop_Lim and node_id: 4-octet field defined as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Hop_Lim | node_id |		| Hop_Lim | node_id |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 14, line 49 ¶		skipping to change at page 13, line 4 ¶
	Data field and associated data type for each of the data field is		Data field and associated data type for each of the data field is
	shown below:		shown below:
	Hop_Lim and node_id: 4-octet field defined as follows:		Hop_Lim and node_id: 4-octet field defined as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Hop_Lim | node_id |		| Hop_Lim | node_id |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Hop_Lim: 1-octet unsigned integer. It is set to the Hop Limit		Hop_Lim: 1-octet unsigned integer. It is set to the Hop Limit
	value in the packet at the node that records this data. Hop		value in the packet at the node that records this data. Hop
	Limit information is used to identify the location of the node		Limit information is used to identify the location of the node
	in the communication path. This is copied from the lower		in the communication path. This is copied from the lower
	layer, e.g., TTL value in IPv4 header or hop limit field from		layer, e.g., TTL value in IPv4 header or hop limit field from
	IPv6 header of the packet when the packet is ready for		IPv6 header of the packet when the packet is ready for
	transmission. The semantics of the Hop_Lim field depend on the		transmission. The semantics of the Hop_Lim field depend on the
	lower layer protocol that IOAM is encapsulated over, and		lower layer protocol that IOAM is encapsulated over, and
	therefore its specific semantics are outside the scope of this		therefore its specific semantics are outside the scope of this
	memo.		memo.
	node_id: 3-octet unsigned integer. Node identifier field to		node_id: 3-octet unsigned integer. Node identifier field to
	uniquely identify a node within in-situ OAM domain. The		uniquely identify a node within in-situ OAM domain. The
	procedure to allocate, manage and map the node_ids is beyond		procedure to allocate, manage and map the node_ids is beyond
	the scope of this document.		the scope of this document.
	ingress_if_id and egress_if_id: 4-octet field defined as follows:		ingress_if_id and egress_if_id: 4-octet field defined as follows:
	When this field is part of the data field but a node populating
	the field is not able to fill it, the position in the field must
	be filled with value 0xFFFFFFFF to mean not populated.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ingress_if_id | egress_if_id |		| ingress_if_id | egress_if_id |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	ingress_if_id: 2-octet unsigned integer. Interface identifier to		ingress_if_id: 2-octet unsigned integer. Interface identifier to
	record the ingress interface the packet was received on.		record the ingress interface the packet was received on.
	egress_if_id: 2-octet unsigned integer. Interface identifier to		egress_if_id: 2-octet unsigned integer. Interface identifier to
	record the egress interface the packet is forwarded out of.		record the egress interface the packet is forwarded out of.
	timestamp seconds: 4-octet unsigned integer. Absolute timestamp in		timestamp seconds: 4-octet unsigned integer. Absolute timestamp in
	seconds that specifies the time at which the packet was received		seconds that specifies the time at which the packet was received
	by the node. The structure of this field is identical to the most		by the node. This field has three possible formats; based on
	significant 32 bits of the 64 least significant bits of the		either PTP [IEEE1588v2], NTP [RFC5905], or POSIX [POSIX]. The
	[IEEE1588v2] timestamp. This truncated field consists of a 32-bit		three timestamp formats are specified in Section 5. In all three
	seconds field. As defined in [IEEE1588v2], the timestamp		cases, the Timestamp Seconds field contains the 32 most
	specifies the number of seconds elapsed since 1 January 1970		significant bits of the timestamp format that is specified in
	00:00:00 according to the International Atomic Time (TAI).		Section 5. If a node is not capable of populating this field, it
			assigns the value 0xFFFFFFFF. Note that this is a legitimate
	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		value that is valid for 1 second in approximately 136 years; the
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		analyzer should correlate several packets or compare the timestamp
	| timestamp seconds |		value to its own time-of-day in order to detect the error
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		indication.
	timestamp nanoseconds: 4-octet unsigned integer in the range 0 to
	10^9-1. This timestamp specifies the fractional part of the wall
	clock time at which the packet was received by the node in units
	of nanoseconds. This field is identical to the 32 least
	significant bits of the [IEEE1588v2] timestamp. This fields
	allows for delay computation between any two nodes in the network
	when the nodes are time synchronized. When this field is part of
	the data field but a node populating the field is not able to fill
	it, the field position in the field must be filled with value
	0xFFFFFFFF to mean not populated.
	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		timestamp subseconds: 4-octet unsigned integer. Absolute timestamp
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		in subseconds that specifies the time at which the packet was
	| timestamp nanoseconds |		received by the node. This field has three possible formats;
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		based on either PTP [IEEE1588v2], NTP [RFC5905], or POSIX [POSIX].
			The three timestamp formats are specified in Section 5. In all
			three cases, the Timestamp Subseconds field contains the 32 least
			significant bits of the timestamp format that is specified in
			Section 5. If a node is not capable of populating this field, it
			assigns the value 0xFFFFFFFF. Note that this is a legitimate
			value in the NTP format, valid for approximately 233 picoseconds
			in every second. If the NTP format is used the analyzer should
			correlate several packets in order to detect the error indication.
	transit delay: 4-octet unsigned integer in the range 0 to 2^31-1.		transit delay: 4-octet unsigned integer in the range 0 to 2^31-1.
	It is the time in nanoseconds the packet spent in the transit		It is the time in nanoseconds the packet spent in the transit
	node. This can serve as an indication of the queuing delay at the		node. This can serve as an indication of the queuing delay at the
	node. If the transit delay exceeds 2^31-1 nanoseconds then the		node. If the transit delay exceeds 2^31-1 nanoseconds then the
	top bit 'O' is set to indicate overflow and value set to		top bit 'O' is set to indicate overflow and value set to
	0x80000000. When this field is part of the data field but a node		0x80000000. When this field is part of the data field but a node
	populating the field is not able to fill it, the field position in		populating the field is not able to fill it, the field position in
	the field must be filled with value 0xFFFFFFFF to mean not		the field must be filled with value 0xFFFFFFFF to mean not
	populated.		populated.
	skipping to change at page 16, line 45 ¶		skipping to change at page 14, line 42 ¶
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| app_data |		| app_data |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	queue depth: 4-octet unsigned integer field. This field indicates		queue depth: 4-octet unsigned integer field. This field indicates
	the current length of the egress interface queue of the interface		the current length of the egress interface queue of the interface
	from where the packet is forwarded out. The queue depth is		from where the packet is forwarded out. The queue depth is
	expressed as the current number of memory buffers used by the		expressed as the current number of memory buffers used by the
	queue (a packet may consume one or more memory buffers, depending		queue (a packet may consume one or more memory buffers, depending
	on its size). When this field is part of the data field but a		on its size).
	node populating the field is not able to fill it, the field
	position in the field must be filled with value 0xFFFFFFFF to mean
	not populated.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| queue depth |		| queue depth |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Opaque State Snapshot: Variable length field. It allows the network		Opaque State Snapshot: Variable length field. It allows the network
	element to store an arbitrary state in the node data field ,		element to store an arbitrary state in the node data field ,
	without a pre-defined schema. The schema needs to be made known		without a pre-defined schema. The schema needs to be made known
	to the analyzer by some out-of-band mechanism. The specification		to the analyzer by some out-of-band mechanism. The specification
	skipping to change at page 17, line 32 ¶		skipping to change at page 15, line 23 ¶
	| Length | Schema ID |		| Length | Schema ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| |		| |
	| Opaque data |		| Opaque data |
	~ ~		~ ~
	. .		. .
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Length: 1-octet unsigned integer. It is the length in octets of		Length: 1-octet unsigned integer. It is the length in multiples
	the Opaque data field that follows Schema Id. It MUST always		of 4-octets of the Opaque data field that follows Schema Id.
	be a multiple of 4.
	Schema ID: 3-octet unsigned integer identifying the schema of		Schema ID: 3-octet unsigned integer identifying the schema of
	Opaque data.		Opaque data.
	Opaque data: Variable length field. This field is interpreted as		Opaque data: Variable length field. This field is interpreted as
	specified by the schema identified by the Schema ID.		specified by the schema identified by the Schema ID.
			When this field is part of the data field but a node populating
			the field has no opaque state data to report, the Length must be
			set to 0 and the Schema ID must be set to 0xFFFFFF to mean no
			schema.
	Hop_Lim and node_id wide: 8-octet field defined as follows:		Hop_Lim and node_id wide: 8-octet field defined as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Hop_Lim | node_id ~		| Hop_Lim | node_id ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ node_id (contd) |		~ node_id (contd) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Hop_Lim: 1-octet unsigned integer. It is set to the Hop Limit		Hop_Lim: 1-octet unsigned integer. It is set to the Hop Limit
	skipping to change at page 18, line 18 ¶		skipping to change at page 16, line 14 ¶
	depend on the lower layer protocol that IOAM is encapsulated		depend on the lower layer protocol that IOAM is encapsulated
	over, and therefore its specific semantics are outside the		over, and therefore its specific semantics are outside the
	scope of this memo.		scope of this memo.
	node_id: 7-octet unsigned integer. Node identifier field to		node_id: 7-octet unsigned integer. Node identifier field to
	uniquely identify a node within in-situ OAM domain. The		uniquely identify a node within in-situ OAM domain. The
	procedure to allocate, manage and map the node_ids is beyond		procedure to allocate, manage and map the node_ids is beyond
	the scope of this document.		the scope of this document.
	ingress_if_id and egress_if_id wide: 8-octet field defined as		ingress_if_id and egress_if_id wide: 8-octet field defined as
	follows: When this field is part of the data field but a node		follows:
	populating the field is not able to fill it, the field position in
	the field must be filled with value 0xFFFFFFFFFFFFFFFF to mean not
	populated.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ingress_if_id |		| ingress_if_id |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| egress_if_id |		| egress_if_id |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	ingress_if_id: 4-octet unsigned integer. Interface identifier to		ingress_if_id: 4-octet unsigned integer. Interface identifier to
	record the ingress interface the packet was received on.		record the ingress interface the packet was received on.
	skipping to change at page 18, line 50 ¶		skipping to change at page 16, line 43 ¶
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| app data ~		| app data ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ app data (contd) |		~ app data (contd) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Checksum Complement: 4-octet node data which contains a two-octet		Checksum Complement: 4-octet node data which contains a two-octet
	Checksum Complement field, and a 2-octet reserved field. The		Checksum Complement field, and a 2-octet reserved field. The
	Checksum Complement can be used when IOAM is transported over		Checksum Complement is useful when IOAM is transported over
	encapsulations that make use of a UDP transport, such as VXLAN-GPE		encapsulations that make use of a UDP transport, such as VXLAN-GPE
	or Geneve. In this case, incorporating the IOAM node data		or Geneve. Without the Checksum Complement, nodes adding IOAM
	requires the UDP Checksum field to be updated. Rather than to		node data must update the UDP Checksum field. When the Checksum
	recompute the Chekcsum field, a node can use the Checksum		Complement is present, an IOAM encapsulating node or IOAM transit
	Complement to make a checksum-neutral update in the UDP payload;		node adding node data MUST carry out one of the following two
	the Checksum Complement is assigned a value that complements the		alternatives in order to maintain the correctness of the UDP
	rest of the node data fields that were added by the current node,		Checksum value:
	causing the existing UDP Checksum field to remain correct.
			1. Recompute the UDP Checksum field.
			2. Use the Checksum Complement to make a checksum-neutral update
			in the UDP payload; the Checksum Complement is assigned a
			value that complements the rest of the node data fields that
			were added by the current node, causing the existing UDP
			Checksum field to remain correct.
			IOAM decapsulating nodes MUST recompute the UDP Checksum field,
			since they do not know whether previous hops modified the UDP
			Checksum field or the Checksum Complement field.
	Checksum Complement fields are used in a similar manner in		Checksum Complement fields are used in a similar manner in
	[RFC7820] and [RFC7821].		[RFC7820] and [RFC7821].
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7		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
	8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Checksum Complement | Reserved |		| Checksum Complement | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	4.1.4. Examples of IOAM node data		4.1.3. Examples of IOAM node data
	An entry in the "node data list" array can have different formats,		An entry in the "node data list" array can have different formats,
	following the needs of the deployment. Some deployments might only		following the needs of the deployment. Some deployments might only
	be interested in recording the node identifiers, whereas others might		be interested in recording the node identifiers, whereas others might
	be interested in recording node identifier and timestamp. The		be interested in recording node identifier and timestamp. The
	section defines different types that an entry in "node data list" can		section defines different types that an entry in "node data list" can
	take.		take.
	0xD400: IOAM-Trace-Type is 0xD400 then the format of node data is:		0xD400: IOAM-Trace-Type is 0xD400 then the format of node data is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Hop_Lim | node_id |		| Hop_Lim | node_id |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ingress_if_id | egress_if_id |		| ingress_if_id | egress_if_id |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| timestamp nanoseconds |		| timestamp subseconds |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| app_data |		| app_data |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	0xC000: IOAM-Trace-Type is 0xC000 then the format is:		0xC000: IOAM-Trace-Type is 0xC000 then the format is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Hop_Lim | node_id |		| Hop_Lim | node_id |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ingress_if_id | egress_if_id |		| ingress_if_id | egress_if_id |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	0x9000: IOAM-Trace-Type is 0x9000 then the format is:		0x9000: IOAM-Trace-Type is 0x9000 then the format is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Hop_Lim | node_id |		| Hop_Lim | node_id |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| timestamp nanoseconds |		| timestamp subseconds |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	0x8400: IOAM-Trace-Type is 0x8400 then the format is:		0x8400: IOAM-Trace-Type is 0x8400 then the format is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Hop_Lim | node_id |		| Hop_Lim | node_id |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| app_data |		| app_data |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	0x9400: IOAM-Trace-Type is 0x9400 then the format is:		0x9400: IOAM-Trace-Type is 0x9400 then the format is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Hop_Lim | node_id |		| Hop_Lim | node_id |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| timestamp nanoseconds |		| timestamp subseconds |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| app_data |		| app_data |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	0x3180: IOAM-Trace-Type is 0x3180 then the format is:		0x3180: IOAM-Trace-Type is 0x3180 then the format is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| timestamp seconds |		| timestamp seconds |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| timestamp nanoseconds |		| timestamp subseconds |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Schema Id |		| Length | Schema Id |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| |		| |
	| Opaque data |		| Opaque data |
	~ ~		~ ~
	. .		. .
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 22, line 9 ¶		skipping to change at page 20, line 9 ¶
	o Random: Unique identifier for the packet (e.g., 64-bits allow for		o Random: Unique identifier for the packet (e.g., 64-bits allow for
	the unique identification of 2^64 packets).		the unique identification of 2^64 packets).
	o Cumulative: Information which is handed from node to node and		o Cumulative: Information which is handed from node to node and
	updated by every node according to a verification algorithm.		updated by every node according to a verification algorithm.
	IOAM proof of transit option:		IOAM proof of transit option:
	IOAM proof of transit option header:		IOAM proof of transit option header:
	0 1 2 3 4 5 6 7		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
	|IOAM POT Type|P|		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+		|IOAM POT Type | IOAM POT flags| Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	IOAM proof of transit option data MUST be 4-octet aligned:		IOAM proof of transit option data MUST be 4-octet aligned.:
	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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| POT Option data field determined by IOAM-POT-Type |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			IOAM POT Type: 8-bit identifier of a particular POT variant that
			specifies the POT data that is included. This document defines
			POT Type 0:
			0: POT data is a 16 Octet field as described below.
			IOAM POT flags: 8-bit. Following flags are defined:
			Bit 0 "Profile-to-use" (P-bit) (most significant bit). For IOAM
			POT types that use a maximum of two profiles to drive
			computation, indicates which POT-profile is used. The two
			profiles are numbered 0, 1.
			Bit 1-7 Reserved: Must be set to zero upon transmission and
			ignored upon receipt.
			Reserved: 16-bit Reserved bits are present for future use. The
			reserved bits Must be set to zero upon transmission and ignored
			upon receipt.
			POT Option data: Variable-length field. The type of which is
			determined by the IOAM-POT-Type.
			4.2.1. IOAM Proof of Transit Type 0
			IOAM proof of transit option of IOAM POT Type 0:
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|IOAM POT Type=0|P|R R R R R R R| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
	| Random | |		| Random | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P
	| Random(contd) | O		| Random(contd) | O
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T
	| Cumulative | |		| Cumulative | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Cumulative (contd) | |		| Cumulative (contd) | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
	IOAM POT Type: 7-bit identifier of a particular POT variant that		IOAM POT Type: 8-bit identifier of a particular POT variant that
	dictates the POT data that is included. This document defines POT		specifies the POT data that is included. This section defines the
	Type 0:		POT data when the IOAM POT Type is set to the value 0.
	0: POT data is a 16 Octet field as described below.		P bit: 1-bit. "Profile-to-use" (P-bit) (most significant bit).
			Indicates which POT-profile is used to generate the Cumulative.
			Any node participating in POT will have a maximum of 2 profiles
			configured that drive the computation of cumulative. The two
			profiles are numbered 0, 1. This bit conveys whether profile 0 or
			profile 1 is used to compute the Cumulative.
	Profile to use (P): 1-bit. Indicates which POT-profile is used to		R (7 bits): 7-bit IOAM POT flags for future use. MUST be set to
	generate the Cumulative. Any node participating in POT will have		zero upon transmission and ignored upon receipt.
	a maximum of 2 profiles configured that drive the computation of
	cumulative. The two profiles are numbered 0, 1. This bit conveys		Reserved: 16-bit Reserved bits are present for future use. The
	whether profile 0 or profile 1 is used to compute the Cumulative.		reserved bits Must be set to zero upon transmission and ignored
			upon receipt.
	Random: 64-bit Per packet Random number.		Random: 64-bit Per packet Random number.
	Cumulative: 64-bit Cumulative that is updated at specific nodes by		Cumulative: 64-bit Cumulative that is updated at specific nodes by
	processing per packet Random number field and configured		processing per packet Random number field and configured
	parameters.		parameters.
	Note: Larger or smaller sizes of "Random" and "Cumulative" data are		Note: Larger or smaller sizes of "Random" and "Cumulative" data are
	feasible and could be required for certain deployments (e.g. in case		feasible and could be required for certain deployments (e.g. in case
	of space constraints in the transport protocol used). Future		of space constraints in the transport protocol used). Future
	versions of this document will address different sizes of data for		versions of this document will address different sizes of data for
	"proof of transit".		"proof of transit".
	4.3. IOAM Edge-to-Edge Option		4.3. IOAM Edge-to-Edge Option
	The IOAM edge-to-edge option is to carry data that is added by the		The IOAM edge-to-edge option is to carry data that is added by the
	IOAM encapsulating node and interpreted by IOAM decapsulating node.		IOAM encapsulating node and interpreted by IOAM decapsulating node.
	The IOAM transit nodes MAY process the data without modifying it.		The IOAM transit nodes MAY process the data without modifying it.
	Currently only sequence numbers use the IOAM edge-to-edge option. In
	order to detect packet loss, packet reordering, or packet duplication
	in an in-situ OAM-domain, sequence numbers can be added to packets of
	a particular tube (see [I-D.hildebrand-spud-prototype]). Each tube
	leverages a dedicated namespace for its sequence numbers.
	IOAM edge-to-edge option:		IOAM edge-to-edge option:
	IOAM edge-to-edge option header:		IOAM edge-to-edge option header:
	0 1 2 3 4 5 6 7		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
	| IOAM-E2E-Type |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+		| IOAM-E2E-Type | Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	IOAM edge-to-edge option data MUST be 4-octet aligned:		IOAM edge-to-edge option data MUST be 4-octet aligned:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| E2E Option data field determined by IOAM-E2E-Type |		| E2E Option data field determined by IOAM-E2E-Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	IOAM-E2E-Type: 8-bit identifier of a particular in situ OAM E2E		IOAM-E2E-Type: A 16-bit identifier which specifies which data types
	variant.		are used in the E2E option data. The IOAM-E2E-Type value is a bit
			field. The order of packing the E2E option data field elements
			follows the bit order of the IOAM-E2E-Type field, as follows:
	0: E2E option data is a 64-bit sequence number added to a		Bit 0 (Most significant bit) When set indicates presence of a
	specific tube which is used to identify packet loss and		64-bit sequence number added to a specific tube which is
	reordering for that tube.		used to detect packet loss, packet reordering, or packet
			duplication for that tube. Each tube leverages a
			dedicated namespace for its sequence numbers.
	5. IOAM Data Export		Bit 1 When set indicates presence of a 32-bit sequence number
			added to a specific tube which is used to detect packet
			loss, packet reordering, or packet duplication for that
			tube. Each tube leverages a dedicated namespace for its
			sequence numbers.
			Bit 2 When set indicates presence of timestamp seconds for the
			transmission of the frame. This 4-octet field has three
			possible formats; based on either PTP [IEEE1588v2], NTP
			[RFC5905], or POSIX [POSIX]. The three timestamp formats
			are specified in Section 5. In all three cases, the
			Timestamp Seconds field contains the 32 most significant
			bits of the timestamp format that is specified in
			Section 5. If a node is not capable of populating this
			field, it assigns the value 0xFFFFFFFF. Note that this
			is a legitimate value that is valid for 1 second in
			approximately 136 years; the analyzer should correlate
			several packets or compare the timestamp value to its own
			time-of-day in order to detect the error indication.
			Bit 3 When set indicates presence of timestamp subseconds for
			the transmission of the frame. This 4-octet field has
			three possible formats; based on either PTP [IEEE1588v2],
			NTP [RFC5905], or POSIX [POSIX]. The three timestamp
			formats are specified in Section 5. In all three cases,
			the Timestamp Subseconds field contains the 32 least
			significant bits of the timestamp format that is
			specified in Section 5. If a node is not capable of
			populating this field, it assigns the value 0xFFFFFFFF.
			Note that this is a legitimate value in the NTP format,
			valid for approximately 233 picoseconds in every second.
			If the NTP format is used the analyzer should correlate
			several packets in order to detect the error indication.
			Bit 4-15 Undefined. An IOAM encapsulating node Must set the value
			of these bits to zero upon transmission and ignore upon
			receipt.
			Reserved: 16-bits Reserved bits are present for future use. The
			reserved bits Must be set to zero upon transmission and ignored
			upon receipt.
			E2E Option data: Variable-length field. The type of which is
			determined by the IOAM-E2E-Type.
			5. Timestamp Formats
			The IOAM data fields include a timestamp field which is represented
			in one of three possible timestamp formats. It is assumed that the
			management plane is responsible for determining which timestamp
			format is used.
			5.1. PTP Truncated Timestamp Format
			The Precision Time Protocol (PTP) [IEEE1588v2] uses an 80-bit
			timestamp format. The truncated timestamp format is a 64-bit field,
			which is the 64 least significant bits of the 80-bit PTP timestamp.
			The PTP truncated format is specified in Section 4.3 of
			[I-D.ietf-ntp-packet-timestamps], and the details are presented below
			for the sake of completeness.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Seconds |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Nanoseconds |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 1: PTP [IEEE1588] Truncated Timestamp Format
			Timestamp field format:
			Seconds: specifies the integer portion of the number of seconds
			since the epoch.
			+ Size: 32 bits.
			+ Units: seconds.
			Nanoseconds: specifies the fractional portion of the number of
			seconds since the epoch.
			+ Size: 32 bits.
			+ Units: nanoseconds. The value of this field is in the range 0
			to (10^9)-1.
			Epoch:
			The PTP [IEEE1588v2] epoch is 1 January 1970 00:00:00 TAI, which
			is 31 December 1969 23:59:51.999918 UTC.
			Resolution:
			The resolution is 1 nanosecond.
			Wraparound:
			This time format wraps around every 2^32 seconds, which is roughly
			136 years. The next wraparound will occur in the year 2106.
			Synchronization Aspects:
			It is assumed that nodes that run this protocol are synchronized
			among themselves. Nodes may be synchronized to a global reference
			time. Note that if PTP [IEEE1588v2] is used for synchronization,
			the timestamp may be derived from the PTP-synchronized clock,
			allowing the timestamp to be measured with respect to the clock of
			an PTP Grandmaster clock.
			The PTP truncated timestamp format is not affected by leap
			seconds.
			5.2. NTP 64-bit Timestamp Format
			The Network Time Protocol (NTP) [RFC5905] timestamp format is 64 bits
			long. This format is specified in Section 4.2.1 of
			[I-D.ietf-ntp-packet-timestamps], and the details are presented below
			for the sake of completeness.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Seconds |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Fraction |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 2: NTP [RFC5905] 64-bit Timestamp Format
			Timestamp field format:
			Seconds: specifies the integer portion of the number of seconds
			since the epoch.
			+ Size: 32 bits.
			+ Units: seconds.
			Fraction: specifies the fractional portion of the number of
			seconds since the epoch.
			+ Size: 32 bits.
			+ Units: the unit is 2^(-32) seconds, which is roughly equal to
			233 picoseconds.
			Epoch:
			The epoch is 1 January 1900 at 00:00 UTC.
			Resolution:
			The resolution is 2^(-32) seconds.
			Wraparound:
			This time format wraps around every 2^32 seconds, which is roughly
			136 years. The next wraparound will occur in the year 2036.
			Synchronization Aspects:
			Nodes that use this timestamp format will typically be
			synchronized to UTC using NTP [RFC5905]. Thus, the timestamp may
			be derived from the NTP-synchronized clock, allowing the timestamp
			to be measured with respect to the clock of an NTP server.
			The NTP timestamp format is affected by leap seconds; it
			represents the number of seconds since the epoch minus the number
			of leap seconds that have occurred since the epoch. The value of
			a timestamp during or slightly after a leap second may be
			temporarily inaccurate.
			5.3. POSIX-based Timestamp Format
			This timestamp format is based on the POSIX time format [POSIX]. The
			detailed specification of the timestamp format used in this document
			is presented below.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Seconds |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Microseconds |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 3: POSIX-based Timestamp Format
			Timestamp field format:
			Seconds: specifies the integer portion of the number of seconds
			since the epoch.
			+ Size: 32 bits.
			+ Units: seconds.
			Microseconds: specifies the fractional portion of the number of
			seconds since the epoch.
			+ Size: 32 bits.
			+ Units: the unit is microseconds. The value of this field is in
			the range 0 to (10^6)-1.
			Epoch:
			The epoch is 1 January 1970 00:00:00 TAI, which is 31 December
			1969 23:59:51.999918 UTC.
			Resolution:
			The resolution is 1 microsecond.
			Wraparound:
			This time format wraps around every 2^32 seconds, which is roughly
			136 years. The next wraparound will occur in the year 2106.
			Synchronization Aspects:
			It is assumed that nodes that use this timestamp format run Linux
			operating system, and hence use the POSIX time. In some cases
			nodes may be synchronized to UTC using a synchronization mechanism
			that is outside the scope of this document, such as NTP [RFC5905].
			Thus, the timestamp may be derived from the NTP-synchronized
			clock, allowing the timestamp to be measured with respect to the
			clock of an NTP server.
			The POSIX-based timestamp format is affected by leap seconds; it
			represents the number of seconds since the epoch minus the number
			of leap seconds that have occurred since the epoch. The value of
			a timestamp during or slightly after a leap second may be
			temporarily inaccurate.
			6. IOAM Data Export
	IOAM nodes collect information for packets traversing a domain that		IOAM nodes collect information for packets traversing a domain that
	supports IOAM. IOAM decapsulating nodes as well as IOAM transit		supports IOAM. IOAM decapsulating nodes as well as IOAM transit
	nodes can choose to retrieve IOAM information from the packet,		nodes can choose to retrieve IOAM information from the packet,
	process the information further and export the information using		process the information further and export the information using
	e.g., IPFIX.		e.g., IPFIX.
	The discussion of IOAM data processing and export is left for a		The discussion of IOAM data processing and export is left for a
	future version of this document.		future version of this document.
	6. IANA Considerations		7. IANA Considerations
	This document requests the following IANA Actions.		This document requests the following IANA Actions.
	6.1. Creation of a new In-Situ OAM Protocol Parameters Registry (IOAM)		7.1. Creation of a new In-Situ OAM Protocol Parameters Registry (IOAM)
	Protocol Parameters IANA registry		Protocol Parameters IANA registry
	IANA is requested to create a new protocol registry for "In-Situ OAM		IANA is requested to create a new protocol registry for "In-Situ OAM
	(IOAM) Protocol Parameters". This is the common registry that will		(IOAM) Protocol Parameters". This is the common registry that will
	include registrations for all IOAM namespaces. Each Registry, whose		include registrations for all IOAM namespaces. Each Registry, whose
	names are listed below:		names are listed below:
			IOAM Type
	IOAM Trace Type		IOAM Trace Type
	IOAM Trace flags		IOAM Trace flags
	IOAM POT Type		IOAM POT Type
			IOAM POT flags
	IOAM E2E Type		IOAM E2E Type
	will contain the current set of possibilities defined in this		will contain the current set of possibilities defined in this
	document. New registries in this name space are created via RFC		document. New registries in this name space are created via RFC
	Required process as per [RFC8126].		Required process as per [RFC8126].
	The subsequent sub-sections detail the registries herein contained.		The subsequent sub-sections detail the registries herein contained.
	6.2. IOAM Trace Type Registry		7.2. IOAM Type Registry
			This registry defines 128 code points for the IOAM-Type field for
			identifying IOAM options as explained in Section 4. The following
			code points are defined in this draft:
			0 IOAM Pre-allocated Trace Option Type
			1 IOAM Incremental Trace Option Type
			2 IOAM POT Option Type
			3 IOAM E2E Option Type
			4 - 127 are available for assignment via RFC Required process as per
			[RFC8126].
			7.3. IOAM Trace Type Registry
	This registry defines code point for each bit in the 16-bit IOAM-		This registry defines code point for each bit in the 16-bit IOAM-
	Trace-Type field for Pre-allocated trace option and Incremental trace		Trace-Type field for Pre-allocated trace option and Incremental trace
	option defined in Section 4.1. The meaning of Bit 0 - 11 for trace		option defined in Section 4.1. The meaning of Bit 0 - 11 for trace
	type are defined in this document in Paragraph 1 of (Section 4.1.1).		type are defined in this document in Paragraph 1 of (Section 4.1.1).
	The meaning for Bit 12 - 15 are available for assignment via RFC		The meaning for Bit 12 - 15 are available for assignment via RFC
	Required process as per [RFC8126].		Required process as per [RFC8126].
	6.3. IOAM Trace Flags Registry		7.4. IOAM Trace Flags Registry
	This registry defines code point for each bit in the 5 bit flags for		This registry defines code point for each bit in the 4 bit flags for
	Pre-allocated trace option and Incremental trace option defined in		Pre-allocated trace option and Incremental trace option defined in
	Section 4.1. The meaning of Bit 0 - 1 for trace flags are defined in		Section 4.1. The meaning of Bit 0 - 1 for trace flags are defined in
	this document in Paragraph 5 of Section 4.1.1. The meaning for Bit 2		this document in Paragraph 5 of Section 4.1.1. The meaning for Bit 2
	- 4 are available for assignment via RFC Required process as per		- 3 are available for assignment via RFC Required process as per
	[RFC8126].		[RFC8126].
	6.4. IOAM POT Type Registry		7.5. IOAM POT Type Registry
	This registry defines 128 code points to define IOAM POT Type for		This registry defines 256 code points to define IOAM POT Type for
	IOAM proof of transit option Section 4.2. The code point value 0 is		IOAM proof of transit option Section 4.2. The code point value 0 is
	defined in this document, 1 - 127 are available for assignment via		defined in this document, 1 - 255 are available for assignment via
	RFC Required process as per [RFC8126].		RFC Required process as per [RFC8126].
	6.5. IOAM E2E Type Registry		7.6. IOAM POT Flags Registry
	This registry defines 256 code points to define IOAM-E2E-Type for		This registry defines code point for each bit in the 8 bit flags for
	IOAM E2E option Section 4.3. The code point value 0 is defined in		IOAM POT option defined in Section 4.2. The meaning of Bit 0 for
	this document, 1 - 255 are available for assignments via RFC Required		IOAM POT flags is defined in this document in Section 4.2. The
			meaning for Bit 1 - 7 are available for assignment via RFC Required
	process as per [RFC8126].		process as per [RFC8126].
	7. Manageability Considerations		7.7. IOAM E2E Type Registry
			This registry defines code points for each bit in the 16 bit IOAM-
			E2E-Type field for IOAM E2E option Section 4.3. The meaning of Bit 0
			- 3 are defined in this document. The meaning of Bit 4 - 15 are
			available for assignments via RFC Required process as per [RFC8126].
			8. Manageability Considerations
	Manageability considerations will be addressed in a later version of		Manageability considerations will be addressed in a later version of
	this document..		this document..
	8. Security Considerations		9. Security Considerations
	Security considerations will be addressed in a later version of this		Security considerations will be addressed in a later version of this
	document. For a discussion of security requirements of in-situ OAM,		document.
	please refer to [I-D.brockners-inband-oam-requirements].
	9. Acknowledgements		10. Acknowledgements
	The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari		The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari
	Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya		Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya
	Nadahalli, LJ Wobker, Erik Nordmark, Vengada Prasad Govindan, and		Nadahalli, LJ Wobker, Erik Nordmark, Vengada Prasad Govindan, and
	Andrew Yourtchenko for the comments and advice.		Andrew Yourtchenko for the comments and advice.
	This document leverages and builds on top of several concepts		This document leverages and builds on top of several concepts
	described in [I-D.kitamura-ipv6-record-route]. The authors would		described in [I-D.kitamura-ipv6-record-route]. The authors would
	like to acknowledge the work done by the author Hiroshi Kitamura and		like to acknowledge the work done by the author Hiroshi Kitamura and
	people involved in writing it.		people involved in writing it.
	The authors would like to gracefully acknowledge useful review and		The authors would like to gracefully acknowledge useful review and
	insightful comments received from Joe Clarke, Al Morton, and Mickey		insightful comments received from Joe Clarke, Al Morton, and Mickey
	Spiegel.		Spiegel.
	10. References		11. References
	10.1. Normative References		11.1. Normative References
	[IEEE1588v2]		[IEEE1588v2]
	Institute of Electrical and Electronics Engineers,		Institute of Electrical and Electronics Engineers, "IEEE
	"1588-2008 - IEEE Standard for a Precision Clock		Std 1588-2008 - IEEE Standard for a Precision Clock
	Synchronization Protocol for Networked Measurement and		Synchronization Protocol for Networked Measurement and
	Control Systems", IEEE Std 1588-2008, 2008,		Control Systems", IEEE Std 1588-2008, 2008,
	<http://standards.ieee.org/findstds/		<http://standards.ieee.org/findstds/
	standard/1588-2008.html>.		standard/1588-2008.html>.
			[POSIX] Institute of Electrical and Electronics Engineers, "IEEE
			Std 1003.1-2008 (Revision of IEEE Std 1003.1-2004) - IEEE
			Standard for Information Technology - Portable Operating
			System Interface (POSIX(R))", IEEE Std 1003.1-2008, 2008,
			<https://standards.ieee.org/findstds/
			standard/1003.1-2008.html>.
	[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, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
			[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
			"Network Time Protocol Version 4: Protocol and Algorithms
			Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
			<https://www.rfc-editor.org/info/rfc5905>.
	[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>.
	10.2. Informative References		11.2. Informative References
	[I-D.brockners-inband-oam-requirements]
	Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
	Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi,
	T., <>, P., and r. remy@barefootnetworks.com,
	"Requirements for In-situ OAM", draft-brockners-inband-
	oam-requirements-03 (work in progress), March 2017.
	[I-D.brockners-inband-oam-transport]
	Brockners, F., Bhandari, S., Govindan, V., Pignataro, C.,
	Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes,
	D., Lapukhov, P., and R. Chang, "Encapsulations for In-
	situ OAM Data", draft-brockners-inband-oam-transport-05
	(work in progress), July 2017.
	[I-D.hildebrand-spud-prototype]		[I-D.hildebrand-spud-prototype]
	Hildebrand, J. and B. Trammell, "Substrate Protocol for		Hildebrand, J. and B. Trammell, "Substrate Protocol for
	User Datagrams (SPUD) Prototype", draft-hildebrand-spud-		User Datagrams (SPUD) Prototype", draft-hildebrand-spud-
	prototype-03 (work in progress), March 2015.		prototype-03 (work in progress), March 2015.
			[I-D.ietf-ntp-packet-timestamps]
			Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
			Defining Packet Timestamps", draft-ietf-ntp-packet-
			timestamps-00 (work in progress), October 2017.
	[I-D.ietf-nvo3-geneve]		[I-D.ietf-nvo3-geneve]
	Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic		Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
	Network Virtualization Encapsulation", draft-ietf-		Network Virtualization Encapsulation", draft-ietf-
	nvo3-geneve-05 (work in progress), September 2017.		nvo3-geneve-05 (work in progress), September 2017.
	[I-D.ietf-nvo3-vxlan-gpe]		[I-D.ietf-nvo3-vxlan-gpe]
	Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol		Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
	Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-04 (work		Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-05 (work
	in progress), April 2017.		in progress), October 2017.
	[I-D.ietf-sfc-nsh]		[I-D.ietf-sfc-nsh]
	Quinn, P., Elzur, U., and C. Pignataro, "Network Service		Quinn, P., Elzur, U., and C. Pignataro, "Network Service
	Header (NSH)", draft-ietf-sfc-nsh-27 (work in progress),		Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress),
	October 2017.		November 2017.
	[I-D.kitamura-ipv6-record-route]		[I-D.kitamura-ipv6-record-route]
	Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop		Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop
	Option Extension", draft-kitamura-ipv6-record-route-00		Option Extension", draft-kitamura-ipv6-record-route-00
	(work in progress), November 2000.		(work in progress), November 2000.
	[I-D.lapukhov-dataplane-probe]		[I-D.lapukhov-dataplane-probe]
	Lapukhov, P. and r. remy@barefootnetworks.com, "Data-plane		Lapukhov, P. and r. remy@barefootnetworks.com, "Data-plane
	probe for in-band telemetry collection", draft-lapukhov-		probe for in-band telemetry collection", draft-lapukhov-
	dataplane-probe-01 (work in progress), June 2016.		dataplane-probe-01 (work in progress), June 2016.
	skipping to change at page 28, line 19 ¶		skipping to change at page 33, line 4 ¶
	Email: shwethab@cisco.com		Email: shwethab@cisco.com
	Carlos Pignataro		Carlos Pignataro
	Cisco Systems, Inc.		Cisco Systems, Inc.
	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
	Hannes Gredler		Hannes Gredler
	RtBrick Inc.		RtBrick Inc.
	Email: hannes@rtbrick.com		Email: hannes@rtbrick.com
	John Leddy		John Leddy
	Comcast		Comcast
			United States
	Email: John_Leddy@cable.comcast.com		Email: John_Leddy@cable.comcast.com
	Stephen Youell		Stephen Youell
	JP Morgan Chase		JP Morgan Chase
	25 Bank Street		25 Bank Street
	London E14 5JP		London E14 5JP
	United Kingdom		United Kingdom
	Email: stephen.youell@jpmorgan.com		Email: stephen.youell@jpmorgan.com
	skipping to change at page 29, line 4 ¶		skipping to change at page 33, line 30 ¶
	Email: stephen.youell@jpmorgan.com		Email: stephen.youell@jpmorgan.com
	Tal Mizrahi		Tal Mizrahi
	Marvell		Marvell
	6 Hamada St.		6 Hamada St.
	Yokneam 2066721		Yokneam 2066721
	Israel		Israel
	Email: talmi@marvell.com		Email: talmi@marvell.com
	David Mozes		David Mozes
	Mellanox Technologies Ltd.
	Email: davidm@mellanox.com		Email: mosesster@gmail.com
	Petr Lapukhov		Petr Lapukhov
	Facebook		Facebook
	1 Hacker Way		1 Hacker Way
	Menlo Park, CA 94025		Menlo Park, CA 94025
	US		US
	Email: petr@fb.com		Email: petr@fb.com
	Remy Chang		Remy Chang
	Barefoot Networks		Barefoot Networks
	2185 Park Boulevard		4750 Patrick Henry Drive
	Palo Alto, CA 94306		Santa Clara, CA 95054
	US		US
	Daniel		Daniel Bernier
	Bell Canada		Bell Canada
			Canada
	Email: daniel.bernier@bell.ca		Email: daniel.bernier@bell.ca
			John Lemon
			Broadcom
			270 Innovation Drive
			San Jose, CA 95134
			US
			Email: john.lemon@broadcom.com
End of changes. 92 change blocks.
	347 lines changed or deleted		582 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/