< draft-mirsky-ippm-hybrid-two-step-10.txt   draft-mirsky-ippm-hybrid-two-step-11.txt >
IPPM Working Group G. Mirsky IPPM Working Group G. Mirsky
Internet-Draft ZTE Corp. Internet-Draft ZTE Corp.
Intended status: Standards Track W. Lingqiang Intended status: Standards Track W. Lingqiang
Expires: 18 November 2021 G. Zhui Expires: 9 January 2022 G. Zhui
ZTE Corporation ZTE Corporation
H. Song H. Song
Futurewei Technologies Futurewei Technologies
17 May 2021 8 July 2021
Hybrid Two-Step Performance Measurement Method Hybrid Two-Step Performance Measurement Method
draft-mirsky-ippm-hybrid-two-step-10 draft-mirsky-ippm-hybrid-two-step-11
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 41
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 18 November 2021. This Internet-Draft will expire on 9 January 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 (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 22 skipping to change at page 2, line 22
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5
4.1. Operation of the HTS Ingress Node . . . . . . . . . . . . 6 4.1. Operation of the HTS Ingress Node . . . . . . . . . . . . 7
4.2. Operation of the HTS Intermediate Node . . . . . . . . . 8 4.2. Operation of the HTS Intermediate Node . . . . . . . . . 9
4.3. Operation of the HTS Egress Node . . . . . . . . . . . . 9 4.3. Operation of the HTS Egress Node . . . . . . . . . . . . 10
4.4. Considerations for HTS Timers . . . . . . . . . . . . . . 10 4.4. Considerations for HTS Timers . . . . . . . . . . . . . . 11
4.5. Deploying HTS in a Multicast Network . . . . . . . . . . 10 4.5. Deploying HTS in a Multicast Network . . . . . . . . . . 11
5. Authentication in HTS . . . . . . . . . . . . . . . . . . . . 11 5. Authentication in HTS . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6.1. IOAM Option-Type for HTS . . . . . . . . . . . . . . . . 12 6.1. IOAM Option-Type for HTS . . . . . . . . . . . . . . . . 13
6.2. HTS TLV Registry . . . . . . . . . . . . . . . . . . . . 12 6.2. HTS TLV Registry . . . . . . . . . . . . . . . . . . . . 13
6.3. HTS Sub-TLV Type Sub-registry . . . . . . . . . . . . . . 13 6.3. HTS Sub-TLV Type Sub-registry . . . . . . . . . . . . . . 14
6.4. HMAC Type Sub-registry . . . . . . . . . . . . . . . . . 14 6.4. HMAC Type Sub-registry . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 17 skipping to change at page 5, line 17
as that associated with buffering and queuing of the packet). A as that associated with buffering and queuing of the packet). A
similar problem may lower the quality of, for example, information similar problem may lower the quality of, for example, information
that characterizes utilization of the egress interface. If unable to that characterizes utilization of the egress interface. If unable to
obtain the data consistently, without variable delays for additional obtain the data consistently, without variable delays for additional
processing, information may not accurately reflect the egress processing, information may not accurately reflect the egress
interface state. To mitigate this problem [RFC8169] defined an RTM interface state. To mitigate this problem [RFC8169] defined an RTM
two-step mode. two-step mode.
Another challenge associated with methods that collect network state Another challenge associated with methods that collect network state
information into the actual data packet is the risk to exceed the information into the actual data packet is the risk to exceed the
Maximum Transmission Unit (MTU) size, especially if the packet Maximum Transmission Unit (MTU) size on the path, especially if the
traverses overlay domains or VPNs. Since the fragmentation is not packet traverses overlay domains or VPNs. Since the fragmentation is
available at the transport network, operators may have to reduce MTU not available at the transport network, operators may have to reduce
size advertised to the client layer or risk missing network state MTU size advertised to the client layer or risk missing network state
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
[I-D.ietf-raw-use-cases], it is beneficial to collect the telemetry,
including the calculated performance metrics, that reflects
conditions experienced by the monitored flow at a node, other than
the egress. For example, a head-end can optimize path selection
based on the compounded information that reflects network conditions,
resource utilization. This mode is referred to as the upstream
collection and the other - downstream collection to differentiate
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 or obtaining network state information, * performing a measurement and/or obtaining network state
one or more than one type, on a node; information on a node;
* collecting and transporting the measurement. * collecting and transporting the measurement and/or the telemetry
information.
HTS uses 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 [I-D.ietf-ippm-ioam-data]. A packet in the flow to which
the Alternate-Marking method [RFC8321] is applied can be used as an the Alternate-Marking method [RFC8321] is applied can be used as an
HTS Trigger. The nature of the HTS Trigger is a transport network HTS Trigger. The nature of the HTS Trigger is a transport network
layer-specific, and its description is outside the scope of this layer-specific, and its description is outside the scope of this
document. The packet that includes the HTS Trigger in this document document. The packet that includes the HTS Trigger in this document
is also referred to as the trigger packet. is also referred to as the trigger packet.
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. The follow-up packet contains characteristic HTS Follow-up packet. In some use cases, e.g., when HTS is used to
information, copied from the trigger packet, sufficient for collect the telemetry, including performance metrics, calculated
participating HTS nodes to associate it with the original packet. As based on a series of measurements, an HTS follow-up packet can be
the follow-up packet is expected to traverse the same sequence of originated without using the HTS Trigger. The follow-up packet
nodes, one element of the characteristic information is the contains characteristic information sufficient for participating HTS
information that determines the path in the data plane. For example, nodes to associate it with the monitored data flow. The
in a segment routing domain [RFC8402], a list of segment identifiers characteristic information can be obtained using the information of
of the trigger packet is applied to the follow-up packet. And in the the trigger packet or constructed by a node that originates the
case of the service function chain based on the Network Service follow-up packet. As the follow-up packet is expected to traverse
Header [RFC8300], the Base Header and Service Path Header of the the same sequence of nodes, one element of the characteristic
trigger packet will be applied to the follow-up packet. Also, when information is the information that determines the path in the data
HTS is used to collect the telemetry information in an IOAM domain, plane. For example, in a segment routing domain [RFC8402], a list of
the IOAM trace option header [I-D.ietf-ippm-ioam-data] of the trigger segment identifiers of the trigger packet is applied to the follow-up
packet is applied in the follow-up packet. The follow-up packet also packet. And in the case of the service function chain based on the
uses the same network information used to load-balance flows in Network Service Header [RFC8300], the Base Header and Service Path
equal-cost multipath (ECMP) as the trigger packet, e.g., IPv6 Flow Header of the trigger packet will be applied to the follow-up packet.
Label [RFC6437] or an entropy label [RFC6790]. The exact composition Also, when HTS is used to collect the telemetry information in an
of the characteristic information is specific for each transport IOAM domain, the IOAM trace option header [I-D.ietf-ippm-ioam-data]
network, and its definition is outside the scope of this document. of the trigger packet is applied in the follow-up packet. The
follow-up packet also uses the same network information used to load-
balance flows in equal-cost multipath (ECMP) as the trigger packet,
e.g., IPv6 Flow Label [RFC6437] or an entropy label [RFC6790]. The
exact composition of the characteristic information is specific for
each transport network, and its definition is outside the scope of
this document.
Only one outstanding follow-up packet MUST be on the node for the Only one outstanding follow-up packet MUST be on the node for the
given path. That means that if the node receives an HTS Trigger for given path. That means that if the node receives an HTS Trigger for
the flow on which it still waits for the follow-up packet to the the flow on which it still waits for the follow-up packet to the
previous HTS Trigger, the node will originate the follow-up packet to previous HTS Trigger, the node will originate the follow-up packet to
transport the former set of the network state data and transmit it transport the former set of the network state data and transmit it
before it sends the follow-up packet with the latest collection of before it sends the follow-up packet with the latest collection of
network state information. network state information.
The following sections describe the operation of HTS nodes in the
downstream mode of collecting the telemetry information. In the
upstream mode, the bahavior of HTS nodes, in general, identical with
the exception that the HTS Trigger packet does not precede the HTS
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 1 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 Len| Flags | Sequence Number | |Ver|HTS Shim L | Flags |Sequence Number| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HTS Max Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Telemetry Data Profile | | Telemetry Data Profile |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Telemetry Data TLVs ~ ~ Telemetry Data TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Follow-up Packet Format Figure 1: 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 bytes. The minimal value of the field is four of the HTS shim in octets. The minimal value of the field is
bytes. 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 2: 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 2.
- 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 16 bits-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
sequence of the HTS follow-up packets that originated in response sequence of the HTS follow-up packets that originated in response
to the same HTS trigger. The ingress node MUST set the value of to the same HTS trigger. The ingress node MUST set the value of
the field to zero. the field to zero.
Reserved is one octet-long field. It MUST be zeroed on
transmission and ignored on recepit.
HTS Max Length is four octet-long field. The value of th HTS Max
Length field indicates the maximum length of the HTS Follow-up
packet in octets. An operator MUST be able to configure the HTS
Max Length field's value. The value SHOULD be set equal to the
path MTU.
Telemetry Data Profile is the optional variable-length field of Telemetry Data Profile is the optional variable-length field of
bit-size flags. Each flag indicates the requested type of bit-size flags. Each flag indicates the requested type of
telemetry data to be collected at each HTS node. The increment of telemetry data to be collected at each HTS node. The increment of
the field is four bytes with a minimum length of zero. For the field is four bytes with a minimum length of zero. For
example, IOAM-Trace-Type information defined in example, IOAM-Trace-Type information defined in
[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
skipping to change at page 9, line 10 skipping to change at page 9, line 49
1. verify that the matching transport information exists and the 1. verify that the matching transport information exists and the
Full flag is cleared, then stop the associated HTS Follow-up Full flag is cleared, then stop the associated HTS Follow-up
Timer; Timer;
2. otherwise, transmit the received packet. Proceed to Step 8; 2. otherwise, transmit the received packet. Proceed to Step 8;
3. collect telemetry data requested in the Telemetry Data Profile 3. collect telemetry data requested in the Telemetry Data Profile
field or defined by the local HTS policy; field or defined by the local HTS policy;
4. if adding the collected telemetry would not exceed MTU, then 4. if adding the collected telemetry would not exceed HTS Max Length
append data as a new Telemetry Data TLV and transmit the follow- field's value, then append data as a new Telemetry Data TLV and
up packet. Proceed to Step 8; transmit the follow-up packet. Proceed to Step 8;
5. otherwise, set the value of the Full flag to one, copy the 5. otherwise, set the value of the Full flag to one, copy the
transport information from the received follow-up packet and transport information from the received follow-up packet and
transmit it accordingly. Proceed to Step 8; transmit it accordingly. Proceed to Step 8;
6. originate the new follow-up packet using the transport 6. originate the new follow-up packet using the transport
information copied from the received follow-up packet. The value information copied from the received follow-up packet. The value
of the Sequence Number field in the HTS shim MUST be set to the of the Sequence Number field in the HTS shim MUST be set to the
value of the field in the received follow-up packet incremented value of the field in the received follow-up packet incremented
by one; by one;
skipping to change at page 16, line 19 skipping to change at page 17, line 19
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
for In-situ OAM", Work in Progress, Internet-Draft, draft- for In-situ OAM", Work in Progress, Internet-Draft, draft-
ietf-ippm-ioam-data-12, 21 February 2021, ietf-ippm-ioam-data-14, 24 June 2021,
<https://tools.ietf.org/html/draft-ietf-ippm-ioam-data- <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
12>. ioam-data-14>.
[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-03, 17 February 2021, draft-ietf-ippm-ioam-direct-export-03, 17 February 2021,
<https://tools.ietf.org/html/draft-ietf-ippm-ioam-direct- <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
export-03>. ioam-direct-export-03>.
[I-D.ietf-raw-use-cases]
Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J.
Bernardos, "RAW use cases", Work in Progress, Internet-
Draft, draft-ietf-raw-use-cases-01, 21 February 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-raw-use-
cases-01>.
[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, "Postcard-based On-Path T., Li, Z., Shin, J., and K. Lee, "Postcard-based On-Path
Flow Data Telemetry using Packet Marking", Work in Flow Data Telemetry using Packet Marking", Work in
Progress, Internet-Draft, draft-song-ippm-postcard-based- Progress, Internet-Draft, draft-song-ippm-postcard-based-
telemetry-09, 19 February 2021, telemetry-09, 19 February 2021,
<https://tools.ietf.org/html/draft-song-ippm-postcard- <https://datatracker.ietf.org/doc/html/draft-song-ippm-
based-telemetry-09>. postcard-based-telemetry-09>.
[P4.INT] "In-band Network Telemetry (INT)", P4.org Specification, [P4.INT] "In-band Network Telemetry (INT)", P4.org Specification,
October 2017. October 2017.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007, DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>. <https://www.rfc-editor.org/info/rfc4868>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
 End of changes. 21 change blocks. 
62 lines changed or deleted 104 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/