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.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/