draft-song-ippm-postcard-based-telemetry-10.txt   draft-song-ippm-postcard-based-telemetry-11.txt 
IPPM H. Song IPPM H. Song
Internet-Draft Futurewei Technologies Internet-Draft Futurewei Technologies
Intended status: Informational G. Mirsky Intended status: Informational G. Mirsky
Expires: January 10, 2022 ZTE Corp. Expires: 19 May 2022 Ericsson
C. Filsfils C. Filsfils
A. Abdelsalam A. Abdelsalam
Cisco Systems, Inc. Cisco Systems, Inc.
T. Zhou T. Zhou
Z. Li Z. Li
Huawei Huawei
J. Shin J. Shin
SK Telecom SK Telecom
K. Lee K. Lee
LG U+ LG U+
July 9, 2021 15 November 2021
Postcard-based On-Path Flow Data Telemetry using Packet Marking In-Situ OAM Marking-based Direct Export
draft-song-ippm-postcard-based-telemetry-10 draft-song-ippm-postcard-based-telemetry-11
Abstract Abstract
The document describes a packet-marking variation of the Postcard- The document describes a packet-marking variation of the IOAM DEX
Based Telemetry (PBT), referred to as PBT-M. Similar to the option, referred to as IOAM Marking. Similar to IOAM DEX, IOAM
instruction-based PBT (i.e., IOAM DEX), PBT-M does not carry the Marking does not carry the telemetry data in user packets but send
telemetry data in user packets but send the telemetry data through a the telemetry data through a dedicated packet. Unlike IOAM DEX, IOAM
dedicated packet. Unlike the instruction-based PBT, PBT-M does not Marking does not require an extra instruction header. IOAM Marking
require an extra instruction header. PBT-M raises some unique issues raises some unique issues that need to be considered. This document
that need to be considered. This document formally describes the formally describes the high level scheme and cover the common
high level scheme and cover the common requirements and issues when requirements and issues when applying IOAM Marking in different
applying PBT-M in different networks. PBT-M is complementary to the networks. IOAM Marking is complementary to the other on-path
other on-path telemetry schemes such as IOAM. telemetry schemes such as IOAM trace and E2E options.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 10, 2022. This Internet-Draft will expire on 19 May 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. PBT-M: Marking-based PBT . . . . . . . . . . . . . . . . . . 3 2. IOAM Marking: Marking-based IOAM Direct Export . . . . . . . 3
3. New Challenges . . . . . . . . . . . . . . . . . . . . . . . 5 3. New Challenges . . . . . . . . . . . . . . . . . . . . . . . 5
4. PBT-M Design Considerations . . . . . . . . . . . . . . . . . 6 4. IOAM Marking Design Considerations . . . . . . . . . . . . . 6
4.1. Packet Marking . . . . . . . . . . . . . . . . . . . . . 6 4.1. Packet Marking . . . . . . . . . . . . . . . . . . . . . 6
4.2. Flow Path Discovery . . . . . . . . . . . . . . . . . . . 6 4.2. Flow Path Discovery . . . . . . . . . . . . . . . . . . . 6
4.3. Packet Identity for Export Data Correlation . . . . . . . 7 4.3. Packet Identity for Export Data Correlation . . . . . . . 7
4.4. Control the Load . . . . . . . . . . . . . . . . . . . . 7 4.4. Control the Load . . . . . . . . . . . . . . . . . . . . 8
5. Implementation Recommendation . . . . . . . . . . . . . . . . 8 5. Implementation Recommendation . . . . . . . . . . . . . . . . 8
5.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Postcard Format . . . . . . . . . . . . . . . . . . . . . 8 5.2. Postcard Format . . . . . . . . . . . . . . . . . . . . . 8
5.3. Data Correlation . . . . . . . . . . . . . . . . . . . . 8 5.3. Data Correlation . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
10. Informative References . . . . . . . . . . . . . . . . . . . 9 10. Informative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Motivation 1. Motivation
To gain detailed data plane visibility to support effective network To gain detailed data plane visibility to support effective network
OAM, it is essential to be able to examine the trace of user packets OAM, it is essential to be able to examine the trace of user packets
along their forwarding paths. Such on-path flow data reflect the along their forwarding paths. Such on-path flow data reflect the
state and status of each user packet's real-time experience and state and status of each user packet's real-time experience and
provide valuable information for network monitoring, measurement, and provide valuable information for network monitoring, measurement, and
diagnosis. diagnosis.
skipping to change at page 3, line 16 skipping to change at page 3, line 16
path, the timestamp/latency at each network node, and, in case of path, the timestamp/latency at each network node, and, in case of
packet drop, the drop location, and the reason. The emerging packet drop, the drop location, and the reason. The emerging
programmable data plane devices allow user-defined data collection or programmable data plane devices allow user-defined data collection or
conditional data collection based on trigger events. Such on-path conditional data collection based on trigger events. Such on-path
flow data are from and about the live user traffic, which complements flow data are from and about the live user traffic, which complements
the data acquired through other passive and active OAM mechanisms the data acquired through other passive and active OAM mechanisms
such as IPFIX [RFC7011] and ICMP [RFC2925]. such as IPFIX [RFC7011] and ICMP [RFC2925].
On-path telemetry was developed to cater to the need of collecting On-path telemetry was developed to cater to the need of collecting
on-path flow data. There are two basic modes for on-path telemetry: on-path flow data. There are two basic modes for on-path telemetry:
the passport mode and the postcard mode. In the passport mode, each the passport mode and the postcard mode. In the passport mode which
is represented by IOAM trace option [I-D.ietf-ippm-ioam-data], each
node on the path adds the telemetry data to the user packets (i.e., node on the path adds the telemetry data to the user packets (i.e.,
stamp the passport). The accumulated data-trace carried by user stamp the passport). The accumulated data-trace carried by user
packets are exported at a configured end node. In the postcard mode, packets are exported at a configured end node. In the postcard mode
each node directly exports the telemetry data using an independent which is represented by IOAM direct export option (DEX)
packet (i.e., send a postcard) to avoid the need for carrying the [I-D.ietf-ippm-ioam-direct-export], each node directly exports the
data with user packets. telemetry data using an independent packet (i.e., send a postcard) to
avoid carrying the data with user packets. The postcard mode is
The postcard mode is complementary to the passport mode. In the complementary to the passport mode.
variant of the postcard-based telemetry (PBT) which uses an
instruction header, the postcards that carry telemetry data can be
generated by a node's slow path and transported in-band or out-of-
band, independent of the original user packets. IOAM direct export
option (DEX) [I-D.ietf-ippm-ioam-direct-export] is a representative
of instruction-based PBT.
This document describes another variation of the postcard mode on- IOAM DEX uses an instruction header to explicitly instruct the
path telemetry, the marking-based PBT (PBT-M). Unlike the telemetry data to be collected. This document describes another
instruction-based PBT, PBT-M does not require a telemetry instruction variation of the postcard mode on-path telemetry, IOAM Marking.
header. However, PBT-M has unique issues that need to be considered. Unlike IOAM DEX, IOAM Marking does not require a telemetry
This document discusses the challenges and their solutions which are instruction header. However, IOAM Marking has unique issues that
common to the high-level scheme of PBT-M. need to be considered. This document discusses the challenges and
their solutions which are common to the high-level scheme of IOAM
Marking.
2. PBT-M: Marking-based PBT 2. IOAM Marking: Marking-based IOAM Direct Export
As the name suggests, PBT-M only needs a marking-bit in the existing As the name suggests, IOAM Marking only needs a marking-bit in the
headers of user packets to trigger the telemetry data collection and existing headers of user packets to trigger the telemetry data
export. The sketch of PBT-M is as follows. If on-path data need to collection and export. The sketch of IOAM Marking is as follows. If
be collected, the user packet is marked at the path head node. At on-path data need to be collected, the user packet is marked at the
each PBT-aware node, if the mark is detected, a postcard (i.e., the path head node. At each IOAM Marking-aware node, if the mark is
dedicated OAM packet triggered by a marked user packet) is generated detected, a postcard (i.e., the dedicated OAM packet triggered by a
and sent to a collector. The postcard contains the data requested by marked user packet) is generated and sent to a collector. The
the management plane. The requested data are configured by the postcard contains the data requested by the management plane. The
management plane. Once the collector receives all the postcards for requested data are configured by the management plane. Once the
a single user packet, it can infer the packet's forwarding path and collector receives all the postcards for a single user packet, it can
analyze the data set. The path end node is configured to unmark the infer the packet's forwarding path and analyze the data set. The
packets to its original format if necessary. path end node is configured to unmark the packets to its original
format if necessary.
The overall architecture of PBT-M is depicted in Figure 1. The overall architecture of IOAM Marking is depicted in Figure 1.
+------------+ +-----------+ +------------+ +-----------+
| Network | | Telemetry | | Network | | Telemetry |
| Management |(-------| Data | | Management |(-------| Data |
| | | Collector | | | | Collector |
+-----:------+ +-----------+ +-----:------+ +-----------+
: ^ : ^
:configurations |postcards :configurations |postcards
: |(OAM pkts) : |(OAM pkts)
...............:.....................|........ ...............:.....................|........
skipping to change at page 4, line 28 skipping to change at page 4, line 26
: | : | : | : | : | : | : | : |
V | V | V | V | V | V | V | V |
+------+-+ +-----+--+ +------+-+ +------+-+ +------+-+ +-----+--+ +------+-+ +------+-+
usr pkts | Head | | Path | | Path | | End | usr pkts | Head | | Path | | Path | | End |
====>| Node |====>| Node |====>| Node |====>| Node |===> ====>| Node |====>| Node |====>| Node |====>| Node |===>
| | | A | | B | | | | | | A | | B | | |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
mark usr pkts gen postcards gen postcards gen postcards mark usr pkts gen postcards gen postcards gen postcards
gen postcards unmark usr pkts gen postcards unmark usr pkts
Figure 1: Architecture of PBT-M Figure 1: Architecture of IOAM Marking
The advantages of PBT-M are summarized as follows. The advantages of IOAM Marking are summarized as follows.
o 1: PBT-M avoids augmenting user packets with new headers and the * 1: IOAM Marking avoids augmenting user packets with new headers
signaling for telemetry data collection remains in the data plane. and the signaling for telemetry data collection remains in the
data plane.
o 2: PBT-M is extensible for collecting arbitrary new data to * 2: IOAM Marking is extensible for collecting arbitrary new data to
support possible future use cases. The data set to be collected support possible future use cases. The data set to be collected
can be configured through the management plane or control plane. can be configured through the management plane or control plane.
o 3: PBT-M can avoid interfering with the normal forwarding. The * 3: IOAM Marking can avoid interfering with the normal forwarding.
collected data are free to be transported independently through The collected data are free to be transported independently
in-band or out-of-band channels. The data collecting, processing, through in-band or out-of-band channels. The data collecting,
assembly, encapsulation, and transport are, therefore, decoupled processing, assembly, encapsulation, and transport are, therefore,
from the forwarding of the corresponding user packets and can be decoupled from the forwarding of the corresponding user packets
performed in data-plane slow-path if necessary. and can be performed in data-plane slow-path if necessary.
o 4: For PBT-M, the types of data collected from each node can vary * 4: For IOAM Marking, the types of data collected from each node
depending on application requirements and node capability. can vary depending on application requirements and node
capability.
o 5: PBT-M makes it easy to secure the collected data without * 5: IOAM Marking makes it easy to secure the collected data without
exposing it to unnecessary entities. For example, both the exposing it to unnecessary entities. For example, both the
configuration and the telemetry data can be encrypted and/or configuration and the telemetry data can be encrypted and/or
authenticated before being transported, so passive eavesdropping authenticated before being transported, so passive eavesdropping
and a man-in-the-middle attack can both be deterred. and a man-in-the-middle attack can both be deterred.
o 6: Even if a user packet under inspection is dropped at some node * 6: Even if a user packet under inspection is dropped at some node
in the network, the postcards collected from the preceding nodes in the network, the postcards collected from the preceding nodes
are still valid and can be used to diagnose the packet drop are still valid and can be used to diagnose the packet drop
location and reason. location and reason.
3. New Challenges 3. New Challenges
Although PBT-M addresses the issues of the passport mode telemetry Although IOAM Marking has some unique features compared to the
and the instruction-based PBT, it introduces a few new challenges. passport mode telemetry and the instruction-based IOAM DEX, it
introduces a few new challenges.
o Challenge 1 (Packet Marking): A user packet needs to be marked to * Challenge 1 (Packet Marking): A user packet needs to be marked to
trigger the path-associated data collection. Since the PBT-M does trigger the path-associated data collection. Since IOAM Marking
not augment user packets with any new header fields, it needs to does not augment user packets with any new header fields, it needs
reserve or reuse bits from the existing header fields. This to reserve or reuse bits from the existing header fields. This
raises a similar issue as in the Alternate Marking Scheme raises a similar issue as in the Alternate Marking Scheme
[RFC8321] [RFC8321]
o Challenge 2 (Configuration): Since the packet header will not * Challenge 2 (Configuration): Since the packet header will not
carry OAM instructions anymore, the data plane devices need to be carry IOAM instructions anymore, the data plane devices need to be
configured to know what data to collect. However, in general, the configured to know what data to collect. However, in general, the
forwarding path of a flow packet (due to ECMP or dynamic routing) forwarding path of a flow packet (due to ECMP or dynamic routing)
is unknown beforehand (note that there are some notable is unknown beforehand (note that there are some notable
exceptions, such as segment routing). If the per-flow customized exceptions, such as segment routing). If the per-flow customized
data collection is required, configuring the data set for each data collection is required, configuring the data set for each
flow at all data plane devices might be expensive in terms of flow at all data plane devices might be expensive in terms of
configuration load and data plane resources. configuration load and data plane resources.
o Challenge 3 (Data Correlation): Due to the variable transport * Challenge 3 (Data Correlation): Due to the variable transport
latency, the dedicated postcard packets for a single packet may latency, the dedicated postcard packets for a single packet may
arrive at the collector out of order or be dropped in networks for arrive at the collector out of order or be dropped in networks for
some reason. In order to infer the packet forwarding path, the some reason. In order to infer the packet forwarding path, the
collector needs some information from the postcard packets to collector needs some information from the postcard packets to
identify the user packet affiliation and the order of path node identify the user packet affiliation and the order of path node
traversal. traversal.
o Challenge 4 (Load Overhead): Since each postcard packet has its * Challenge 4 (Load Overhead): Since each postcard packet has its
header, the overall network bandwidth overhead of PBT can be high. header, the overall network bandwidth overhead of IOAM Marking can
A large number of postcards could add processing pressure on data be high. A large number of postcards could add processing
collecting servers. That can be used as an attack vector for DoS. pressure on data collecting servers. That can be used as an
attack vector for DoS.
4. PBT-M Design Considerations 4. IOAM Marking Design Considerations
To address the above challenges, we propose several design details of To address the above challenges, we propose several design details of
PBT-M. IOAM Marking.
4.1. Packet Marking 4.1. Packet Marking
To trigger the path-associated data collection, usually, a single bit To trigger the path-associated data collection, usually, a single bit
from some header field is sufficient. While no such bit is from some header field is sufficient. While no such bit is
available, other packet-marking techniques are needed. We discuss available, other packet-marking techniques are needed. We discuss
several possible application scenarios. several possible application scenarios.
o IPv4. Alternate Marking (AM) [RFC8321] is an IP flow performance * IPv4. Alternate Marking (AM) [RFC8321] is an IP flow performance
measurement framework that also requires a single bit for packet measurement framework that also requires a single bit for packet
coloring. The difference is that AM does in-network measurement coloring. The difference is that AM does in-network measurement
while PBT-M only collects and exports data at network nodes (i.e., while IOAM Marking only collects and exports data at network nodes
the data analysis is done at the collector rather than in the (i.e., the data analysis is done at the collector rather than in
network nodes). AM suggests to use some reserved bit of the Flag the network nodes). AM suggests to use some reserved bit of the
field or some unused bit of the TOS field. Actually, AM can be Flag field or some unused bit of the TOS field. Actually, AM can
considered a sub-case of PBT-M, so that the same bit can be used be considered a sub-case of IOAM Marking, so that the same bit can
for PBT-M. The management plane is responsible for configuring be used for IOAM Marking. The management plane is responsible for
the actual operation mode. configuring the actual operation mode.
o SFC NSH. The OAM bit in the NSH header can be used to trigger the * SFC NSH. The OAM bit in the NSH header can be used to trigger the
on-path data collection [I-D.ietf-sfc-nsh]. PBT does not add any on-path data collection [RFC8300]. IOAM Marking does not add any
other metadata to NSH. other metadata to NSH.
o MPLS. Instead of choosing a header bit, we take advantage of the * MPLS. Instead of choosing a header bit, we take advantage of the
synonymous flow label [I-D.bryant-mpls-synonymous-flow-labels] synonymous flow label [I-D.bryant-mpls-synonymous-flow-labels]
approach to mark the packets. A synonymous flow label indicates approach to mark the packets. A synonymous flow label indicates
the on-path data should be collected and forwarded through a the on-path data should be collected and forwarded through a
postcard. postcard.
o SRv6: A flag bit in SRH can be reserved to trigger the on-path * SRv6: A flag bit in SRH can be reserved to trigger the on-path
data collection [I-D.song-6man-srv6-pbt]. SRv6 OAM data collection [I-D.song-6man-srv6-pbt]. SRv6 OAM
[I-D.ietf-6man-spring-srv6-oam] has adopted the O-bit in SRH flags [I-D.ietf-6man-spring-srv6-oam] has adopted the O-bit in SRH flags
as the marking bit to trigger the telemetry. as the marking bit to trigger the telemetry.
4.2. Flow Path Discovery 4.2. Flow Path Discovery
In case the path that a flow traverses is unknown in advance, all In case the path that a flow traverses is unknown in advance, all
PBT-aware nodes should be configured to react to the marked packets IOAM Marking-aware nodes should be configured to react to the marked
by exporting some basic data, such as node ID and TTL before a data packets by exporting some basic data, such as node ID and TTL before
set template for that flow is configured. This way, the management a data set template for that flow is configured. This way, the
plane can learn the flow path dynamically. management plane can learn the flow path dynamically.
If the management plane wants to collect the on-path data for some If the management plane wants to collect the on-path data for some
flow, it configures the head node(s) with a probability or time flow, it configures the head node(s) with a probability or time
interval for the flow packet marking. When the first marked packet interval for the flow packet marking. When the first marked packet
is forwarded in the network, the PBT-aware nodes will export the is forwarded in the network, the IOAM Marking-aware nodes will export
basic data set to the collector. Hence, the flow path is identified. the basic data set to the collector. Hence, the flow path is
If other data types need to be collected, the management plane can identified. If other data types need to be collected, the management
further configure the data set's template to the target nodes on the plane can further configure the data set's template to the target
flow's path. The PBT-aware nodes collect and export data accordingly nodes on the flow's path. The IOAM Marking-aware nodes collect and
if the packet is marked and a data set template is present. export data accordingly if the packet is marked and a data set
template is present.
If the flow path is changed for any reason, the new path can be If the flow path is changed for any reason, the new path can be
quickly learned by the collector. Consequently, the management plane quickly learned by the collector. Consequently, the management plane
controller can be directed to configure the nodes on the new path. controller can be directed to configure the nodes on the new path.
The outdated configuration can be automatically timed out or The outdated configuration can be automatically timed out or
explicitly revoked by the management plane controller. explicitly revoked by the management plane controller.
4.3. Packet Identity for Export Data Correlation 4.3. Packet Identity for Export Data Correlation
The collector needs to correlate all the postcard packets for a The collector needs to correlate all the postcard packets for a
skipping to change at page 7, line 48 skipping to change at page 8, line 7
the timestamp at each node can also infer the postcard affiliation. the timestamp at each node can also infer the postcard affiliation.
However, some errors may occur under some circumstances. For However, some errors may occur under some circumstances. For
example, two consecutive user packets from the same flows are marked, example, two consecutive user packets from the same flows are marked,
but one exported postcard from a node is lost. It is difficult for but one exported postcard from a node is lost. It is difficult for
the collector to decide to which user packet the remaining postcard the collector to decide to which user packet the remaining postcard
is related. In many cases, such a rare error has no catastrophic is related. In many cases, such a rare error has no catastrophic
consequence. Therefore it is tolerable. consequence. Therefore it is tolerable.
4.4. Control the Load 4.4. Control the Load
PBT-M should not be applied to all the packets all the time. It is IOAM Marking should not be applied to all the packets all the time.
better to be used in an interactive environment where the network It is better to be used in an interactive environment where the
telemetry applications dynamically decide which subset of traffic is network telemetry applications dynamically decide which subset of
under scrutiny. The network devices can limit the PBT rate through traffic is under scrutiny. The network devices can limit the packet
sampling and metering. The PBT packets can be distributed to marking rate through sampling and metering. The postcard packets can
different servers to balance the processing load. be distributed to different servers to balance the processing load.
It is important to understand that the total amount of data exported It is important to understand that the total amount of data exported
by PBT-M is identical to that of IOAM. The only extra overhead is by IOAM Marking is identical to that of IOAM trace option. The only
the packet header of the postcards. In the case of IOAM, it carries extra overhead is the packet header of the postcards. In the case of
the data from each node throughout the path to the end node before IOAM trace option, it carries the data from each node throughout the
exporting the aggregated data. On the other hand, PBT-M directly path to the end node before exporting the aggregated data. On the
exports local data. The overall network bandwidth impact depends on other hand, IOAM Marking directly exports local data. The overall
the network topology and scale, and PBT-M could be more bandwidth network bandwidth impact depends on the network topology and scale,
efficient. and in some cases IOAM Marking could be more bandwidth efficient.
5. Implementation Recommendation 5. Implementation Recommendation
5.1. Configuration 5.1. Configuration
The head node's ACL should be configured to filter out the target The head node's ACL should be configured to filter out the target
flows for telemetry data collection. Optionally, a flow packet flows for telemetry data collection. Optionally, a flow packet
sampling rate or probability could be configured to monitor a subset sampling rate or probability could be configured to monitor a subset
of the flow packets. of the flow packets.
The telemetry data set that should be exported by postcards at each The telemetry data set that should be exported by postcards at each
path node could be configured using the data set templates specified, path node could be configured using the data set templates specified,
for example, in IPFIX [RFC7011]. In future revisions, we will for example, in IPFIX [RFC7011]. In future revisions, we will
provide more details. provide more details.
The PBT-aware path nodes could be configured to respond or ignore the The IOAM Marking-aware path nodes could be configured to respond or
marked packets. ignore the marked packets.
5.2. Postcard Format 5.2. Postcard Format
The postcard should use the same data export format as that used by The postcard should use the same data export format as that used by
IOAM. [I-D.spiegel-ippm-ioam-rawexport] proposes a raw format that IOAM. [I-D.spiegel-ippm-ioam-rawexport] proposes a raw format that
can be interpreted by IPFIX. In future revisions, we will provide can be interpreted by IPFIX. In future revisions, we will provide
more details. more details.
5.3. Data Correlation 5.3. Data Correlation
skipping to change at page 9, line 9 skipping to change at page 9, line 18
correlate and order the postcards for a single user packet. correlate and order the postcards for a single user packet.
Section 4.3 provides several possible means. The application Section 4.3 provides several possible means. The application
scenario and network protocol are important factors to determine the scenario and network protocol are important factors to determine the
means to use. In future revisions, we will provide details for means to use. In future revisions, we will provide details for
representative applications. representative applications.
6. Security Considerations 6. Security Considerations
Several security issues need to be considered. Several security issues need to be considered.
o Eavesdrop and tamper: the postcards can be encrypted and * Eavesdrop and tamper: the postcards can be encrypted and
authenticated to avoid such security threats. authenticated to avoid such security threats.
o DoS attack: PBT can be limited to a single administrative domain. * DoS attack: IOAM Marking can be limited to a single administrative
The mark must be removed at the egress domain edge. The node can domain. The mark must be removed at the egress domain edge. The
rate-limit the extra traffic incurred by postcards. node can rate-limit the extra traffic incurred by postcards.
7. IANA Considerations 7. IANA Considerations
No requirement for IANA is identified. No requirement for IANA is identified.
8. Contributors 8. Contributors
We thank Alfred Morton who provided valuable suggestions and comments We thank Alfred Morton who provided valuable suggestions and comments
helping improve this draft. helping improve this draft.
9. Acknowledgments 9. Acknowledgments
TBD. TBD.
10. Informative References 10. Informative References
[I-D.bryant-mpls-synonymous-flow-labels] [I-D.bryant-mpls-synonymous-flow-labels]
Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen, Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen,
M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft- M., and Z. Li, "RFC6374 Synonymous Flow Labels", Work in
bryant-mpls-synonymous-flow-labels-01 (work in progress), Progress, Internet-Draft, draft-bryant-mpls-synonymous-
July 2015. flow-labels-01, 4 July 2015,
<https://www.ietf.org/archive/id/draft-bryant-mpls-
synonymous-flow-labels-01.txt>.
[I-D.ietf-6man-spring-srv6-oam] [I-D.ietf-6man-spring-srv6-oam]
Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M.
Chen, "Operations, Administration, and Maintenance (OAM) Chen, "Operations, Administration, and Maintenance (OAM)
in Segment Routing Networks with IPv6 Data plane (SRv6)", in Segment Routing Networks with IPv6 Data plane (SRv6)",
draft-ietf-6man-spring-srv6-oam-07 (work in progress), Work in Progress, Internet-Draft, draft-ietf-6man-spring-
July 2020. srv6-oam-11, 2 June 2021,
<https://www.ietf.org/archive/id/draft-ietf-6man-spring-
srv6-oam-11.txt>.
[I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
for In-situ OAM", Work in Progress, Internet-Draft, draft-
ietf-ippm-ioam-data-16, 8 November 2021,
<https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-
data-16.txt>.
[I-D.ietf-ippm-ioam-direct-export] [I-D.ietf-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-ietf-ippm-ioam-direct- OAM Direct Exporting", Work in Progress, Internet-Draft,
export-00 (work in progress), February 2020. draft-ietf-ippm-ioam-direct-export-07, 13 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-
[I-D.ietf-sfc-nsh] direct-export-07.txt>.
Quinn, P., Elzur, U., and C. Pignataro, "Network Service
Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress),
November 2017.
[I-D.song-6man-srv6-pbt] [I-D.song-6man-srv6-pbt]
Song, H., "Support Postcard-Based Telemetry for SRv6 OAM", Song, H., "Support Postcard-Based Telemetry for SRv6 OAM",
draft-song-6man-srv6-pbt-01 (work in progress), October Work in Progress, Internet-Draft, draft-song-6man-srv6-
2019. pbt-01, 14 October 2019, <https://www.ietf.org/archive/id/
draft-song-6man-srv6-pbt-01.txt>.
[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-01 (work in progress), Work in Progress, Internet-Draft, draft-spiegel-ippm-ioam-
October 2018. rawexport-05, 12 July 2021,
<https://www.ietf.org/archive/id/draft-spiegel-ippm-ioam-
rawexport-05.txt>.
[RFC2925] White, K., "Definitions of Managed Objects for Remote [RFC2925] White, K., "Definitions of Managed Objects for Remote
Ping, Traceroute, and Lookup Operations", RFC 2925, Ping, Traceroute, and Lookup Operations", RFC 2925,
DOI 10.17487/RFC2925, September 2000, DOI 10.17487/RFC2925, September 2000,
<https://www.rfc-editor.org/info/rfc2925>. <https://www.rfc-editor.org/info/rfc2925>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX) "Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77, Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013, RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>. <https://www.rfc-editor.org/info/rfc7011>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid "Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>. January 2018, <https://www.rfc-editor.org/info/rfc8321>.
Authors' Addresses Authors' Addresses
Haoyu Song Haoyu Song
Futurewei Technologies Futurewei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, 95050 Santa Clara, 95050,
USA United States of America
Email: hsong@futurewei.com Email: hsong@futurewei.com
Greg Mirsky Greg Mirsky
ZTE Corp. Ericsson
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Belgium Belgium
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Ahmed Abdelsalam Ahmed Abdelsalam
Cisco Systems, Inc. Cisco Systems, Inc.
Italy Italy
 End of changes. 53 change blocks. 
151 lines changed or deleted 170 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/