< draft-fioccola-rfc8889bis-00.txt   draft-fioccola-rfc8889bis-01.txt >
Network Working Group G. Fioccola, Ed. Network Working Group G. Fioccola, Ed.
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Obsoletes: 8889 (if approved) M. Cociglio Obsoletes: 8889 (if approved) M. Cociglio
Intended status: Standards Track Telecom Italia Intended status: Standards Track Telecom Italia
Expires: May 23, 2022 A. Sapio Expires: June 12, 2022 A. Sapio
Intel Corporation Intel Corporation
R. Sisto R. Sisto
Politecnico di Torino Politecnico di Torino
November 19, 2021 T. Zhou
Huawei Technologies
December 9, 2021
Multipoint Alternate-Marking Method Multipoint Alternate-Marking Method
draft-fioccola-rfc8889bis-00 draft-fioccola-rfc8889bis-01
Abstract Abstract
This document generalizes and expands Alternate-Marking methodology This document generalizes and expands Alternate-Marking methodology
to measure any kind of unicast flow whose packets can follow several to measure any kind of unicast flow whose packets can follow several
different paths in the network -- in wider terms, a multipoint-to- different paths in the network -- in wider terms, a multipoint-to-
multipoint network. For this reason, the technique here described is multipoint network. For this reason, the technique here described is
called "Multipoint Alternate Marking". This document obsoletes called "Multipoint Alternate Marking". This document obsoletes
[RFC8889]. [RFC8889].
skipping to change at page 1, line 40 skipping to change at page 1, line 42
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 May 23, 2022. This Internet-Draft will expire on June 12, 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Correlation with RFC 5644 . . . . . . . . . . . . . . . . 5 2.1. Correlation with RFC 5644 . . . . . . . . . . . . . . . . 5
3. Flow Classification . . . . . . . . . . . . . . . . . . . . . 6 3. Flow Classification . . . . . . . . . . . . . . . . . . . . . 6
4. Multipoint Performance Measurement . . . . . . . . . . . . . 8 4. Multipoint Performance Measurement . . . . . . . . . . . . . 9
4.1. Monitoring Network . . . . . . . . . . . . . . . . . . . 9 4.1. Monitoring Network . . . . . . . . . . . . . . . . . . . 9
5. Multipoint Packet Loss . . . . . . . . . . . . . . . . . . . 10 5. Multipoint Packet Loss . . . . . . . . . . . . . . . . . . . 10
6. Network Clustering . . . . . . . . . . . . . . . . . . . . . 11 6. Network Clustering . . . . . . . . . . . . . . . . . . . . . 11
6.1. Algorithm for Clusters Partition . . . . . . . . . . . . 12 6.1. Algorithm for Clusters Partition . . . . . . . . . . . . 12
7. Timing Aspects . . . . . . . . . . . . . . . . . . . . . . . 15 7. Timing Aspects . . . . . . . . . . . . . . . . . . . . . . . 16
8. Multipoint Delay and Delay Variation . . . . . . . . . . . . 17 8. Multipoint Delay and Delay Variation . . . . . . . . . . . . 18
8.1. Delay Measurements on a Multipoint-Paths Basis . . . . . 18 8.1. Delay Measurements on a Multipoint-Paths Basis . . . . . 18
8.1.1. Single-Marking Measurement . . . . . . . . . . . . . 18 8.1.1. Single-Marking Measurement . . . . . . . . . . . . . 18
8.2. Delay Measurements on a Single-Packet Basis . . . . . . . 18 8.2. Delay Measurements on a Single-Packet Basis . . . . . . . 18
8.2.1. Single- and Double-Marking Measurement . . . . . . . 18 8.2.1. Single- and Double-Marking Measurement . . . . . . . 18
8.2.2. Hashing Selection Method . . . . . . . . . . . . . . 19 8.2.2. Hashing Selection Method . . . . . . . . . . . . . . 19
9. A Closed-Loop Performance-Management Approach . . . . . . . . 21 9. A Closed-Loop Performance-Management Approach . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
14.1. Normative References . . . . . . . . . . . . . . . . . . 23 14.1. Normative References . . . . . . . . . . . . . . . . . . 22
14.2. Informative References . . . . . . . . . . . . . . . . . 23 14.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Changes Log . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Changes Log . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The Alternate-Marking method, as described in The Alternate-Marking method, as described in
[I-D.fioccola-rfc8321bis], is applicable to a point-to-point path. [I-D.fioccola-rfc8321bis], is applicable to a point-to-point path.
The extension proposed in this document applies to the most general The extension proposed in this document applies to the most general
case of multipoint-to-multipoint path and enables flexible and case of multipoint-to-multipoint path and enables flexible and
adaptive performance measurements in a managed network. adaptive performance measurements in a managed network.
The Alternate-Marking methodology described in The Alternate-Marking methodology described in
skipping to change at page 3, line 35 skipping to change at page 3, line 39
parameters. parameters.
The approach presented in this document is applied only to unicast The approach presented in this document is applied only to unicast
flows and not to multicast. Broadcast, Unknown Unicast, and flows and not to multicast. Broadcast, Unknown Unicast, and
Multicast (BUM) traffic is not considered here, because traffic Multicast (BUM) traffic is not considered here, because traffic
replication is not covered by the Multipoint Alternate-Marking replication is not covered by the Multipoint Alternate-Marking
method. Furthermore, it can be applicable to anycast flows, and method. Furthermore, it can be applicable to anycast flows, and
Equal-Cost Multipath (ECMP) paths can also be easily monitored with Equal-Cost Multipath (ECMP) paths can also be easily monitored with
this technique. this technique.
In short, [I-D.fioccola-rfc8321bis] applies to point-to-point unicast [I-D.fioccola-rfc8321bis] applies to point-to-point unicast flows and
flows and BUM traffic, while this document and its Clustered BUM traffic. For BUM traffic, the basic method of
[I-D.fioccola-rfc8321bis] can easily be applied link by link and
therefore split the multicast flow tree distribution into separate
unicast point-to-point links. While this document and its Clustered
Alternate-Marking method is valid for multipoint-to-multipoint Alternate-Marking method is valid for multipoint-to-multipoint
unicast flows, anycast, and ECMP flows. unicast flows, anycast, and ECMP flows.
Therefore,the Alternate-Marking method can be extended to any kind of Therefore, the Alternate-Marking method can be extended to any kind
multipoint-to-multipoint paths, and the network-clustering approach of multipoint-to-multipoint paths, and the network-clustering
presented in this document is the formalization of how to implement approach presented in this document is the formalization of how to
this property and allow a flexible and optimized performance implement this property and allow a flexible and optimized
measurement support for network management in every situation. performance measurement support for network management in every
situation.
Without network clustering, it is possible to apply Alternate Marking Without network clustering, it is possible to apply Alternate Marking
only for all the network or per single flow. Instead, with network only for all the network or per single flow. Instead, with network
clustering, it is possible to use the partition of the network into clustering, it is possible to use the partition of the network into
clusters at different levels in order to perform the needed degree of clusters at different levels in order to perform the needed degree of
detail. In some circumstances, it is possible to monitor a detail. In some circumstances, it is possible to monitor a
multipoint network by analyzing the network clustering, without multipoint network by analyzing the network clustering, without
examining in depth. In case of problems (packet loss is measured or examining in depth. In case of problems (packet loss is measured or
the delay is too high), the filtering criteria could be specified the delay is too high), the filtering criteria could be specified
more in order to perform a detailed analysis by using a different more in order to perform a detailed analysis by using a different
skipping to change at page 4, line 26 skipping to change at page 4, line 33
accurately the network performance monitoring is set up by applying accurately the network performance monitoring is set up by applying
the Multipoint Alternate Marking as described in this document. the Multipoint Alternate Marking as described in this document.
It is important to underline that, as an extension of It is important to underline that, as an extension of
[I-D.fioccola-rfc8321bis], this is a methodology document, so the [I-D.fioccola-rfc8321bis], this is a methodology document, so the
mechanism that can be used to transmit the counters and the mechanism that can be used to transmit the counters and the
timestamps is out of scope here, and the implementation is open. timestamps is out of scope here, and the implementation is open.
Several options are possible -- e.g., see "Enhanced Alternate Marking Several options are possible -- e.g., see "Enhanced Alternate Marking
Method" [I-D.zhou-ippm-enhanced-alternate-marking]. Method" [I-D.zhou-ippm-enhanced-alternate-marking].
This document assumes that the blocks are created according to a
fixed timer as per [I-D.fioccola-rfc8321bis]. The switching after a
fixed number of packets is an additional possibility but it is out of
scope here.
Note that the fragmented packets case can be managed with the Note that the fragmented packets case can be managed with the
Alternate-Marking methodology only if fragmentation happens outside Alternate-Marking methodology. The same considerations of
the portion of the network that is monitored. This is always true [I-D.fioccola-rfc8321bis] apply also in the case of Multipoint
for both [I-D.fioccola-rfc8321bis] and Multipoint Alternate Marking, Alternate Marking. As defined in [I-D.fioccola-rfc8321bis] the
as explained here. marking node MUST mark all the fragments except in the case of
fragmentation within the network domain, in that event it is
suggested to mark only the first fragment.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Terminology 2. Terminology
skipping to change at page 10, line 30 skipping to change at page 10, line 30
\ <> R9 <>--- \ <> R9 <>---
\ +------+ \ +------+
\ \
\ +------+ \ +------+
<> R10 <>--- <> R10 <>---
+------+ +------+
Figure 2: Monitoring Network Graph Figure 2: Monitoring Network Graph
Each monitoring point is characterized by the packet counter that Each monitoring point is characterized by the packet counter that
refers only to a marking period of the monitored flow. refers only to a marking period of the monitored flow. Also, it is
assumed that there be a monitoring point at all possible egress
points of the multipoint monitored network.
The same is also applicable for the delay, but it will be described The same is also applicable for the delay, but it will be described
in the following sections. in the following sections.
5. Multipoint Packet Loss 5. Multipoint Packet Loss
Since all the packets of the considered flow leaving the network have Since all the packets of the considered flow leaving the network have
previously entered the network, the number of packets counted by all previously entered the network, the number of packets counted by all
the input nodes is always greater than, or equal to, the number of the input nodes is always greater than, or equal to, the number of
packets counted by all the output nodes. Noninitial fragments are packets counted by all the output nodes. Noninitial fragments are
skipping to change at page 16, line 39 skipping to change at page 16, line 47
When we expand to multipoint-to-multipoint flows, we have to consider When we expand to multipoint-to-multipoint flows, we have to consider
that all source nodes mark the traffic, and this adds more that all source nodes mark the traffic, and this adds more
complexity. complexity.
Regarding the timing aspects of the methodology, Regarding the timing aspects of the methodology,
[I-D.fioccola-rfc8321bis] already describes two contributions that [I-D.fioccola-rfc8321bis] already describes two contributions that
are taken into account: the clock error between network devices and are taken into account: the clock error between network devices and
the network delay between measurement points. the network delay between measurement points.
But we should now consider an additional contribution. Since all Since there are more marking nodes in a multipoint environment, all
source nodes mark the traffic, the source measurement intervals can source nodes mark the traffic based on synchronized clock time but
be of different lengths and with different offsets, and this mismatch the marking periods can be of different lengths and with different
m can be added to d, as shown in Figure 5. offsets. This is because there can be an additional contribution to
consider since different nodes are marking the traffic and the
batches get mixed in a multipoint flow. For example, a marking node
may apply the marking with a delay because it is overloaded while the
other marking nodes are not. To take into account this possible
additional gap between the sources it is introduced a mismatch m that
can be added to d, as shown in Figure 5.
...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB... ...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB...
|<======================================>| |<======================================>|
| L | | L |
...=========>|<==================><==================>|<==========... ...=========>|<==================><==================>|<==========...
| L/2 L/2 | | L/2 L/2 |
|<=><===>| |<===><=>| |<=><===>| |<===><=>|
m d | | d m m d | | d m
|<====================>| |<====================>|
available counting interval available counting interval
skipping to change at page 17, line 38 skipping to change at page 17, line 44
L - 2m - 2d > 0. L - 2m - 2d > 0.
This formula needs to be verified for each measurement point on the This formula needs to be verified for each measurement point on the
multipoint path, where m is misalignment between the marking source multipoint path, where m is misalignment between the marking source
routers, while d, already introduced in [I-D.fioccola-rfc8321bis], routers, while d, already introduced in [I-D.fioccola-rfc8321bis],
takes into account clock error and network delay between network takes into account clock error and network delay between network
nodes. Therefore, the mismatch between measurement intervals must nodes. Therefore, the mismatch between measurement intervals must
satisfy this condition. satisfy this condition.
Also, it is worth highlighting that the formula above is exactly the
same of [I-D.fioccola-rfc8321bis] if m=0, indeed in case of a point-
to-point flow there is only one marking node and m=0.
Note that the timing considerations are valid for both packet loss Note that the timing considerations are valid for both packet loss
and delay measurements. and delay measurements.
8. Multipoint Delay and Delay Variation 8. Multipoint Delay and Delay Variation
The same line of reasoning can be applied to delay and delay The same line of reasoning can be applied to delay and delay
variation. Similarly to the delay measurements defined in variation. Similarly to the delay measurements defined in
[I-D.fioccola-rfc8321bis], the marking batches anchor the samples to [I-D.fioccola-rfc8321bis], the marking batches anchor the samples to
a particular period, and this is the time reference that can be used. a particular period, and this is the time reference that can be used.
It is important to highlight that both delay and delay-variation It is important to highlight that both delay and delay-variation
skipping to change at page 19, line 28 skipping to change at page 19, line 41
8.2.2. Hashing Selection Method 8.2.2. Hashing Selection Method
RFCs 5474 [RFC5474] and 5475 [RFC5475] introduce sampling and RFCs 5474 [RFC5474] and 5475 [RFC5475] introduce sampling and
filtering techniques for IP packet selection. filtering techniques for IP packet selection.
The hash-based selection methodologies for delay measurement can work The hash-based selection methodologies for delay measurement can work
in a multipoint-to-multipoint path and MAY be used either coupled to in a multipoint-to-multipoint path and MAY be used either coupled to
mean delay or stand-alone. mean delay or stand-alone.
[I-D.mizrahi-ippm-compact-alternate-marking] introduces how to use [I-D.mizrahi-ippm-marking] introduces how to use the hash method (RFC
the hash method (RFC 5474 [RFC5474] and RFC 5475 [RFC5475]) combined 5474 [RFC5474] and RFC 5475 [RFC5475]) combined with the Alternate-
with the Alternate-Marking method for point-to-point flows. It is Marking method for point-to-point flows. It is also called Mixed
also called Mixed Hashed Marking: the coupling of a marking method Hashed Marking: the coupling of a marking method and hashing
and hashing technique is very useful, because the marking batches technique is very useful, because the marking batches anchor the
anchor the samples selected with hashing, and this simplifies the samples selected with hashing, and this simplifies the correlation of
correlation of the hashing packets along the path. the hashing packets along the path.
It is possible to use a basic-hash or a dynamic-hash method. One of It is possible to use a basic-hash or a dynamic-hash method. One of
the challenges of the basic approach is that the frequency of the the challenges of the basic approach is that the frequency of the
sampled packets may vary considerably. For this reason, the dynamic sampled packets may vary considerably. For this reason, the dynamic
approach has been introduced for point-to-point flows in order to approach has been introduced for point-to-point flows in order to
have the desired and almost fixed number of samples for each have the desired and almost fixed number of samples for each
measurement period. Using the hash-based sampling, the number of measurement period. Using the hash-based sampling, the number of
samples may vary a lot because it depends on the packet rate that is samples may vary a lot because it depends on the packet rate that is
variable. The dynamic approach helps to have an almost fixed number variable. The dynamic approach helps to have an almost fixed number
of samples for each marking period, and this is a better option for of samples for each marking period, and this is a better option for
making regular measurements over time. In the hash-based sampling, making regular measurements over time. In the hash-based sampling,
Alternate Marking is used to create periods, so that hash-based Alternate Marking is used to create periods, so that hash-based
samples are divided into batches, which allows anchoring the selected samples are divided into batches, which allows anchoring the selected
samples to their period. Moreover, in the dynamic hash-based samples to their period. Moreover, in the dynamic hash-based
sampling, by dynamically adapting the length of the hash value, the sampling, by dynamically adapting the length of the hash value, the
number of samples is bounded in each marking period. This can be number of samples is bounded in each marking period.
realized by choosing the maximum number of samples (NMAX) to be
caught in a marking period. The algorithm starts with only a few
hash bits, which permits selecting a greater percentage of packets
(e.g., with 0 bits of hash all the packets are sampled, with 1 bit of
hash half of the packets are sampled, and so on). When the number of
selected packets reaches NMAX, a hashing bit is added. As a
consequence, the sampling proceeds at half of the original rate, and
also the packets already selected that do not match the new hash are
discarded. This step can be repeated iteratively. It is assumed
that each sample includes the timestamp (used for delay measurement)
and the hash value, allowing the management system to match the
samples received from the two measurement points. The dynamic
process statistically converges at the end of a marking period, and
the final number of selected samples is between NMAX/2 and NMAX.
Therefore, the dynamic approach paces the sampling rate, allowing to
bound the number of sampled packets per sampling period.
In a multipoint environment, the behavior is similar to a point-to-
point flow. In particular, in the context of a multipoint-to-
multipoint flow, the dynamic hash could be the solution for
performing delay measurements on specific packets and overcoming the
single- and double-marking limitations.
The management system receives the samples, including the timestamps
and the hash value, from all the MPs, and this happens for both
point-to-point and multipoint-to-multipoint flows. Then, the longest
hash used by the MPs is deduced and applied to couple timestamps from
either the same packets of 2 MPs of a point-to-point path, or the
input and output MPs of a cluster (or a super cluster or the entire
network). But some considerations are needed: if there isn't packet
loss, the set of input samples is always equal to the set of output
samples. In the case of packet loss, the set of output samples can
be a subset of input samples, but the method still works because, at
the end, it is easy to couple the input and output timestamps of each
caught packet using the hash (in particular, the "unused part of the
hash" that should be different for each packet).
Therefore, the basic hash is logically similar to the double-marking In a multipoint environment, the hashing selection MAY be the
method, and in the case of a point-to-point path, double-marking and solution for performing delay measurements on specific packets and
basic-hash selection are equivalent. The dynamic approach scales the overcoming the single- and double-marking limitations.
number of measurements per interval. It would seem that double
marking would also work well if we reduced the interval length, but
this can be done only for a point-to-point path and not for a
multipoint path, where we cannot couple the picked packets in a
multipoint path. So, in general, if we want to get delay
measurements on the basis of a multipoint-to-multipoint path, and
want to select more than one packet per period, double marking cannot
be used because we could not be able to couple the picked packets
between input and output nodes. On the other hand, we can do that by
using hashing selection.
9. A Closed-Loop Performance-Management Approach 9. A Closed-Loop Performance-Management Approach
The Multipoint Alternate-Marking framework that is introduced in this The Multipoint Alternate-Marking framework that is introduced in this
document adds flexibility to Performance Management (PM), because it document adds flexibility to Performance Management (PM), because it
can reduce the order of magnitude of the packet counters. This can reduce the order of magnitude of the packet counters. This
allows an SDN orchestrator to supervise, control, and manage PM in allows an SDN orchestrator to supervise, control, and manage PM in
large networks. large networks.
The monitoring network can be considered as a whole or split into The monitoring network can be considered as a whole or split into
skipping to change at page 22, line 42 skipping to change at page 22, line 11
Internet. However, implementation of this method must be mindful of Internet. However, implementation of this method must be mindful of
security and privacy concerns, as explained in security and privacy concerns, as explained in
[I-D.fioccola-rfc8321bis]. [I-D.fioccola-rfc8321bis].
11. IANA Considerations 11. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
12. Contributors 12. Contributors
Tianran Zhou
Huawei Technologies
Email: zhoutianran@huawei.com
Greg Mirsky Greg Mirsky
Ericsson Ericsson
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com
Tal Mizrahi Tal Mizrahi
Huawei Technologies Huawei Technologies
Email: tal.mizrahi.phd@gmail.com Email: tal.mizrahi.phd@gmail.com
Xiao Min Xiao Min
ZTE Corp. ZTE Corp.
skipping to change at page 23, line 19 skipping to change at page 22, line 32
13. Acknowledgements 13. Acknowledgements
The authors would like to thank Martin Duke and Tommy Pauly for their The authors would like to thank Martin Duke and Tommy Pauly for their
assistance and their detailed and precious reviews. assistance and their detailed and precious reviews.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.fioccola-rfc8321bis]
Fioccola, G., Cociglio, M., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method", draft-fioccola-rfc8321bis-00
(work in progress), November 2021.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A.,
Grossglauser, M., and J. Rexford, "A Framework for Packet Grossglauser, M., and J. Rexford, "A Framework for Packet
Selection and Reporting", RFC 5474, DOI 10.17487/RFC5474, Selection and Reporting", RFC 5474, DOI 10.17487/RFC5474,
March 2009, <https://www.rfc-editor.org/info/rfc5474>. March 2009, <https://www.rfc-editor.org/info/rfc5474>.
skipping to change at page 23, line 45 skipping to change at page 23, line 16
Metrics (IPPM): Spatial and Multicast", RFC 5644, Metrics (IPPM): Spatial and Multicast", RFC 5644,
DOI 10.17487/RFC5644, October 2009, DOI 10.17487/RFC5644, October 2009,
<https://www.rfc-editor.org/info/rfc5644>. <https://www.rfc-editor.org/info/rfc5644>.
[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>.
14.2. Informative References 14.2. Informative References
[I-D.fioccola-rfc8321bis]
Fioccola, G., Cociglio, M., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method", draft-fioccola-rfc8321bis-00
(work in progress), November 2021.
[I-D.ietf-ippm-route] [I-D.ietf-ippm-route]
Alvarez-Hamelin, J. I., Morton, A., Fabini, J., Pignataro, Alvarez-Hamelin, J. I., Morton, A., Fabini, J., Pignataro,
C., and R. Geib, "Advanced Unidirectional Route Assessment C., and R. Geib, "Advanced Unidirectional Route Assessment
(AURA)", draft-ietf-ippm-route-10 (work in progress), (AURA)", draft-ietf-ippm-route-10 (work in progress),
August 2020. August 2020.
[I-D.mizrahi-ippm-compact-alternate-marking] [I-D.mizrahi-ippm-marking]
Mizrahi, T., Arad, C., Fioccola, G., Cociglio, M., Chen, Mizrahi, T., Fioccola, G., Cociglio, M., Chen, M., and G.
M., Zheng, L., and G. Mirsky, "Compact Alternate Marking Mirsky, "Marking Methods for Performance Measurement",
Methods for Passive and Hybrid Performance Monitoring", draft-mizrahi-ippm-marking-00 (work in progress), October
draft-mizrahi-ippm-compact-alternate-marking-05 (work in 2021.
progress), July 2019.
[I-D.song-opsawg-ifit-framework] [I-D.song-opsawg-ifit-framework]
Song, H., Qin, F., Chen, H., Jin, J., and J. Shin, "In- Song, H., Qin, F., Chen, H., Jin, J., and J. Shin, "In-
situ Flow Information Telemetry", draft-song-opsawg-ifit- situ Flow Information Telemetry", draft-song-opsawg-ifit-
framework-16 (work in progress), October 2021. framework-16 (work in progress), October 2021.
[I-D.zhou-ippm-enhanced-alternate-marking] [I-D.zhou-ippm-enhanced-alternate-marking]
Zhou, T., Fioccola, G., Liu, Y., Lee, S., Cociglio, M., Zhou, T., Fioccola, G., Liu, Y., Lee, S., Cociglio, M.,
and W. Li, "Enhanced Alternate Marking Method", draft- and W. Li, "Enhanced Alternate Marking Method", draft-
zhou-ippm-enhanced-alternate-marking-07 (work in zhou-ippm-enhanced-alternate-marking-07 (work in
skipping to change at page 25, line 13 skipping to change at page 24, line 19
<https://www.rfc-editor.org/info/rfc8889>. <https://www.rfc-editor.org/info/rfc8889>.
Appendix A. Changes Log Appendix A. Changes Log
Changes from RFC 8889 include: Changes from RFC 8889 include:
o Minor editorial changes o Minor editorial changes
o Removed section on "Examples of application" o Removed section on "Examples of application"
Changes in v-(01) include:
o Considerations on BUM traffic
o Reference to RFC8321bis for the fragmentation part
o Revised section on "Delay Measurements on a Single-Packet Basis"
o Revised section on "Timing Aspects"
Authors' Addresses Authors' Addresses
Giuseppe Fioccola (editor) Giuseppe Fioccola (editor)
Huawei Technologies Huawei Technologies
Riesstrasse, 25 Riesstrasse, 25
Munich 80992 Munich 80992
Germany Germany
Email: giuseppe.fioccola@huawei.com Email: giuseppe.fioccola@huawei.com
skipping to change at page 25, line 30 skipping to change at page 25, line 4
Email: giuseppe.fioccola@huawei.com Email: giuseppe.fioccola@huawei.com
Mauro Cociglio Mauro Cociglio
Telecom Italia Telecom Italia
Via Reiss Romoli, 274 Via Reiss Romoli, 274
Torino 10148 Torino 10148
Italy Italy
Email: mauro.cociglio@telecomitalia.it Email: mauro.cociglio@telecomitalia.it
Amedeo Sapio Amedeo Sapio
Intel Corporation Intel Corporation
4750 Patrick Henry Dr. 4750 Patrick Henry Dr.
Santa Clara, CA 95054 Santa Clara, CA 95054
USA USA
Email: amedeo.sapio@intel.com Email: amedeo.sapio@intel.com
Riccardo Sisto Riccardo Sisto
Politecnico di Torino Politecnico di Torino
Corso Duca degli Abruzzi, 24 Corso Duca degli Abruzzi, 24
Torino 10129 Torino 10129
Italy Italy
Email: riccardo.sisto@polito.it Email: riccardo.sisto@polito.it
Tianran Zhou
Huawei Technologies
156 Beiqing Rd.
Beijing 100095
China
Email: zhoutianran@huawei.com
 End of changes. 27 change blocks. 
104 lines changed or deleted 87 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/