draft-ietf-ippm-ioam-data-14.txt   draft-ietf-ippm-ioam-data-15.txt 
ippm F. Brockners, Ed. ippm F. Brockners, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track S. Bhandari, Ed. Intended status: Standards Track S. Bhandari, Ed.
Expires: December 26, 2021 Thoughtspot Expires: April 6, 2022 Thoughtspot
T. Mizrahi, Ed. T. Mizrahi, Ed.
Huawei Huawei
June 24, 2021 October 3, 2021
Data Fields for In-situ OAM Data Fields for In-situ OAM
draft-ietf-ippm-ioam-data-14 draft-ietf-ippm-ioam-data-15
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 in the network. This document discusses the data traverses a path in the network. This document discusses the data
fields and associated data types for in-situ OAM. In-situ OAM data fields and associated data types for in-situ OAM. In-situ OAM data
fields can be encapsulated into a variety of protocols such as NSH, fields can be encapsulated into a variety of protocols such as NSH,
Segment Routing, Geneve, or IPv6. In-situ OAM can be used to Segment Routing, Geneve, or IPv6. In-situ OAM can be used to
complement OAM mechanisms based on, e.g., ICMP or other types of complement OAM mechanisms based on, e.g., ICMP or other types of
skipping to change at page 1, line 40 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 December 26, 2021. This Internet-Draft will expire on April 6, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
5. IOAM Data-Fields, Types, Nodes . . . . . . . . . . . . . . . 6 5. IOAM Data-Fields, Types, Nodes . . . . . . . . . . . . . . . 6
5.1. IOAM Data-Fields and Option-Types . . . . . . . . . . . . 7 5.1. IOAM Data-Fields and Option-Types . . . . . . . . . . . . 7
5.2. IOAM-Domains and types of IOAM Nodes . . . . . . . . . . 7 5.2. IOAM-Domains and types of IOAM Nodes . . . . . . . . . . 7
5.3. IOAM-Namespaces . . . . . . . . . . . . . . . . . . . . . 9 5.3. IOAM-Namespaces . . . . . . . . . . . . . . . . . . . . . 9
5.4. IOAM Trace Option-Types . . . . . . . . . . . . . . . . . 11 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 . . . . 18 5.4.2. IOAM node data fields and associated formats . . . . 18
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 . . . . . . . . . 19 5.4.2.2. ingress_if_id and egress_if_id . . . . . . . . . 19
5.4.2.3. timestamp seconds . . . . . . . . . . . . . . . . 19 5.4.2.3. timestamp seconds . . . . . . . . . . . . . . . . 19
5.4.2.4. timestamp faction . . . . . . . . . . . . . . . . 20 5.4.2.4. timestamp fraction . . . . . . . . . . . . . . . 20
5.4.2.5. transit delay . . . . . . . . . . . . . . . . . . 20 5.4.2.5. transit delay . . . . . . . . . . . . . . . . . . 20
5.4.2.6. namespace specific data . . . . . . . . . . . . . 20 5.4.2.6. namespace specific data . . . . . . . . . . . . . 20
5.4.2.7. queue depth . . . . . . . . . . . . . . . . . . . 21 5.4.2.7. queue depth . . . . . . . . . . . . . . . . . . . 21
5.4.2.8. Checksum Complement . . . . . . . . . . . . . . . 21 5.4.2.8. Checksum Complement . . . . . . . . . . . . . . . 21
5.4.2.9. Hop_Lim and node_id wide . . . . . . . . . . . . 22 5.4.2.9. Hop_Lim and node_id wide . . . . . . . . . . . . 22
5.4.2.10. ingress_if_id and egress_if_id wide . . . . . . . 22 5.4.2.10. ingress_if_id and egress_if_id wide . . . . . . . 22
5.4.2.11. namespace specific data wide . . . . . . . . . . 22 5.4.2.11. namespace specific data wide . . . . . . . . . . 22
5.4.2.12. buffer occupancy . . . . . . . . . . . . . . . . 23 5.4.2.12. buffer occupancy . . . . . . . . . . . . . . . . 23
5.4.2.13. Opaque State Snapshot . . . . . . . . . . . . . . 23 5.4.2.13. Opaque State Snapshot . . . . . . . . . . . . . . 23
5.4.3. Examples of IOAM node data . . . . . . . . . . . . . 24 5.4.3. Examples of IOAM node data . . . . . . . . . . . . . 24
skipping to change at page 3, line 6 skipping to change at page 3, line 6
6.3. POSIX-based Timestamp Format . . . . . . . . . . . . . . 34 6.3. POSIX-based Timestamp Format . . . . . . . . . . . . . . 34
7. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 35 7. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 35
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
8.1. IOAM Option-Type Registry . . . . . . . . . . . . . . . . 36 8.1. IOAM Option-Type Registry . . . . . . . . . . . . . . . . 36
8.2. IOAM Trace-Type Registry . . . . . . . . . . . . . . . . 36 8.2. IOAM Trace-Type Registry . . . . . . . . . . . . . . . . 36
8.3. IOAM Trace-Flags Registry . . . . . . . . . . . . . . . . 37 8.3. IOAM Trace-Flags Registry . . . . . . . . . . . . . . . . 37
8.4. IOAM POT-Type Registry . . . . . . . . . . . . . . . . . 38 8.4. IOAM POT-Type Registry . . . . . . . . . . . . . . . . . 38
8.5. IOAM POT-Flags Registry . . . . . . . . . . . . . . . . . 38 8.5. IOAM POT-Flags Registry . . . . . . . . . . . . . . . . . 38
8.6. IOAM E2E-Type Registry . . . . . . . . . . . . . . . . . 39 8.6. IOAM E2E-Type Registry . . . . . . . . . . . . . . . . . 39
8.7. IOAM Namespace-ID Registry . . . . . . . . . . . . . . . 39 8.7. IOAM Namespace-ID Registry . . . . . . . . . . . . . . . 39
9. Management and Deployment Considerations . . . . . . . . . . 41 9. Management and Deployment Considerations . . . . . . . . . . 40
10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.1. Normative References . . . . . . . . . . . . . . . . . . 43 12.1. Normative References . . . . . . . . . . . . . . . . . . 43
12.2. Informative References . . . . . . . . . . . . . . . . . 44 12.2. Informative References . . . . . . . . . . . . . . . . . 44
Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 45 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
skipping to change at page 4, line 46 skipping to change at page 4, line 46
Geneve: Generic Network Virtualization Encapsulation [RFC8926] Geneve: Generic Network Virtualization Encapsulation [RFC8926]
IOAM: In-situ Operations, Administration, and Maintenance IOAM: In-situ Operations, Administration, and Maintenance
MTU: Maximum Transmit Unit MTU: Maximum Transmit Unit
NSH: Network Service Header [RFC8300] NSH: Network Service Header [RFC8300]
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
Short format: "Short format" refers to an IOAM-Data-Field which Short format: "Short format" refers to an IOAM-Data-Field which
comprises 4 octets. comprises 4 octets.
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]
skipping to change at page 5, line 42 skipping to change at page 5, line 40
protocols are outside the scope of this document. It is expected protocols are outside the scope of this document. It is expected
that each such encapsulation would be specified by an RFC, jointly that each such encapsulation would be specified by an RFC, jointly
designed by the working group that develops or maintains the designed by the working group that develops or maintains the
encapsulation protocol and the IETF IPPM working group. encapsulation protocol and the IETF IPPM working group.
Deployment domain (or scope) of in-situ OAM deployment: IOAM is Deployment domain (or scope) of in-situ OAM deployment: IOAM is
focused on "limited domains" as defined in [RFC8799]. For IOAM, a focused on "limited domains" as defined in [RFC8799]. For IOAM, a
limited domain could for example be an enterprise campus using limited domain could for example be 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 limited domain which uses IOAM is called an "IOAM domain". An IOAM A limited domain which uses IOAM may constitute one or multiple "IOAM
domain is bounded by its perimeter or edge. Designers of protocol domains", each disambiguated through separate namespace identifiers.
An IOAM domain is bounded by its perimeter or edge. IOAM domains may
overlap inside the limited domain. Designers of protocol
encapsulations for IOAM specify mechanisms to ensure that IOAM data encapsulations for IOAM specify mechanisms to ensure that IOAM data
stays within an IOAM domain. In addition, the operator of such a stays within an IOAM domain. In addition, the operator of such a
domain is expected to put provisions in place to ensure that IOAM domain is expected to put provisions in place to ensure that IOAM
data does not leak beyond the edge of an IOAM domain using, for data does not leak beyond the edge of an IOAM domain using, for
example, packet filtering methods. The operator has to consider the example, packet filtering methods. The operator SHOULD consider the
potential operational impact of IOAM to mechanisms such as ECMP potential operational impact of IOAM to mechanisms such as ECMP
processing (e.g. load-balancing schemes based on packet length could processing (e.g., load-balancing schemes based on packet length could
be impacted by the increased packet size due to IOAM), path MTU be impacted by the increased packet size due to IOAM), path MTU
(i.e., ensure that the MTU of all links within a domain is (i.e., ensure that the MTU of all links within a domain is
sufficiently large to support the increased packet size due to IOAM) sufficiently large to support the increased packet size due to IOAM)
and ICMP message handling (i.e., in case of IPv6, IOAM support for and ICMP message handling (i.e., in case of IPv6, IOAM support for
ICMPv6 Echo Request/Reply is desired which would translate into ICMPv6 Echo Request/Reply is desired which would translate into
ICMPv6 extensions to enable IOAM-Data-Fields to be copied from an ICMPv6 extensions to enable IOAM-Data-Fields to be copied from an
Echo Request message to an Echo Reply message). Echo Request message to an Echo Reply message).
IOAM control points: IOAM-Data-Fields are added to or removed from IOAM control points: IOAM-Data-Fields are added to or removed from
the user traffic by the devices which form the edge of a domain. the user traffic by the devices which form the edge of a domain.
skipping to change at page 20, line 9 skipping to change at page 20, line 9
[RFC5905], or POSIX [POSIX]. The three timestamp formats are [RFC5905], or POSIX [POSIX]. The three timestamp formats are
specified in Section 6. In all three cases, the Timestamp Seconds specified in Section 6. In all three cases, the Timestamp Seconds
field contains the 32 most significant bits of the timestamp format field contains the 32 most significant bits of the timestamp format
that is specified in Section 6. If a node is not capable of that is specified in Section 6. If a node is not capable of
populating this field, it assigns the value 0xFFFFFFFF. Note that populating this field, it assigns the value 0xFFFFFFFF. Note that
this is a legitimate value that is valid for 1 second in this is a legitimate value that is valid for 1 second in
approximately 136 years; the analyzer has to correlate several approximately 136 years; the analyzer has to correlate several
packets or compare the timestamp value to its own time-of-day in packets or compare the timestamp value to its own time-of-day in
order to detect the error indication. order to detect the error indication.
5.4.2.4. timestamp faction 5.4.2.4. timestamp fraction
The "timestamp fraction" field is a 4-octet unsigned integer field. The "timestamp fraction" field is a 4-octet unsigned integer field.
Fraction specifies the fractional portion of the number of seconds Fraction specifies the fractional portion of the number of seconds
since the NTP epoch [RFC8877]. The field specifies the time at which since the NTP epoch [RFC8877]. The field specifies the time at which
the packet was received by the node. This field has three possible the packet was received by the node. This field has three possible
formats; based on either PTP (see e.g., [RFC8877]), NTP [RFC5905], or formats; based on either PTP (see e.g., [RFC8877]), NTP [RFC5905], or
POSIX [POSIX]. The three timestamp formats are specified in POSIX [POSIX]. The three timestamp formats are specified in
Section 6. In all three cases, the Timestamp fraction field contains Section 6. In all three cases, the Timestamp fraction field contains
the 32 least significant bits of the timestamp format that is the 32 least significant bits of the timestamp format that is
specified in Section 6. If a node is not capable of populating this specified in Section 6. If a node is not capable of populating this
skipping to change at page 26, line 40 skipping to change at page 26, line 40
| | | |
| Opaque data | | Opaque data |
~ ~ ~ ~
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.5. IOAM Proof of Transit Option-Type 5.5. IOAM Proof of Transit Option-Type
IOAM Proof of Transit Option-Type is used to support path or service IOAM Proof of Transit Option-Type is used to support path or service
function chain [RFC7665] verification use cases. Proof-of-transit function chain [RFC7665] verification use cases. For further
leverages mechanisms like Shamir's Secret Sharing Schema (SSSS) information on Proof-of-transit, please refer to
[SSS]. For further information on Proof-of-transit, please refer to
[I-D.ietf-sfc-proof-of-transit]. While details on how the IOAM data [I-D.ietf-sfc-proof-of-transit]. While details on how the IOAM data
for the Proof-of-transit option is processed at IOAM encapsulating, for the Proof-of-transit option is processed at IOAM encapsulating,
decapsulating and transit nodes are outside the scope of the decapsulating and transit nodes are outside the scope of the
document, all of these approaches share the need to uniquely identify document, all of these approaches share the need to uniquely identify
a packet as well as iteratively operate on a set of information that a packet as well as iteratively operate on a set of information that
is handed from node to node. Correspondingly, two pieces of is handed from node to node. Correspondingly, two pieces of
information are added as IOAM-Data-Fields to the packet: information are added as IOAM-Data-Fields to the packet:
o PktID: Unique identifier for the packet. o PktID: Unique identifier for the packet.
skipping to change at page 36, line 6 skipping to change at page 36, line 6
IOAM Trace-Flags IOAM Trace-Flags
IOAM POT-Type IOAM POT-Type
IOAM POT-Flags IOAM POT-Flags
IOAM E2E-Type IOAM E2E-Type
IOAM Namespace-ID IOAM Namespace-ID
New registries in this group can be created via RFC Required process
as per [RFC8126].
The subsequent sub-sections detail the registries herein contained. The subsequent sub-sections detail the registries herein contained.
8.1. IOAM Option-Type Registry 8.1. IOAM Option-Type Registry
This registry defines 128 code points for the IOAM Option-Type field This registry defines 128 code points for the IOAM Option-Type field
for identifying IOAM Option-Types as explained in Section 5. The for identifying IOAM Option-Types as explained in Section 5. The
following code points are defined in this draft: following code points are defined in this draft:
0 IOAM Pre-allocated Trace Option-Type 0 IOAM Pre-allocated Trace Option-Type
skipping to change at page 43, line 22 skipping to change at page 43, line 20
Yourtchenko, Aviv Kfir, Tianran Zhou, Zhenbin (Robin) and Greg Mirsky Yourtchenko, Aviv Kfir, Tianran Zhou, Zhenbin (Robin) and Greg Mirsky
for the 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, Roman Danyliw, Benjamin Kaduk, Ian Swett, Carlos Bernardos, Haoyu Song, Mickey Spiegel, Roman Danyliw, Benjamin
Martin Duke, Francesca Palombini, Lars Eggert, Dan Romascanu and Kaduk, Murray S. Kucherawy, Ian Swett, Martin Duke, Francesca
Barak Gafni. Palombini, Lars Eggert, Alvaro Retana, Erik Kline, Robert Wilton,
Zaheduzzaman Sarker, Dan Romascanu and Barak Gafni.
12. References 12. References
12.1. Normative References 12.1. Normative References
[POSIX] Institute of Electrical and Electronics Engineers, "IEEE [POSIX] Institute of Electrical and Electronics Engineers, "IEEE
Std 1003.1-2017 (Revision of IEEE Std 1003.1-2017) - IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2017) - IEEE
Standard for Information Technology - Portable Operating Standard for Information Technology - Portable Operating
System Interface (POSIX(TM) Base Specifications, Issue System Interface (POSIX(TM) Base Specifications, Issue
7)", IEEE Std 1003.1-2017, 2017, 7)", IEEE Std 1003.1-2017, 2017,
skipping to change at page 44, line 14 skipping to change at page 44, line 14
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 12.2. Informative References
[I-D.brockners-ippm-ioam-data-integrity] [I-D.brockners-ippm-ioam-data-integrity]
Brockners, F., Bhandari, S., and T. Mizrahi, "Integrity of Brockners, F., Bhandari, S., and T. Mizrahi, "Integrity of
In-situ OAM Data Fields", draft-brockners-ippm-ioam-data- In-situ OAM Data Fields", draft-brockners-ippm-ioam-data-
integrity-01 (work in progress), February 2021. integrity-03 (work in progress), July 2021.
[I-D.brockners-opsawg-ioam-deployment] [I-D.brockners-opsawg-ioam-deployment]
Brockners, F., Bhandari, S., and D. Bernier, "In-situ OAM Brockners, F., Bhandari, S., Bernier, D., and T. Mizrahi,
Deployment", draft-brockners-opsawg-ioam-deployment-02 "In-situ OAM Deployment", draft-brockners-opsawg-ioam-
(work in progress), September 2020. deployment-03 (work in progress), June 2021.
[I-D.ietf-nvo3-vxlan-gpe] [I-D.ietf-nvo3-vxlan-gpe]
(Editor), F. M., (editor), L. K., and U. E. (editor), (Editor), F. M., (editor), L. K., and U. E. (editor),
"Generic Protocol Extension for VXLAN (VXLAN-GPE)", draft- "Generic Protocol Extension for VXLAN (VXLAN-GPE)", draft-
ietf-nvo3-vxlan-gpe-11 (work in progress), March 2021. ietf-nvo3-vxlan-gpe-12 (work in progress), September 2021.
[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-08 (work in progress), November 2020. transit-08 (work in progress), November 2020.
[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-04 (work in progress), draft-spiegel-ippm-ioam-rawexport-05 (work in progress),
November 2020. July 2021.
[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 45, line 43 skipping to change at page 45, line 43
[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>.
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation", "Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020, RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/info/rfc8926>. <https://www.rfc-editor.org/info/rfc8926>.
[SSS] Wikipedia, "Shamir's 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
Email: cpignata@cisco.com
Email: cpignata@cisco.com
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
Nvidia Nvidia
skipping to change at page 47, line 4 skipping to change at page 46, line 43
John Leddy John Leddy
United States United States
Email: john@leddy.net Email: john@leddy.net
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
David Mozes David Mozes
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
 End of changes. 24 change blocks. 
34 lines changed or deleted 29 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/