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/ |