< draft-mirsky-ippm-hybrid-two-step-12.txt   draft-mirsky-ippm-hybrid-two-step-13.txt >
IPPM Working Group G. Mirsky IPPM Working Group G. Mirsky
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track W. Lingqiang Intended status: Standards Track W. Lingqiang
Expires: 30 July 2022 G. Zhui Expires: 27 October 2022 G. Zhui
ZTE Corporation ZTE Corporation
H. Song H. Song
Futurewei Technologies Futurewei Technologies
26 January 2022 P. Thubert
Cisco Systems, Inc
25 April 2022
Hybrid Two-Step Performance Measurement Method Hybrid Two-Step Performance Measurement Method
draft-mirsky-ippm-hybrid-two-step-12 draft-mirsky-ippm-hybrid-two-step-13
Abstract Abstract
Development of, and advancements in, automation of network operations Development of, and advancements in, automation of network operations
brought new requirements for measurement methodology. Among them is brought new requirements for measurement methodology. Among them is
the ability to collect instant network state as the packet being the ability to collect instant network state as the packet being
processed by the networking elements along its path through the processed by the networking elements along its path through the
domain. This document introduces a new hybrid measurement method, domain. This document introduces a new hybrid measurement method,
referred to as hybrid two-step, as it separates the act of measuring referred to as hybrid two-step, as it separates the act of measuring
and/or calculating the performance metric from the act of collecting and/or calculating the performance metric from the act of collecting
skipping to change at page 1, line 41 skipping to change at page 1, line 43
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 30 July 2022. This Internet-Draft will expire on 27 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 38 skipping to change at page 2, line 38
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6.1. IOAM Option-Type for HTS . . . . . . . . . . . . . . . . 13 6.1. IOAM Option-Type for HTS . . . . . . . . . . . . . . . . 13
6.2. HTS TLV Registry . . . . . . . . . . . . . . . . . . . . 13 6.2. HTS TLV Registry . . . . . . . . . . . . . . . . . . . . 13
6.3. HTS Sub-TLV Type Sub-registry . . . . . . . . . . . . . . 14 6.3. HTS Sub-TLV Type Sub-registry . . . . . . . . . . . . . . 14
6.4. HMAC Type Sub-registry . . . . . . . . . . . . . . . . . 15 6.4. HMAC Type Sub-registry . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Successful resolution of challenges of automated network operation, Successful resolution of challenges of automated network operation,
as part of, for example, overall service orchestration or data center as part of, for example, overall service orchestration or data center
operation, relies on a timely collection of accurate information that operation, relies on a timely collection of accurate information that
reflects the state of network elements on an unprecedented scale. reflects the state of network elements on an unprecedented scale.
Because performing the analysis and act upon the collected Because performing the analysis and act upon the collected
information requires considerable computing and storage resources, information requires considerable computing and storage resources,
the network state information is unlikely to be processed by the the network state information is unlikely to be processed by the
skipping to change at page 5, line 31 skipping to change at page 5, line 31
data for the part, most probably the latter part, of the path. data for the part, most probably the latter part, of the path.
In some networks, for example, wireless that are in the scope of In some networks, for example, wireless that are in the scope of
[I-D.ietf-raw-use-cases], it is beneficial to collect the telemetry, [I-D.ietf-raw-use-cases], it is beneficial to collect the telemetry,
including the calculated performance metrics, that reflects including the calculated performance metrics, that reflects
conditions experienced by the monitored flow at a node, other than conditions experienced by the monitored flow at a node, other than
the egress. For example, a head-end can optimize path selection the egress. For example, a head-end can optimize path selection
based on the compounded information that reflects network conditions, based on the compounded information that reflects network conditions,
resource utilization. This mode is referred to as the upstream resource utilization. This mode is referred to as the upstream
collection and the other - downstream collection to differentiate collection and the other - downstream collection to differentiate
between two modes of telemetry collection.. between two modes of telemetry collection.
4. Theory of Operation 4. Theory of Operation
The HTS method consists of two phases: The HTS method consists of two phases:
* performing a measurement and/or obtaining network state * performing a measurement and/or obtaining network state
information on a node; information on a node;
* collecting and transporting the measurement and/or the telemetry * collecting and transporting the measurement and/or the telemetry
information. information.
HTS may use an HTS Trigger carried in a data packet or a specially HTS may use an HTS Trigger carried in a data packet or a specially
constructed test packet. For example, an HTS Trigger could be a constructed test packet. For example, an HTS Trigger could be a
packet that has IOAM Option-Type set to the "IOAM Hybrid Two-Step packet that has IOAM Option-Type set to the "IOAM Hybrid Two-Step
Option-Type" value (TBA1) allocated by IANA (see Section 6.1). The Option-Type" value (TBA1) allocated by IANA (see Section 6.1). The
HTS Trigger also includes IOAM Namespace-ID and IOAM-Trace-Type HTS Trigger also includes IOAM Namespace-ID and IOAM-Trace-Type
information [I-D.ietf-ippm-ioam-data]. A packet in the flow to which information s defined in Section 5.3 and Section 5.4.1
the Alternate-Marking method [RFC8321] is applied can be used as an [I-D.ietf-ippm-ioam-data] respectively (shown in Figure 1). A packet
HTS Trigger. The nature of the HTS Trigger is a transport network in the flow to which the Alternate-Marking method, defined in
layer-specific, and its description is outside the scope of this [RFC8321] and [RFC8889], is applied can be used as an HTS Trigger.
document. The packet that includes the HTS Trigger in this document
is also referred to as the trigger packet. The nature of the HTS Trigger is a transport network layer-specific,
and its description is outside the scope of this document. The
packet that includes the HTS Trigger in this document is also
referred to as the trigger packet.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Hybrid Two-Step Trace IOAM Header
The HTS method uses the HTS Follow-up packet, referred to as the The HTS method uses the HTS Follow-up packet, referred to as the
follow-up packet, to collect measurement and network state data from follow-up packet, to collect measurement and network state data from
the nodes. The node that creates the HTS Trigger also generates the the nodes. The node that creates the HTS Trigger also generates the
HTS Follow-up packet. In some use cases, e.g., when HTS is used to HTS Follow-up packet. In some use cases, e.g., when HTS is used to
collect the telemetry, including performance metrics, calculated collect the telemetry, including performance metrics, calculated
based on a series of measurements, an HTS follow-up packet can be based on a series of measurements, an HTS follow-up packet can be
originated without using the HTS Trigger. The follow-up packet originated without using the HTS Trigger. The follow-up packet
contains characteristic information sufficient for participating HTS contains characteristic information sufficient for participating HTS
nodes to associate it with the monitored data flow. The nodes to associate it with the monitored data flow. The
skipping to change at page 7, line 18 skipping to change at page 7, line 22
the exception that the HTS Trigger packet does not precede the HTS the exception that the HTS Trigger packet does not precede the HTS
Follow-up packet. Follow-up packet.
4.1. Operation of the HTS Ingress Node 4.1. Operation of the HTS Ingress Node
A node that originates the HTS Trigger is referred to as the HTS A node that originates the HTS Trigger is referred to as the HTS
ingress node. As stated, the ingress node originates the follow-up ingress node. As stated, the ingress node originates the follow-up
packet. The follow-up packet has the transport network encapsulation packet. The follow-up packet has the transport network encapsulation
identical with the trigger packet followed by the HTS shim and one or identical with the trigger packet followed by the HTS shim and one or
more telemetry information elements encoded as Type-Length-Value more telemetry information elements encoded as Type-Length-Value
{TLV}. Figure 1 displays an example of the follow-up packet format. {TLV}. Figure 2 displays an example of the follow-up packet format.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Transport Network ~ ~ Transport Network ~
| Encapsulation | | Encapsulation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|HTS Shim L | Flags |Sequence Number| Reserved | |Ver|HTS Shim L | Flags |Sequence Number| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HTS Max Length | | HTS Max Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Telemetry Data Profile | | Telemetry Data Profile |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Telemetry Data TLVs ~ ~ Telemetry Data TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Follow-up Packet Format Figure 2: Follow-up Packet Format
Fields of the HTS shim are as follows: Fields of the HTS shim are as follows:
Version (Ver) is the two-bits long field. It specifies the Version (Ver) is the two-bits long field. It specifies the
version of the HTS shim format. This document defines the format version of the HTS shim format. This document defines the format
for the 0b00 value of the field. for the 0b00 value of the field.
HTS Shim Length is the six bits-long field. It defines the length HTS Shim Length is the six bits-long field. It defines the length
of the HTS shim in octets. The minimal value of the field is of the HTS shim in octets. The minimal value of the field is
eight octets. eight octets.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|F| Reserved | |F| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 2: Flags Field Format Figure 3: Flags Field Format
Flags is eight-bits long. The format of the Flags field displayed Flags is eight-bits long. The format of the Flags field displayed
in Figure 2. in Figure 3.
- Full (F) flag MUST be set to zero by the node originating the - Full (F) flag MUST be set to zero by the node originating the
HTS follow-up packet and MUST be set to one by the node that HTS follow-up packet and MUST be set to one by the node that
does not add its telemetry data to avoid exceeding MTU size. does not add its telemetry data to avoid exceeding MTU size.
- The node originating the follow-up packet MUST zero the - The node originating the follow-up packet MUST zero the
Reserved field and ignore it on the receipt. Reserved field and ignore it on the receipt.
Sequence Number is one octet-long field. The zero-based value of Sequence Number is one octet-long field. The zero-based value of
the field reflects the place of the HTS follow-up packet in the the field reflects the place of the HTS follow-up packet in the
skipping to change at page 9, line 4 skipping to change at page 9, line 12
[I-D.ietf-ippm-ioam-data] can be used in the Telemetry Data [I-D.ietf-ippm-ioam-data] can be used in the Telemetry Data
Profile field. Profile field.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length | | Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~ ~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Telemetry Data TLV Format
Figure 4: Telemetry Data TLV Format
Telemetry Data TLV is a variable-length field. Multiple TLVs MAY Telemetry Data TLV is a variable-length field. Multiple TLVs MAY
be placed in an HTS packet. Additional TLVs may be enclosed be placed in an HTS packet. Additional TLVs may be enclosed
within a given TLV, subject to the semantics of the (outer) TLV in within a given TLV, subject to the semantics of the (outer) TLV in
question. Figure 3 presents the format of a Telemetry Data TLV, question. Figure 4 presents the format of a Telemetry Data TLV,
where fields are defined as the following: where fields are defined as the following:
- Type - a one-octet-long field that characterizes the - Type - a one-octet-long field that characterizes the
interpretation of the Value field. interpretation of the Value field.
- Reserved - one-octet-long field. - Reserved - one-octet-long field.
- Length - two-octet-long field equal to the length of the Value - Length - two-octet-long field equal to the length of the Value
field in octets. field in octets.
skipping to change at page 12, line 14 skipping to change at page 12, line 17
5. Authentication in HTS 5. Authentication in HTS
Telemetry information may be used to drive network operation, closing Telemetry information may be used to drive network operation, closing
the control loop for self-driving, self-healing networks. Thus it is the control loop for self-driving, self-healing networks. Thus it is
critical to provide a mechanism to protect the telemetry information critical to provide a mechanism to protect the telemetry information
collected using the HTS method. This document defines an optional collected using the HTS method. This document defines an optional
authentication of a Telemetry Data TLV that protects the collected authentication of a Telemetry Data TLV that protects the collected
information's integrity. information's integrity.
The format of the Authentication sub-TLV is displayed in Figure 4. The format of the Authentication sub-TLV is displayed in Figure 5.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Authentic. Type| HMAC Type | Length | |Authentic. Type| HMAC Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Digest | | Digest |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: HMAC sub-TLV Figure 5: HMAC sub-TLV
where fields are defined as follows: where fields are defined as follows:
* Authentication Type - is a one-octet-long field, value TBA2 * Authentication Type - is a one-octet-long field, value TBA2
allocated by IANA Section 6.2. allocated by IANA Section 6.2.
* Length - two-octet-long field, set equal to the length of the * Length - two-octet-long field, set equal to the length of the
Digest field in octets. Digest field in octets.
* HMAC Type - is a one-octet-long field that identifies the type of * HMAC Type - is a one-octet-long field that identifies the type of
skipping to change at page 12, line 49 skipping to change at page 13, line 5
according to the HTS HMAC Type sub-registry (see Section 6.4). according to the HTS HMAC Type sub-registry (see Section 6.4).
* Digest - is a variable-length field that carries HMAC digest of * Digest - is a variable-length field that carries HMAC digest of
the text that includes the encompassing TLV. the text that includes the encompassing TLV.
This specification defines the use of HMAC-SHA-256 truncated to 128 This specification defines the use of HMAC-SHA-256 truncated to 128
bits ([RFC4868]) in HTS. Future specifications may define the use in bits ([RFC4868]) in HTS. Future specifications may define the use in
HTS of more advanced cryptographic algorithms or the use of digest of HTS of more advanced cryptographic algorithms or the use of digest of
a different length. HMAC is calculated as defined in [RFC2104] over a different length. HMAC is calculated as defined in [RFC2104] over
text as the concatenation of the Sequence Number field of the follow- text as the concatenation of the Sequence Number field of the follow-
up packet (see Figure 1) and the preceding data collected in the up packet (see Figure 2) and the preceding data collected in the
Telemetry Data TLV. The digest then MUST be truncated to 128 bits Telemetry Data TLV. The digest then MUST be truncated to 128 bits
and written into the Digest field. Distribution and management of and written into the Digest field. Distribution and management of
shared keys are outside the scope of this document. In the HTS shared keys are outside the scope of this document. In the HTS
authenticated mode, the Authentication sub-TLV MUST be present in authenticated mode, the Authentication sub-TLV MUST be present in
each Telemetry Data TLV. HMAC MUST be verified before using any data each Telemetry Data TLV. HMAC MUST be verified before using any data
in the included Telemetry Data TLV. If HMAC verification fails, the in the included Telemetry Data TLV. If HMAC verification fails, the
system MUST stop processing corresponding Telemetry Data TLV and system MUST stop processing corresponding Telemetry Data TLV and
notify an operator. Specification of the notification mechanism is notify an operator. Specification of the notification mechanism is
outside the scope of this document. outside the scope of this document.
skipping to change at page 17, line 32 skipping to change at page 17, line 32
[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", Work in Progress, Internet-Draft, OAM Direct Exporting", Work in Progress, Internet-Draft,
draft-ietf-ippm-ioam-direct-export-07, 13 October 2021, draft-ietf-ippm-ioam-direct-export-07, 13 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm- <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
ioam-direct-export-07>. ioam-direct-export-07>.
[I-D.ietf-raw-use-cases] [I-D.ietf-raw-use-cases]
Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J. Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F.
Bernardos, "RAW use cases", Work in Progress, Internet- Theoleyre, "RAW use-cases", Work in Progress, Internet-
Draft, draft-ietf-raw-use-cases-03, 20 October 2021, Draft, draft-ietf-raw-use-cases-05, 23 February 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-raw-use- <https://datatracker.ietf.org/doc/html/draft-ietf-raw-use-
cases-03>. cases-05>.
[I-D.song-ippm-postcard-based-telemetry] [I-D.song-ippm-postcard-based-telemetry]
Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou, Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou,
T., Li, Z., Shin, J., and K. Lee, "In-Situ OAM Marking- T., Li, Z., Shin, J., and K. Lee, "In-Situ OAM Marking-
based Direct Export", Work in Progress, Internet-Draft, based Direct Export", Work in Progress, Internet-Draft,
draft-song-ippm-postcard-based-telemetry-11, 15 November draft-song-ippm-postcard-based-telemetry-11, 15 November
2021, <https://datatracker.ietf.org/doc/html/draft-song- 2021, <https://datatracker.ietf.org/doc/html/draft-song-
ippm-postcard-based-telemetry-11>. ippm-postcard-based-telemetry-11>.
[P4.INT] "In-band Network Telemetry (INT)", P4.org Specification, [P4.INT] "In-band Network Telemetry (INT)", P4.org Specification,
skipping to change at page 18, line 46 skipping to change at page 18, line 46
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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto,
"Multipoint Alternate-Marking Method for Passive and
Hybrid Performance Monitoring", RFC 8889,
DOI 10.17487/RFC8889, August 2020,
<https://www.rfc-editor.org/info/rfc8889>.
Authors' Addresses Authors' Addresses
Greg Mirsky Greg Mirsky
Ericsson Ericsson
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com
Wang Lingqiang Wang Lingqiang
ZTE Corporation ZTE Corporation
No 19 ,East Huayuan Road No 19 ,East Huayuan Road
Beijing Beijing
Phone: +86 10 82963945 Phone: +86 10 82963945
Email: wang.lingqiang@zte.com.cn Email: wang.lingqiang@zte.com.cn
Guo Zhui Guo Zhui
ZTE Corporation ZTE Corporation
No 19 ,East Huayuan Road No 19 ,East Huayuan Road
Beijing Beijing
Phone: +86 10 82963945 Phone: +86 10 82963945
Email: guo.zhui@zte.com.cn Email: guo.zhui@zte.com.cn
Haoyu Song Haoyu Song
Futurewei Technologies Futurewei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, Santa Clara,
United States of America United States of America
Email: hsong@futurewei.com Email: hsong@futurewei.com
Pascal Thubert
Cisco Systems, Inc
Building D
45 Allee des Ormes - BP1200
06254 MOUGINS - Sophia Antipolis
France
Phone: +33 497 23 26 34
Email: pthubert@cisco.com
 End of changes. 25 change blocks. 
29 lines changed or deleted 48 lines changed or added

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