< draft-ietf-ippm-ioam-data-07.txt		draft-ietf-ippm-ioam-data-08.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: March 14, 2020 Cisco		Expires: April 26, 2020 Cisco
	H. Gredler		H. Gredler
	RtBrick Inc.		RtBrick Inc.
	J. Leddy		J. Leddy
	S. Youell		S. Youell
	JPMC		JPMC
	T. Mizrahi		T. Mizrahi
	Huawei Network.IO Innovation Lab		Huawei Network.IO Innovation Lab
	D. Mozes		D. Mozes
	P. Lapukhov		P. Lapukhov
	Facebook		Facebook
	R. Chang		R. Chang
	Barefoot Networks		Barefoot Networks
	D. Bernier		D. Bernier
	Bell Canada		Bell Canada
	J. Lemon		J. Lemon
	Broadcom		Broadcom
	September 11, 2019		October 24, 2019
	Data Fields for In-situ OAM		Data Fields for In-situ OAM
	draft-ietf-ippm-ioam-data-07		draft-ietf-ippm-ioam-data-08
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 14, 2020.		This Internet-Draft will expire on April 26, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 37 ¶		skipping to change at page 2, line 37 ¶
	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-Fields, Types, Nodes . . . . . . . . . . . . . . . 5		4. IOAM Data-Fields, Types, Nodes . . . . . . . . . . . . . . . 5
	4.1. IOAM Data-Fields and Option-Types . . . . . . . . . . . . 5		4.1. IOAM Data-Fields and Option-Types . . . . . . . . . . . . 5
	4.2. IOAM-Domains and types of IOAM Nodes . . . . . . . . . . 6		4.2. IOAM-Domains and types of IOAM Nodes . . . . . . . . . . 6
	4.3. IOAM-Namespaces . . . . . . . . . . . . . . . . . . . . . 7		4.3. IOAM-Namespaces . . . . . . . . . . . . . . . . . . . . . 7
	4.4. IOAM Trace Option-Types . . . . . . . . . . . . . . . . . 9		4.4. IOAM Trace Option-Types . . . . . . . . . . . . . . . . . 9
	4.4.1. Pre-allocated and Incremental Trace Option-Types . . 11		4.4.1. Pre-allocated and Incremental Trace Option-Types . . 12
	4.4.2. IOAM node data fields and associated formats . . . . 15		4.4.2. IOAM node data fields and associated formats . . . . 15
	4.4.3. Examples of IOAM node data . . . . . . . . . . . . . 21		4.4.3. Examples of IOAM node data . . . . . . . . . . . . . 21
	4.5. IOAM Proof of Transit Option-Type . . . . . . . . . . . . 23		4.5. IOAM Proof of Transit Option-Type . . . . . . . . . . . . 23
	4.5.1. IOAM Proof of Transit Type 0 . . . . . . . . . . . . 25		4.5.1. IOAM Proof of Transit Type 0 . . . . . . . . . . . . 25
	4.6. IOAM Edge-to-Edge Option-Type . . . . . . . . . . . . . . 26		4.6. IOAM Edge-to-Edge Option-Type . . . . . . . . . . . . . . 26
	5. Timestamp Formats . . . . . . . . . . . . . . . . . . . . . . 28		5. Timestamp Formats . . . . . . . . . . . . . . . . . . . . . . 28
	5.1. PTP Truncated Timestamp Format . . . . . . . . . . . . . 28		5.1. PTP Truncated Timestamp Format . . . . . . . . . . . . . 28
	5.2. NTP 64-bit Timestamp Format . . . . . . . . . . . . . . . 29		5.2. NTP 64-bit Timestamp Format . . . . . . . . . . . . . . . 29
	5.3. POSIX-based Timestamp Format . . . . . . . . . . . . . . 30		5.3. POSIX-based Timestamp Format . . . . . . . . . . . . . . 30
	6. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 32		6. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 32
	skipping to change at page 7, line 21 ¶		skipping to change at page 7, line 21 ¶
	An "IOAM transit node" updates one or more of the IOAM-Data-Fields.		An "IOAM transit node" updates one or more of the IOAM-Data-Fields.
	If both the Pre-allocated and the Incremental Trace Option-Types are		If both the Pre-allocated and the Incremental Trace Option-Types are
	present in the packet, each IOAM transit node will update at most one		present in the packet, each IOAM transit node will update at most one
	of these Option-Types. A transit node MUST NOT add new IOAM-Option-		of these Option-Types. A transit node MUST NOT add new IOAM-Option-
	Types to a packet, and MUST NOT change the IOAM-Data-Fields of an		Types to a packet, and MUST NOT change the IOAM-Data-Fields of an
	IOAM Edge-to-Edge Option-Type.		IOAM Edge-to-Edge Option-Type.
	An "IOAM decapsulating node" removes IOAM-Option-Type(s) from		An "IOAM decapsulating node" removes IOAM-Option-Type(s) from
	packets.		packets.
			The role of an IOAM-encapsulating, IOAM-transit or IOAM-decapsulating
			node is always performed within a specific IOAM-Namespace. This
			means that an IOAM node which is e.g. an IOAM-decapsulating node for
			IOAM-Namespace "A" but not for IOAM-Namespace "B" will only remove
			the IOAM-Option-Types for IOAM-Namespace "A" from the packet. An
			IOAM decapsulating node situated at the edge of an IOAM domain MUST
			remove all IOAM-Option-Types and associated encapsulation headers for
			all IOAM-Namespaces from the packet.
			IOAM-Namespaces allow for a namespace-specific definition and
			interpretation of IOAM-Data-Fields. An interface-id could for
			example point to a physical interface (e.g., to understand which
			physical interface of an aggregated link is used when receiving or
			transmitting a packet) whereas in another case it could refer to a
			logical interface (e.g., in case of tunnels). Please refer to
			Section 4.3 for details on IOAM-Namespaces.
	4.3. IOAM-Namespaces		4.3. IOAM-Namespaces
	A subset or all of the IOAM-Option-Types and their corresponding		A subset or all of the IOAM-Option-Types and their corresponding
	IOAM-Data-Fields can be associated to an IOAM-Namespace. IOAM-		IOAM-Data-Fields can be associated to an IOAM-Namespace. IOAM-
	Namespaces add further context to IOAM-Option-Types and associated		Namespaces add further context to IOAM-Option-Types and associated
	IOAM-Data-Fields. Any IOAM-Namespace MUST interpret the IOAM-Option-		IOAM-Data-Fields. Any IOAM-Namespace MUST interpret the IOAM-Option-
	Types and associated IOAM-Data-Fields per the definition in this		Types and associated IOAM-Data-Fields per the definition in this
	document. IOAM-Namespaces group nodes to support different		document. IOAM-Namespaces group nodes to support different
	deployment approaches of IOAM (see a few example use-cases below) as		deployment approaches of IOAM (see a few example use-cases below) as
	well as resolve issues which can occur due to IOAM-Data-Fields not		well as resolve issues which can occur due to IOAM-Data-Fields not
	skipping to change at page 10, line 51 ¶		skipping to change at page 11, line 21 ¶
	devices which either the Incremental Trace-Option or the Pre-		devices which either the Incremental Trace-Option or the Pre-
	allocated Trace-Option could result in both Option-Types being		allocated Trace-Option could result in both Option-Types being
	present in a packet. Given that the operator knows which equipment		present in a packet. Given that the operator knows which equipment
	is deployed in a particular IOAM, the operator will decide by means		is deployed in a particular IOAM, the operator will decide by means
	of configuration which type(s) of trace options will be used for a		of configuration which type(s) of trace options will be used for a
	particular domain.		particular domain.
	Every node data entry holds information for a particular IOAM transit		Every node data entry holds information for a particular IOAM transit
	node that is traversed by a packet. The IOAM decapsulating node		node that is traversed by a packet. The IOAM decapsulating node
	removes the IOAM-Option-Type(s) and processes and/or exports the		removes the IOAM-Option-Type(s) and processes and/or exports the
	associated data. IOAM-Data-Fields are defined in the context of an		associated data. Like all IOAM-Data-Fields, the IOAM-Data-Fields of
	IOAM-Namespace. This allows for a namespace-specific definition and		the IOAM-Trace-Option-Types are defined in the context of an IOAM-
	interpretation. For example: In one case an interface-id could point		Namespace.
	to a physical interface (e.g., to understand which physical interface
	of an aggregated link is used when receiving or transmitting a
	packet) whereas in another case it could refer to a logical interface
	(e.g., in case of tunnels).
	IOAM tracing can collect the following types of information:		IOAM tracing can collect the following types of information:
	o Identification of the IOAM node. An IOAM node identifier can		o Identification of the IOAM node. An IOAM node identifier can
	match to a device identifier or a particular control point or		match to a device identifier or a particular control point or
	subsystem within a device.		subsystem within a device.
	o Identification of the interface that a packet was received on,		o Identification of the interface that a packet was received on,
	i.e. ingress interface.		i.e. ingress interface.
	skipping to change at page 38, line 8 ¶		skipping to change at page 38, line 8 ¶
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-ntp-packet-timestamps]		[I-D.ietf-ntp-packet-timestamps]
	Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for		Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
	Defining Packet Timestamps", draft-ietf-ntp-packet-		Defining Packet Timestamps", draft-ietf-ntp-packet-
	timestamps-07 (work in progress), August 2019.		timestamps-07 (work in progress), August 2019.
	[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-13 (work in progress), March 2019.		nvo3-geneve-14 (work in progress), September 2019.
	[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-07 (work		Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-07 (work
	in progress), April 2019.		in progress), April 2019.
	[I-D.ietf-sfc-proof-of-transit]		[I-D.ietf-sfc-proof-of-transit]
	Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,		Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S.
	Leddy, J., Youell, S., Mozes, D., Mizrahi, T., Aguado, A.,		Youell, "Proof of Transit", draft-ietf-sfc-proof-of-
	and D. Lopez, "Proof of Transit", draft-ietf-sfc-proof-of-		transit-03 (work in progress), September 2019.
	transit-02 (work in progress), March 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.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 40, line 39 ¶		skipping to change at page 41, line 4 ¶
	Email: mosesster@gmail.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
	4750 Patrick Henry Drive		4750 Patrick Henry Drive
	Santa Clara, CA 95054		Santa Clara, CA 95054
	US		US
			Email: remy@barefootnetworks.com
	Daniel Bernier		Daniel Bernier
	Bell Canada		Bell Canada
	Canada		Canada
	Email: daniel.bernier@bell.ca		Email: daniel.bernier@bell.ca
	John Lemon		Jennifer Lemon
	Broadcom		Broadcom
	270 Innovation Drive		270 Innovation Drive
	San Jose, CA 95134		San Jose, CA 95134
	US		US
	Email: john.lemon@broadcom.com		Email: jennifer.lemon@broadcom.com
End of changes. 13 change blocks.
	19 lines changed or deleted		33 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/