< draft-ietf-ippm-ioam-data-10.txt		draft-ietf-ippm-ioam-data-11.txt >
	ippm F. Brockners, Ed.		ippm F. Brockners, Ed.
	Internet-Draft S. Bhandari, Ed.		Internet-Draft S. Bhandari, Ed.
	Intended status: Standards Track Cisco		Intended status: Standards Track Cisco
	Expires: January 14, 2021 T. Mizrahi, Ed.		Expires: May 26, 2021 T. Mizrahi, Ed.
	Huawei		Huawei
	July 13, 2020		November 22, 2020
	Data Fields for In-situ OAM		Data Fields for In-situ OAM
	draft-ietf-ippm-ioam-data-10		draft-ietf-ippm-ioam-data-11
	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 encapsulated into a variety of		In-situ OAM data fields can be encapsulated into a variety of
	protocols such as NSH, Segment Routing, Geneve, IPv6 (via extension		protocols such as NSH, Segment Routing, Geneve, 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 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 14, 2021.		This Internet-Draft will expire on May 26, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Scope, Applicability, and Assumptions . . . . . . . . . . . . 5		4. Scope, Applicability, and Assumptions . . . . . . . . . . . . 5
	5. IOAM Data-Fields, Types, Nodes . . . . . . . . . . . . . . . 6		5. IOAM Data-Fields, Types, Nodes . . . . . . . . . . . . . . . 6
	5.1. IOAM Data-Fields and Option-Types . . . . . . . . . . . . 6		5.1. IOAM Data-Fields and Option-Types . . . . . . . . . . . . 6
	5.2. IOAM-Domains and types of IOAM Nodes . . . . . . . . . . 7		5.2. IOAM-Domains and types of IOAM Nodes . . . . . . . . . . 7
	5.3. IOAM-Namespaces . . . . . . . . . . . . . . . . . . . . . 8		5.3. IOAM-Namespaces . . . . . . . . . . . . . . . . . . . . . 8
	5.4. IOAM Trace Option-Types . . . . . . . . . . . . . . . . . 10		5.4. IOAM Trace Option-Types . . . . . . . . . . . . . . . . . 10
	5.4.1. Pre-allocated and Incremental Trace Option-Types . . 13		5.4.1. Pre-allocated and Incremental Trace Option-Types . . 13
	5.4.2. IOAM node data fields and associated formats . . . . 17		5.4.2. IOAM node data fields and associated formats . . . . 17
	5.4.2.1. Hop_Lim and node_id short format . . . . . . . . 17		5.4.2.1. Hop_Lim and node_id short format . . . . . . . . 18
	5.4.2.2. ingress_if_id and egress_if_id . . . . . . . . . 18		5.4.2.2. ingress_if_id and egress_if_id . . . . . . . . . 18
	5.4.2.3. timestamp seconds . . . . . . . . . . . . . . . . 18		5.4.2.3. timestamp seconds . . . . . . . . . . . . . . . . 19
	5.4.2.4. timestamp subseconds . . . . . . . . . . . . . . 18		5.4.2.4. timestamp subseconds . . . . . . . . . . . . . . 19
	5.4.2.5. transit delay . . . . . . . . . . . . . . . . . . 19		5.4.2.5. transit delay . . . . . . . . . . . . . . . . . . 19
	5.4.2.6. namespace specific data . . . . . . . . . . . . . 19		5.4.2.6. namespace specific data . . . . . . . . . . . . . 20
	5.4.2.7. queue depth . . . . . . . . . . . . . . . . . . . 19		5.4.2.7. queue depth . . . . . . . . . . . . . . . . . . . 20
	5.4.2.8. Checksum Complement . . . . . . . . . . . . . . . 20		5.4.2.8. Checksum Complement . . . . . . . . . . . . . . . 20
	5.4.2.9. Hop_Lim and node_id wide . . . . . . . . . . . . 20		5.4.2.9. Hop_Lim and node_id wide . . . . . . . . . . . . 21
	5.4.2.10. ingress_if_id and egress_if_id wide . . . . . . . 21		5.4.2.10. ingress_if_id and egress_if_id wide . . . . . . . 22
	5.4.2.11. namespace specific data wide . . . . . . . . . . 21		5.4.2.11. namespace specific data wide . . . . . . . . . . 22
	5.4.2.12. buffer occupancy . . . . . . . . . . . . . . . . 22		5.4.2.12. buffer occupancy . . . . . . . . . . . . . . . . 22
	5.4.2.13. Opaque State Snapshot . . . . . . . . . . . . . . 22		5.4.2.13. Opaque State Snapshot . . . . . . . . . . . . . . 23
	5.4.3. Examples of IOAM node data . . . . . . . . . . . . . 23		5.4.3. Examples of IOAM node data . . . . . . . . . . . . . 23
	5.5. IOAM Proof of Transit Option-Type . . . . . . . . . . . . 25		5.5. IOAM Proof of Transit Option-Type . . . . . . . . . . . . 25
	5.5.1. IOAM Proof of Transit Type 0 . . . . . . . . . . . . 27		5.5.1. IOAM Proof of Transit Type 0 . . . . . . . . . . . . 27
	5.6. IOAM Edge-to-Edge Option-Type . . . . . . . . . . . . . . 28		5.6. IOAM Edge-to-Edge Option-Type . . . . . . . . . . . . . . 28
	6. Timestamp Formats . . . . . . . . . . . . . . . . . . . . . . 30		6. Timestamp Formats . . . . . . . . . . . . . . . . . . . . . . 30
	6.1. PTP Truncated Timestamp Format . . . . . . . . . . . . . 30		6.1. PTP Truncated Timestamp Format . . . . . . . . . . . . . 30
	6.2. NTP 64-bit Timestamp Format . . . . . . . . . . . . . . . 31		6.2. NTP 64-bit Timestamp Format . . . . . . . . . . . . . . . 32
	6.3. POSIX-based Timestamp Format . . . . . . . . . . . . . . 33		6.3. POSIX-based Timestamp Format . . . . . . . . . . . . . . 33
	7. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 34		7. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 34
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	8.1. IOAM Option-Type Registry . . . . . . . . . . . . . . . . 35		8.1. IOAM Option-Type Registry . . . . . . . . . . . . . . . . 35
	8.2. IOAM Trace-Type Registry . . . . . . . . . . . . . . . . 35		8.2. IOAM Trace-Type Registry . . . . . . . . . . . . . . . . 36
	8.3. IOAM Trace-Flags Registry . . . . . . . . . . . . . . . . 36		8.3. IOAM Trace-Flags Registry . . . . . . . . . . . . . . . . 36
	8.4. IOAM POT-Type Registry . . . . . . . . . . . . . . . . . 36		8.4. IOAM POT-Type Registry . . . . . . . . . . . . . . . . . 37
	8.5. IOAM POT-Flags Registry . . . . . . . . . . . . . . . . . 36		8.5. IOAM POT-Flags Registry . . . . . . . . . . . . . . . . . 37
	8.6. IOAM E2E-Type Registry . . . . . . . . . . . . . . . . . 37		8.6. IOAM E2E-Type Registry . . . . . . . . . . . . . . . . . 37
	8.7. IOAM Namespace-ID Registry . . . . . . . . . . . . . . . 37		8.7. IOAM Namespace-ID Registry . . . . . . . . . . . . . . . 37
	9. Management and Deployment Considerations . . . . . . . . . . 38		9. Management and Deployment Considerations . . . . . . . . . . 38
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 38		10. Security Considerations . . . . . . . . . . . . . . . . . . . 38
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
	12.1. Normative References . . . . . . . . . . . . . . . . . . 40		12.1. Normative References . . . . . . . . . . . . . . . . . . 40
	12.2. Informative References . . . . . . . . . . . . . . . . . 40		12.2. Informative References . . . . . . . . . . . . . . . . . 41
	Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 42		Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 43
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
	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 being sent within		data is added to the data packets rather than being sent within
	packets specifically dedicated to OAM. IOAM is to complement		packets specifically dedicated to OAM. IOAM is to complement
	skipping to change at page 9, line 7 ¶		skipping to change at page 9, line 7 ¶
	(Namespace-ID). IOAM-Namespace identifiers MUST be present and		(Namespace-ID). IOAM-Namespace identifiers MUST be present and
	populated in all IOAM-Option-Types. The Namespace-ID value is		populated in all IOAM-Option-Types. The Namespace-ID value is
	divided into two sub-ranges:		divided into two sub-ranges:
	o An operator-assigned range from 0x0001 to 0x7FFF		o An operator-assigned range from 0x0001 to 0x7FFF
	o An IANA-assigned range from 0x8000 to 0xFFFF		o An IANA-assigned range from 0x8000 to 0xFFFF
	The IANA-assigned range is intended to allow future extensions to		The IANA-assigned range is intended to allow future extensions to
	have new and interoperable IOAM functionality, while the operator-		have new and interoperable IOAM functionality, while the operator-
	assigned range is intended to be domain specific, and managed by the		assigned range is intended to be domain specific, and managed by the
	network operator. The Namespace-ID value of 0x0000 is default and		network operator. The Namespace-ID value of 0x0000 is the "Default-
	known to all the nodes implementing IOAM.		Namespace-ID". The Default-Namespace-ID indicates that no specific
			namespace is associated with the IOAM data fields in the packet. The
			Default-Namespace-ID MUST be supported by all nodes implementing
			IOAM. A use-case for the Default-Namespace-ID are deployments which
			do not leverage specific namespaces for some or all of their packets
			that carry IOAM data fields.
	Namespace identifiers allow devices which are IOAM capable to		Namespace identifiers allow devices which are IOAM capable to
	determine:		determine:
	o whether IOAM-Option-Type(s) need to be processed by a device: If		o whether IOAM-Option-Type(s) need to be processed by a device: If
	the Namespace-ID contained in a packet does not match any		the Namespace-ID contained in a packet does not match any
	Namespace-ID the node is configured to operate on, then the node		Namespace-ID the node is configured to operate on, then the node
	MUST NOT change the contents of the IOAM-Data-Fields.		MUST NOT change the contents of the IOAM-Data-Fields.
	o which IOAM-Option-Type needs to be processed/updated in case there		o which IOAM-Option-Type needs to be processed/updated in case there
	skipping to change at page 10, line 39 ¶		skipping to change at page 10, line 45 ¶
	two IOAM-Namespaces, in a way that each IOAM-Namespace is		two IOAM-Namespaces, in a way that each IOAM-Namespace is
	represented by one of two IOAM-Option-Types in the packet.		represented by one of two IOAM-Option-Types in the packet.
	Each node would record data only for the IOAM-Namespace that it		Each node would record data only for the IOAM-Namespace that it
	belongs to, ignoring the other IOAM-Option-Type with a IOAM-		belongs to, ignoring the other IOAM-Option-Type with a IOAM-
	Namespace to which it doesn't belong. To retrieve a full view		Namespace to which it doesn't belong. To retrieve a full view
	of the deployment, the captured IOAM-Data-Fields of the two		of the deployment, the captured IOAM-Data-Fields of the two
	IOAM-Namespaces need to be correlated.		IOAM-Namespaces need to be correlated.
	5.4. IOAM Trace Option-Types		5.4. IOAM Trace Option-Types
	"IOAM tracing data" is expected to be either collected at every IOAM		"IOAM tracing data" is expected to be collected at every IOAM transit
	transit node that a packet traverses to ensure visibility into the		node that a packet traverses to ensure visibility into the entire
	entire path a packet takes within an IOAM-Domain. I.e., in a typical		path a packet takes within an IOAM-Domain. I.e., in a typical
	deployment all nodes in an IOAM-Domain would participate in IOAM and		deployment all nodes in an IOAM-Domain would participate in IOAM and
	thus be IOAM transit nodes, IOAM encapsulating or IOAM decapsulating		thus be IOAM transit nodes, IOAM encapsulating or IOAM decapsulating
	nodes. If not all nodes within a domain support IOAM functionality		nodes. If not all nodes within a domain support IOAM functionality
	as defined in this document, IOAM tracing information (i.e., node		as defined in this document, IOAM tracing information (i.e., node
	data, see below) will only be collected on those nodes which support		data, see below) will only be collected on those nodes which support
	IOAM functionality as defined in this document. Nodes which do not		IOAM functionality as defined in this document. Nodes which do not
	support IOAM functionality as defined in this document will forward		support IOAM functionality as defined in this document will forward
	the packet without any changes to the IOAM-Data-Fields. The maximum		the packet without any changes to the IOAM-Data-Fields. The maximum
	number of hops and the minimum path MTU of the IOAM domain is assumed		number of hops and the minimum path MTU of the IOAM domain is assumed
	to be known. An overflow indicator (O-bit) is defined as one of the		to be known. An overflow indicator (O-bit) is defined as one of the
	skipping to change at page 14, line 4 ¶		skipping to change at page 14, line 36 ¶
	~ ... ~ S		~ ... ~ S
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p
	| | a		| | a
	| node data list [n-1] | c		| node data list [n-1] | c
	| | e		| | e
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| | |		| | |
	| node data list [n] | |		| node data list [n] | |
	| | |		| | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
	Namespace-ID: 16-bit identifier of an IOAM-Namespace. The		Namespace-ID: 16-bit identifier of an IOAM-Namespace. The
	Namespace-ID value of 0x0000 is defined as the default value and		Namespace-ID value of 0x0000 is defined as the "Default-Namespace-
	MUST be known to all the nodes implementing IOAM. For any other		ID" (see Section 5.3) and MUST be known to all the nodes
	Namespace-ID value that does not match any Namespace-ID the node		implementing IOAM. For any other Namespace-ID value that does not
	is configured to operate on, the node MUST NOT change the contents		match any Namespace-ID the node is configured to operate on, the
	of the IOAM-Data-Fields.		node MUST NOT change the contents of the IOAM-Data-Fields.
	NodeLen: 5-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, excluding the		data added by each node in multiples of 4-octets, excluding the
	length of the "Opaque State Snapshot" field.		length of the "Opaque State Snapshot" field.
	If IOAM-Trace-Type bit 22 is not set, then NodeLen specifies the		If IOAM-Trace-Type bit 22 is not set, then NodeLen specifies the
	actual length added by each node. If IOAM-Trace-Type bit 22 is		actual length added by each node. If IOAM-Trace-Type bit 22 is
	set, then the actual length added by a node would be (NodeLen +		set, then the actual length added by a node would be (NodeLen +
	length of the "Opaque State Snapshot" field) in 4 octet units.		length of the "Opaque State Snapshot" field) in 4 octet units.
	skipping to change at page 26, line 23 ¶		skipping to change at page 26, line 35 ¶
	IOAM proof of transit Option-Type IOAM-Data-Fields MUST be		IOAM proof of transit Option-Type IOAM-Data-Fields MUST be
	4-octet aligned:		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 |		| POT Option data field determined by IOAM-POT-Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Namespace-ID: 16-bit identifier of an IOAM-Namespace. The		Namespace-ID: 16-bit identifier of an IOAM-Namespace. The
	Namespace-ID value of 0x0000 is defined as the default value and		Namespace-ID value of 0x0000 is defined as the "Default-Namespace-
	MUST be known to all the nodes implementing IOAM. For any other		ID" (see Section 5.3) and MUST be known to all the nodes
	Namespace-ID value that does not match any Namespace-ID the node		implementing IOAM. For any other Namespace-ID value that does not
	is configured to operate on, the node MUST NOT change the contents		match any Namespace-ID the node is configured to operate on, the
	of the IOAM-Data-Fields.		node MUST NOT change the contents of the IOAM-Data-Fields.
	IOAM POT Type: 8-bit identifier of a particular POT variant that		IOAM POT Type: 8-bit identifier of a particular POT variant that
	specifies the POT data that is included. This document defines		specifies the POT data that is included. This document defines
	POT Type 0:		POT Type 0:
	0: POT data is a 16 Octet field as described below.		0: POT data is a 16 Octet field as described below.
	If a node receives an IOAM POT Type value that it does not		If a node receives an IOAM POT Type value that it does not
	understand, the node MUST NOT change the contents of the IOAM-		understand, the node MUST NOT change the contents of the IOAM-
	Data-Fields.		Data-Fields.
	skipping to change at page 27, line 24 ¶		skipping to change at page 27, line 37 ¶
	| Random | |		| Random | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P
	| Random(contd) | O		| Random(contd) | O
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T
	| Cumulative | |		| Cumulative | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Cumulative (contd) | |		| Cumulative (contd) | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
	Namespace-ID: 16-bit identifier of an IOAM-Namespace. The		Namespace-ID: 16-bit identifier of an IOAM-Namespace. The
	Namespace-ID value of 0x0000 is defined as the default value and		Namespace-ID value of 0x0000 is defined as the "Default-Namespace-
	MUST be known to all the nodes implementing IOAM. For any other		ID" (see Section 5.3) and MUST be known to all the nodes
	Namespace-ID value that does not match any Namespace-ID the node		implementing IOAM. For any other Namespace-ID value that does not
	is configured to operate on, the node MUST NOT change the contents		match any Namespace-ID the node is configured to operate on, the
	of the IOAM-Data-Fields.		node MUST NOT change the contents of the IOAM-Data-Fields.
	IOAM POT Type: 8-bit identifier of a particular POT variant that		IOAM POT Type: 8-bit identifier of a particular POT variant that
	specifies the POT data that is included. This section defines the		specifies the POT data that is included. This section defines the
	POT data when the IOAM POT Type is set to the value 0.		POT data when the IOAM POT Type is set to the value 0.
	P bit: 1-bit. "Profile-to-use" (P-bit) (most significant bit).		P bit: 1-bit. "Profile-to-use" (P-bit) (most significant bit).
	Indicates which POT-profile is used to generate the Cumulative.		Indicates which POT-profile is used to generate the Cumulative.
	Any node participating in POT will have a maximum of 2 profiles		Any node participating in POT will have a maximum of 2 profiles
	configured that drive the computation of cumulative. The two		configured that drive the computation of cumulative. The two
	profiles are numbered 0, 1. This bit conveys whether profile 0 or		profiles are numbered 0, 1. This bit conveys whether profile 0 or
	skipping to change at page 28, line 38 ¶		skipping to change at page 29, line 4 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	IOAM Edge-to-Edge Option-Type IOAM-Data-Fields MUST		IOAM Edge-to-Edge Option-Type IOAM-Data-Fields MUST
	be 4-octet aligned:		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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Namespace-ID: 16-bit identifier of an IOAM-Namespace. The		Namespace-ID: 16-bit identifier of an IOAM-Namespace. The
	Namespace-ID value of 0x0000 is defined as the default value and		Namespace-ID value of 0x0000 is defined as the "Default-Namespace-
	MUST be known to all the nodes implementing IOAM. For any other		ID" (see Section 5.3) and MUST be known to all the nodes
	Namespace-ID value that does not match any Namespace-ID the node		implementing IOAM. For any other Namespace-ID value that does not
	is configured to operate on, then the node MUST NOT change the		match any Namespace-ID the node is configured to operate on, then
	contents of the IOAM-Data-Fields.		the node MUST NOT change the contents of the IOAM-Data-Fields.
	IOAM-E2E-Type: A 16-bit identifier which specifies which data types		IOAM-E2E-Type: A 16-bit identifier which specifies which data types
	are used in the E2E option data. The IOAM-E2E-Type value is a bit		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		field. The order of packing the E2E option data field elements
	follows the bit order of the IOAM-E2E-Type field, as follows:		follows the bit order of the IOAM-E2E-Type field, as follows:
	Bit 0 (Most significant bit) When set indicates presence of a		Bit 0 (Most significant bit) When set indicates presence of a
	64-bit sequence number added to a specific "packet group"		64-bit sequence number added to a specific "packet group"
	which is used to detect packet loss, packet reordering,		which is used to detect packet loss, packet reordering,
	or packet duplication within the group. The "packet		or packet duplication within the group. The "packet
	skipping to change at page 30, line 30 ¶		skipping to change at page 30, line 42 ¶
	The IOAM-Data-Fields include a timestamp field which is represented		The IOAM-Data-Fields include a timestamp field which is represented
	in one of three possible timestamp formats. It is assumed that the		in one of three possible timestamp formats. It is assumed that the
	management plane is responsible for determining which timestamp		management plane is responsible for determining which timestamp
	format is used.		format is used.
	6.1. PTP Truncated Timestamp Format		6.1. PTP Truncated Timestamp Format
	The Precision Time Protocol (PTP) [IEEE1588v2] uses an 80-bit		The Precision Time Protocol (PTP) [IEEE1588v2] uses an 80-bit
	timestamp format. The truncated timestamp format is a 64-bit field,		timestamp format. The truncated timestamp format is a 64-bit field,
	which is the 64 least significant bits of the 80-bit PTP timestamp.		which is the 64 least significant bits of the 80-bit PTP timestamp.
	The PTP truncated format is specified in Section 4.3 of		The PTP truncated format is specified in Section 4.3 of [RFC8877],
	[I-D.ietf-ntp-packet-timestamps], and the details are presented below		and the details are presented below for the sake of completeness.
	for the sake of completeness.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Seconds |		| Seconds |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Nanoseconds |		| Nanoseconds |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: PTP [IEEE1588v2] Truncated Timestamp Format		Figure 1: PTP [IEEE1588v2] Truncated Timestamp Format
	skipping to change at page 31, line 44 ¶		skipping to change at page 32, line 13 ¶
	the timestamp MAY be derived from the PTP-synchronized clock,		the timestamp MAY be derived from the PTP-synchronized clock,
	allowing the timestamp to be measured with respect to the clock of		allowing the timestamp to be measured with respect to the clock of
	an PTP Grandmaster clock.		an PTP Grandmaster clock.
	The PTP truncated timestamp format is not affected by leap		The PTP truncated timestamp format is not affected by leap
	seconds.		seconds.
	6.2. NTP 64-bit Timestamp Format		6.2. NTP 64-bit Timestamp Format
	The Network Time Protocol (NTP) [RFC5905] timestamp format is 64 bits		The Network Time Protocol (NTP) [RFC5905] timestamp format is 64 bits
	long. This format is specified in Section 4.2.1 of		long. This format is specified in Section 4.2.1 of [RFC8877], and
	[I-D.ietf-ntp-packet-timestamps], and the details are presented below		the details are presented below for the sake of completeness.
	for the sake of completeness.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Seconds |		| Seconds |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Fraction |		| Fraction |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: NTP [RFC5905] 64-bit Timestamp Format		Figure 2: NTP [RFC5905] 64-bit Timestamp Format
	skipping to change at page 39, line 37 ¶		skipping to change at page 40, line 9 ¶
	the operator. Indeed, in order to limit the scope of threats		the operator. Indeed, in order to limit the scope of threats
	mentioned above to within the current network domain the network		mentioned above to within the current network domain the network
	operator is expected to enforce policies that prevent IOAM traffic		operator is expected to enforce policies that prevent IOAM traffic
	from leaking outside of the IOAM domain, and prevent IOAM data from		from leaking outside of the IOAM domain, and prevent IOAM data from
	outside the domain to be processed and used within the domain.		outside the domain to be processed and used within the domain.
	The security considerations of a system that deploys IOAM, much like		The security considerations of a system that deploys IOAM, much like
	any system, has to be reviewed on a per-deployment-scenario basis,		any system, has to be reviewed on a per-deployment-scenario basis,
	based on a systems-specific threat analysis, which can lead to		based on a systems-specific threat analysis, which can lead to
	specific security solutions that are beyond the scope of the current		specific security solutions that are beyond the scope of the current
	document. For example, in an IOAM deployment that is not confined to		document. Specifically, in an IOAM deployment that is not confined
	a single LAN, but spans multiple inter-connected sites, the inter-		to a single LAN, but spans multiple inter-connected sites (for
	site links can be secured (e.g., by IPsec) in order to avoid external		example, using an overlay network), the inter-site links can be
	threats.		secured (e.g., by IPsec) in order to avoid external threats.
	11. Acknowledgements		11. 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, Andrew		Nadahalli, LJ Wobker, Erik Nordmark, Vengada Prasad Govindan, Andrew
	Yourtchenko, Aviv Kfir, Tianran Zhou and Zhenbin (Robin) for the		Yourtchenko, Aviv Kfir, Tianran Zhou and Zhenbin (Robin) for the
	comments and advice.		comments and advice.
	This document leverages and builds on top of several concepts		This document leverages and builds on top of several concepts
	skipping to change at page 40, line 50 ¶		skipping to change at page 41, line 25 ¶
	[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>.
	12.2. Informative References		12.2. Informative References
	[I-D.brockners-opsawg-ioam-deployment]		[I-D.brockners-opsawg-ioam-deployment]
	Brockners, F., Bhandari, S., and d.		Brockners, F., Bhandari, S., and d.
	daniel.bernier@bell.ca, "In-situ OAM Deployment", draft-		daniel.bernier@bell.ca, "In-situ OAM Deployment", draft-
	brockners-opsawg-ioam-deployment-01 (work in progress),		brockners-opsawg-ioam-deployment-02 (work in progress),
	March 2020.		September 2020.
	[I-D.ietf-ntp-packet-timestamps]
	Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
	Defining Packet Timestamps", draft-ietf-ntp-packet-
	timestamps-09 (work in progress), March 2020.
	[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-16 (work in progress), March 2020.		nvo3-geneve-16 (work in progress), March 2020.
	[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-09 (work		Extension for VXLAN (VXLAN-GPE)", draft-ietf-nvo3-vxlan-
	in progress), December 2019.		gpe-10 (work in progress), July 2020.
	[I-D.ietf-sfc-proof-of-transit]		[I-D.ietf-sfc-proof-of-transit]
	Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S.		Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S.
	Youell, "Proof of Transit", draft-ietf-sfc-proof-of-		Youell, "Proof of Transit", draft-ietf-sfc-proof-of-
	transit-06 (work in progress), June 2020.		transit-08 (work in progress), November 2020.
	[I-D.ioamteam-ippm-ioam-direct-export]		[I-D.ioamteam-ippm-ioam-direct-export]
	Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F.,		Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F.,
	Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ		Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ
	OAM Direct Exporting", draft-ioamteam-ippm-ioam-direct-		OAM Direct Exporting", draft-ioamteam-ippm-ioam-direct-
	export-00 (work in progress), October 2019.		export-00 (work in progress), October 2019.
	[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.spiegel-ippm-ioam-rawexport]		[I-D.spiegel-ippm-ioam-rawexport]
	Spiegel, M., Brockners, F., Bhandari, S., and R.		Spiegel, M., Brockners, F., Bhandari, S., and R.
	Sivakolundu, "In-situ OAM raw data export with IPFIX",		Sivakolundu, "In-situ OAM raw data export with IPFIX",
	draft-spiegel-ippm-ioam-rawexport-03 (work in progress),		draft-spiegel-ippm-ioam-rawexport-04 (work in progress),
	March 2020.		November 2020.
	[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.		[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
	Weingarten, "An Overview of Operations, Administration,		Weingarten, "An Overview of Operations, Administration,
	and Maintenance (OAM) Tools", RFC 7276,		and Maintenance (OAM) Tools", RFC 7276,
	DOI 10.17487/RFC7276, June 2014,		DOI 10.17487/RFC7276, June 2014,
	<https://www.rfc-editor.org/info/rfc7276>.		<https://www.rfc-editor.org/info/rfc7276>.
	[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in		[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
	Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,		Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
	October 2014, <https://www.rfc-editor.org/info/rfc7384>.		October 2014, <https://www.rfc-editor.org/info/rfc7384>.
	skipping to change at page 42, line 29 ¶		skipping to change at page 42, line 45 ¶
	[RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time		[RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time
	Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March		Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March
	2016, <https://www.rfc-editor.org/info/rfc7821>.		2016, <https://www.rfc-editor.org/info/rfc7821>.
	[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,		[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
	"Network Service Header (NSH)", RFC 8300,		"Network Service Header (NSH)", RFC 8300,
	DOI 10.17487/RFC8300, January 2018,		DOI 10.17487/RFC8300, January 2018,
	<https://www.rfc-editor.org/info/rfc8300>.		<https://www.rfc-editor.org/info/rfc8300>.
			[RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
			Defining Packet Timestamps", RFC 8877,
			DOI 10.17487/RFC8877, September 2020,
			<https://www.rfc-editor.org/info/rfc8877>.
	[SSS] Wikipedia, "Shamir's Secret Sharing",		[SSS] Wikipedia, "Shamir's Secret Sharing",
	<https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing>.		<https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing>.
	Contributors' Addresses		Contributors' Addresses
	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
End of changes. 31 change blocks.
	69 lines changed or deleted		72 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/