< draft-ietf-ippm-ioam-data-11.txt		draft-ietf-ippm-ioam-data-12.txt >
	ippm F. Brockners, Ed.		ippm F. Brockners, Ed.
	Internet-Draft S. Bhandari, Ed.		Internet-Draft Cisco
	Intended status: Standards Track Cisco		Intended status: Standards Track S. Bhandari, Ed.
	Expires: May 26, 2021 T. Mizrahi, Ed.		Expires: August 25, 2021 Thoughtspot
			T. Mizrahi, Ed.
	Huawei		Huawei
	November 22, 2020		February 21, 2021
	Data Fields for In-situ OAM		Data Fields for In-situ OAM
	draft-ietf-ippm-ioam-data-11		draft-ietf-ippm-ioam-data-12
	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 40 ¶
	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 May 26, 2021.		This Internet-Draft will expire on August 25, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	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
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 21 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	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 . . . . . . . . . . . . . . . . . 11
	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 . . . . . . . . 18		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 . . . . . . . . . . . . . . . . 19		5.4.2.3. timestamp seconds . . . . . . . . . . . . . . . . 19
	5.4.2.4. timestamp subseconds . . . . . . . . . . . . . . 19		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 . . . . . . . . . . . . . 20		5.4.2.6. namespace specific data . . . . . . . . . . . . . 20
	5.4.2.7. queue depth . . . . . . . . . . . . . . . . . . . 20		5.4.2.7. queue depth . . . . . . . . . . . . . . . . . . . 20
	5.4.2.8. Checksum Complement . . . . . . . . . . . . . . . 20		5.4.2.8. Checksum Complement . . . . . . . . . . . . . . . 20
	skipping to change at page 3, line 12 ¶		skipping to change at page 3, line 13 ¶
	8.5. IOAM POT-Flags Registry . . . . . . . . . . . . . . . . . 37		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 . . . . . . . . . . . . . . . . . . . . . . 40		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
	12.1. Normative References . . . . . . . . . . . . . . . . . . 40		12.1. Normative References . . . . . . . . . . . . . . . . . . 40
	12.2. Informative References . . . . . . . . . . . . . . . . . 41		12.2. Informative References . . . . . . . . . . . . . . . . . 41
	Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 43		Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 43
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
	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
	mechanisms such as Ping or Traceroute. In terms of "active" or		mechanisms such as Ping or Traceroute. In terms of "active" or
	skipping to change at page 4, line 50 ¶		skipping to change at page 5, line 4 ¶
	OAM: Operations, Administration, and Maintenance		OAM: Operations, Administration, and Maintenance
	PMTU Path MTU		PMTU Path MTU
	POT: Proof of Transit		POT: Proof of Transit
	SFC: Service Function Chain		SFC: Service Function Chain
	SID: Segment Identifier		SID: Segment Identifier
	SR: Segment Routing		SR: Segment Routing
	VXLAN-GPE: Virtual eXtensible Local Area Network, Generic Protocol		VXLAN-GPE: Virtual eXtensible Local Area Network, Generic Protocol
	Extension [I-D.ietf-nvo3-vxlan-gpe]		Extension [I-D.ietf-nvo3-vxlan-gpe]
	4. Scope, Applicability, and Assumptions		4. Scope, Applicability, and Assumptions
	IOAM deployment assumes a set of constraints, requirements, and		IOAM deployment assumes a set of constraints, requirements, and
	guiding principles which are described in this section.		guiding principles which are described in this section.
	Scope: This document defines the data fields and associated data		Scope: This document defines the data fields and associated data
	types for in-situ OAM. The in-situ OAM data field can be		types for in-situ OAM. The in-situ OAM data field can be
	encapsulated in a variety of protocols, including NSH, Segment		encapsulated in a variety of protocols, including NSH, Segment
	Routing, Geneve, IPv6, or IPv4. Specification details for these		Routing, Geneve, IPv6, or IPv4. Specification details for these
	different protocols are outside the scope of this document.		different protocols are outside the scope of this document. It is
			expected that each such encapsulation will be defined in the relevant
			working group in the IETF.
	Deployment domain (or scope) of in-situ OAM deployment: IOAM is a		Deployment domain (or scope) of in-situ OAM deployment: IOAM is a
	network domain focused feature, with "network domain" being a set of		network domain focused feature, with "network domain" being a set of
	network devices or entities within a single administration. For		network devices or entities within a single administration. For
	example, a network domain can include an enterprise campus using		example, a network domain can include an enterprise campus using
	physical connections between devices or an overlay network using		physical connections between devices or an overlay network using
	virtual connections / tunnels for connectivity between said devices.		virtual connections / tunnels for connectivity between said devices.
	A network domain is defined by its perimeter or edge. Designers of		A network domain is defined by its perimeter or edge. Designers of
	protocol encapsulations for IOAM specify mechanisms to ensure that		protocol encapsulations for IOAM specify mechanisms to ensure that
	IOAM data stays within an IOAM domain. In addition, the operator of		IOAM data stays within an IOAM domain. In addition, the operator of
	skipping to change at page 22, line 46 ¶		skipping to change at page 22, line 46 ¶
	5.4.2.12. buffer occupancy		5.4.2.12. buffer occupancy
	The "buffer occupancy" field is a 4-octet unsigned integer field.		The "buffer occupancy" field is a 4-octet unsigned integer field.
	This field indicates the current status of the occupancy of the		This field indicates the current status of the occupancy of the
	common buffer pool used by a set of queues. The units of this field		common buffer pool used by a set of queues. The units of this field
	are implementation specific. Hence, the units are interpreted within		are implementation specific. Hence, the units are interpreted within
	the context of an IOAM-Namespace and/or node-id if used. The authors		the context of an IOAM-Namespace and/or node-id if used. The authors
	acknowledge that in some operational cases there is a need for the		acknowledge that in some operational cases there is a need for the
	units to be consistent across a packet path through the network,		units to be consistent across a packet path through the network,
	hence RECOMMEND the implementations to use standard units such as		hence it is RECOMMENDED for implementations to use standard units
	Bytes.		such as Bytes.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| buffer occupancy |		| buffer occupancy |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	5.4.2.13. Opaque State Snapshot		5.4.2.13. Opaque State Snapshot
	The "Opaque State Snapshot" is a variable length field and follows		The "Opaque State Snapshot" is a variable length field and follows
	the fixed length IOAM-Data-Fields defined above. It allows the		the fixed length IOAM-Data-Fields defined above. It allows the
	skipping to change at page 38, line 8 ¶		skipping to change at page 38, line 8 ¶
	8.7. IOAM Namespace-ID Registry		8.7. IOAM Namespace-ID Registry
	IANA is requested to set up an "IOAM Namespace-ID Registry",		IANA is requested to set up an "IOAM Namespace-ID Registry",
	containing 16-bit values. The meaning of Bit 0 is defined in this		containing 16-bit values. The meaning of Bit 0 is defined in this
	document. IANA is requested to reserve the values 0x0001 to 0x7FFF		document. IANA is requested to reserve the values 0x0001 to 0x7FFF
	for private use (managed by operators), as specified in Section 5.3		for private use (managed by operators), as specified in Section 5.3
	of the current document. Registry entries for the values 0x8000 to		of the current document. Registry entries for the values 0x8000 to
	0xFFFF are to be assigned via the "Expert Review" policy defined in		0xFFFF are to be assigned via the "Expert Review" policy defined in
	[RFC8126]. Upon a new allocation request, the responsible AD will		[RFC8126]. Upon a new allocation request, the responsible AD will
	appoint a designated expert, who will review the allocation request.		appoint a designated expert, who will review the allocation request.
	The expert will post the request on the IPPM mailing list, and		The expert will post the request on the mailing list of the IPPM
	possibly on other relevant mailing lists, to allow for community		working group in the IETF (ippm@ietf.org), and possibly on other
	feedback. Based on the review, the expert will either approve or		relevant mailing lists, to allow for community feedback. Based on
	deny the request. The intention is that any allocation will be		the review, the expert will either approve or deny the request. The
	accompanied by a published RFC. But in order to allow for the		intention is that any allocation will be accompanied by a published
	allocation of values prior to the RFC being approved for publication,		RFC. But in order to allow for the allocation of values prior to the
	the designated expert can approve allocations once it seems clear		RFC being approved for publication, the designated expert can approve
	that an RFC will be published.		allocations once it seems clear that an RFC will be published.
	0: default namespace (known to all IOAM nodes)		0: default namespace (known to all IOAM nodes)
	0x0001 - 0x7FFF: reserved for private use		0x0001 - 0x7FFF: reserved for private use
	0x8000 - 0xFFFF: unassigned		0x8000 - 0xFFFF: unassigned
	9. Management and Deployment Considerations		9. Management and Deployment Considerations
	This document defines the structure and use of IOAM data fields.		This document defines the structure and use of IOAM data fields.
	skipping to change at page 39, line 35 ¶		skipping to change at page 39, line 35 ¶
	synchronization protocols then any attack on the time protocol		synchronization protocols then any attack on the time protocol
	[RFC7384] can compromise the integrity of the timestamp-related data		[RFC7384] can compromise the integrity of the timestamp-related data
	fields.		fields.
	At the management plane, attacks can be set up by misconfiguring or		At the management plane, attacks can be set up by misconfiguring or
	by maliciously configuring IOAM-enabled nodes in a way that enables		by maliciously configuring IOAM-enabled nodes in a way that enables
	other attacks. Thus, IOAM configuration has to be secured in a way		other attacks. Thus, IOAM configuration has to be secured in a way
	that authenticates authorized users and verifies the integrity of		that authenticates authorized users and verifies the integrity of
	configuration procedures.		configuration procedures.
			Solutions to ensure the integrity of IOAM data fields are outside the
			scope of this document. [I-D.brockners-ippm-ioam-data-integrity]
			discusses several methods to ensure the integrity of IOAM data fields
			for those deployments that have a need to protect the integrity of
			IOAM data fields.
	The current document does not define a specific IOAM encapsulation.		The current document does not define a specific IOAM encapsulation.
	It has to be noted that some IOAM encapsulation types can introduce		It has to be noted that some IOAM encapsulation types can introduce
	specific security considerations. A specification that defines an		specific security considerations. A specification that defines an
	IOAM encapsulation is expected to address the respective		IOAM encapsulation is expected to address the respective
	encapsulation-specific security considerations.		encapsulation-specific security considerations.
	Notably, in most cases IOAM is expected to be deployed in specific		Notably, in most cases IOAM is expected to be deployed in specific
	network domains, thus confining the potential attack vectors to		network domains, thus confining the potential attack vectors to
	within the network domain. A limited administrative domain provides		within the network domain. A limited administrative domain provides
	the operator with the means to select, monitor, and control the		the operator with the means to select, monitor, and control the
	skipping to change at page 40, line 14 ¶		skipping to change at page 40, line 18 ¶
	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. Specifically, in an IOAM deployment that is not confined		document. Specifically, in an IOAM deployment that is not confined
	to a single LAN, but spans multiple inter-connected sites (for		to a single LAN, but spans multiple inter-connected sites (for
	example, using an overlay network), the inter-site links can be		example, using an overlay network), the inter-site links can be
	secured (e.g., by IPsec) in order to avoid external threats.		secured (e.g., by IPsec) in order to avoid external threats.
			IOAM deployment considerations, including approaches to mitigate the
			above discussed threads and potential attacks are outside the scope
			of this document. IOAM deployment considerations are discussed in
			[I-D.brockners-opsawg-ioam-deployment].
	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, Zhenbin (Robin) and Greg Mirsky
	comments and advice.		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, Tom Herbert,		insightful comments received from Joe Clarke, Al Morton, Tom Herbert,
	Haoyu Song, Mickey Spiegel and Barak Gafni.		Haoyu Song, Mickey Spiegel and Barak Gafni.
	skipping to change at page 41, line 22 ¶		skipping to change at page 41, line 29 ¶
	Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,		Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
	<https://www.rfc-editor.org/info/rfc5905>.		<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>.
	12.2. Informative References		12.2. Informative References
			[I-D.brockners-ippm-ioam-data-integrity]
			Brockners, F., Bhandari, S., and T. Mizrahi, "Integrity of
			In-situ OAM Data Fields", draft-brockners-ippm-ioam-data-
			integrity-00 (work in progress), January 2021.
	[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-02 (work in progress),		brockners-opsawg-ioam-deployment-02 (work in progress),
	September 2020.		September 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.
	skipping to change at page 42, line 50 ¶		skipping to change at page 43, line 19 ¶
	[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		[RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
	Defining Packet Timestamps", RFC 8877,		Defining Packet Timestamps", RFC 8877,
	DOI 10.17487/RFC8877, September 2020,		DOI 10.17487/RFC8877, September 2020,
	<https://www.rfc-editor.org/info/rfc8877>.		<https://www.rfc-editor.org/info/rfc8877>.
	[SSS] Wikipedia, "Shamir's Secret Sharing",		[SSS] "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
	skipping to change at page 43, line 24 ¶		skipping to change at page 43, line 41 ¶
	Mickey Spiegel		Mickey Spiegel
	Barefoot Networks, an Intel company		Barefoot Networks, an Intel company
	4750 Patrick Henry Drive		4750 Patrick Henry Drive
	Santa Clara, CA 95054		Santa Clara, CA 95054
	US		US
	Email: mickey.spiegel@intel.com		Email: mickey.spiegel@intel.com
	Barak Gafni		Barak Gafni
	Mellanox Technologies, Inc.		Nvidia
	350 Oakmead Parkway, Suite 100		350 Oakmead Parkway, Suite 100
	Sunnyvale, CA 94085		Sunnyvale, CA 94085
	U.S.A.		U.S.A.
	Email: gbarak@mellanox.com		Email: gbarak@nvidia.com
	Jennifer Lemon		Jennifer Lemon
	Broadcom		Broadcom
	270 Innovation Drive		270 Innovation Drive
	San Jose, CA 95134		San Jose, CA 95134
	US		US
	Email: jennifer.lemon@broadcom.com		Email: jennifer.lemon@broadcom.com
	Hannes Gredler		Hannes Gredler
	skipping to change at page 45, line 4 ¶		skipping to change at page 45, line 21 ¶
	Authors' Addresses		Authors' Addresses
	Frank Brockners (editor)		Frank Brockners (editor)
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Hansaallee 249, 3rd Floor		Hansaallee 249, 3rd Floor
	DUESSELDORF, NORDRHEIN-WESTFALEN 40549		DUESSELDORF, NORDRHEIN-WESTFALEN 40549
	Germany		Germany
	Email: fbrockne@cisco.com		Email: fbrockne@cisco.com
	Shwetha Bhandari (editor)		Shwetha Bhandari (editor)
	Cisco Systems, Inc.		Thoughtspot
	Cessna Business Park, Sarjapura Marathalli Outer Ring Road		3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout
	Bangalore, KARNATAKA 560 087		Bangalore, KARNATAKA 560 102
	India		India
	Email: shwethab@cisco.com		Email: shwetha.bhandari@thoughtspot.com
	Tal Mizrahi (editor)		Tal Mizrahi (editor)
	Huawei		Huawei
	8-2 Matam		8-2 Matam
	Haifa 3190501		Haifa 3190501
	Israel		Israel
	Email: tal.mizrahi.phd@gmail.com		Email: tal.mizrahi.phd@gmail.com
End of changes. 22 change blocks.
	30 lines changed or deleted		50 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/