< draft-fioccola-rfc8889bis-01.txt   draft-fioccola-rfc8889bis-02.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: June 12, 2022 A. Sapio Expires: August 21, 2022 A. Sapio
Intel Corporation Intel Corporation
R. Sisto R. Sisto
Politecnico di Torino Politecnico di Torino
T. Zhou T. Zhou
Huawei Technologies Huawei Technologies
December 9, 2021 February 17, 2022
Multipoint Alternate-Marking Method Multipoint Alternate-Marking Method
draft-fioccola-rfc8889bis-01 draft-fioccola-rfc8889bis-02
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 42 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 June 12, 2022. This Internet-Draft will expire on August 21, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . 16 7. Timing Aspects . . . . . . . . . . . . . . . . . . . . . . . 16
8. Multipoint Delay and Delay Variation . . . . . . . . . . . . 18 8. Multipoint Delay and Delay Variation . . . . . . . . . . . . 17
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 . . . . . . . . 20 9. Results of the Multipoint Alternate Marking Experiment . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. A Closed-Loop Performance-Management Approach . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
14.1. Normative References . . . . . . . . . . . . . . . . . . 22 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
14.2. Informative References . . . . . . . . . . . . . . . . . 23 15.1. Normative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Changes Log . . . . . . . . . . . . . . . . . . . . 24 15.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Changes Log . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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 10, line 37 skipping to change at page 10, line 37
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. Also, it is refers only to a marking period of the monitored flow. Also, it is
assumed that there be a monitoring point at all possible egress assumed that there be a monitoring point at all possible egress
points of the multipoint monitored network. 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.
The rest of the document assumes that the traffic is going from left
to right in order to simplify the explanation. But the analysis done
for one direction applies equally to all directions.
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
not considered here. not considered here.
The assumption is the use of the Alternate-Marking method. In the The assumption is the use of the Alternate-Marking method. In the
case of no packet loss occurring in the marking period, if all the case of no packet loss occurring in the marking period, if all the
skipping to change at page 16, line 9 skipping to change at page 16, line 9
The complete and mathematical analysis of the possible algorithms for The complete and mathematical analysis of the possible algorithms for
clusters partition, including the considerations in terms of clusters partition, including the considerations in terms of
efficiency and a comparison between the different methods, is in the efficiency and a comparison between the different methods, is in the
paper [IEEE-ACM-ToN-MPNPM]. paper [IEEE-ACM-ToN-MPNPM].
7. Timing Aspects 7. Timing Aspects
It is important to consider the timing aspects, since out-of-order It is important to consider the timing aspects, since out-of-order
packets happen and have to be handled as well, as described in packets happen and have to be handled as well, as described in
[I-D.fioccola-rfc8321bis]. However, in a multisource situation, an [I-D.fioccola-rfc8321bis].
additional issue has to be considered. With multipoint path, the
egress nodes will receive alternate marked packets in random order However, in a multisource situation, an additional issue has to be
from different ingress nodes, and this must not affect the considered. With multipoint path, the egress nodes will receive
measurement. alternate marked packets in random order from different ingress
nodes, and this must not affect the measurement.
So, if we analyze a multipoint-to-multipoint path with more than one So, if we analyze a multipoint-to-multipoint path with more than one
marking node, it is important to recognize the reference measurement marking node, it is important to recognize the reference measurement
interval. In general, the measurement interval for describing the interval. In general, the measurement interval for describing the
results is the interval of the marking node that is more aligned with results is the interval of the marking node that is more aligned with
the start of the measurement, as reported in Figure 4. the start of the measurement, as reported in Figure 4.
Note that the mark switching approach based on a fixed timer is Note that the mark switching approach based on a fixed timer is
considered in this document. considered in this document.
skipping to change at page 16, line 38 skipping to change at page 16, line 39
Figure 4: Measurement Interval Figure 4: Measurement Interval
In Figure 4, it is assumed that the node with the earliest clock (R1) In Figure 4, it is assumed that the node with the earliest clock (R1)
identifies the right starting and ending times of the measurement, identifies the right starting and ending times of the measurement,
but it is just an assumption, and other possibilities could occur. but it is just an assumption, and other possibilities could occur.
So, in this case, T(R1) is the measurement interval, and its So, in this case, T(R1) is the measurement interval, and its
recognition is essential in order to make comparisons with other recognition is essential in order to make comparisons with other
active/passive/hybrid Packet Loss metrics. active/passive/hybrid Packet Loss metrics.
When we expand to multipoint-to-multipoint flows, we have to consider Regarding the timing constraints of the methodology,
that all source nodes mark the traffic, and this adds more
complexity.
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 the measurement points.
Since there are more marking nodes in a multipoint environment, all When we expand to a multipoint environment, we have to consider that
source nodes mark the traffic based on synchronized clock time but there are more marking nodes that mark the traffic based on
the marking periods can be of different lengths and with different synchronized clock time. But, due to different synchronization
offsets. This is because there can be an additional contribution to issues that may happen, the marking batches can be of different
consider since different nodes are marking the traffic and the lengths and with different offsets when they get mixed in a
batches get mixed in a multipoint flow. For example, a marking node multipoint flow. The additional gap that results between the sources
may apply the marking with a delay because it is overloaded while the can be incorporated into A, which is the maximum clock skew between
other marking nodes are not. To take into account this possible the network devices, as already defined in [I-D.fioccola-rfc8321bis].
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 d | | d
|<====================>| |<========================>|
available counting interval available counting interval
Figure 5: Timing Aspects for Multipoint Paths Figure 5: Timing Aspects
So the misalignment between the marking source routers gives an Moreover, it is assumed that each path of the multipoint flow can
additional constraint, and the value of m is added to d (which still be represented with a distinct normal distribution. So, for
already includes clock error and network delay). the aggregate multipoint path, the combination of normal
distributions result in a new normal distribution. Under this
assumption, the definition of the guard band d is still applicable as
defined in [I-D.fioccola-rfc8321bis] and is given by:
Thus, three different possible contributions are considered: clock d = A + D_avg + 3*D_stddev,
error between network devices, network delay between measurement
points, and the misalignment between the marking source routers.
In the end, the condition that must be satisfied to enable the method where A is the clock accuracy, D_avg is the average value of the
to function properly is that the available counting interval must be network delay, and D_stddev is the standard deviation of the delay.
> 0, and that means:
L - 2m - 2d > 0. As shown in Figure 5 and according to [I-D.fioccola-rfc8321bis], the
condition that must be satisfied to enable the method to function
properly is that the available counting interval must be > 0, and
that means:
This formula needs to be verified for each measurement point on the L - 2d > 0.
multipoint path, where m is misalignment between the marking source
routers, while d, already introduced in [I-D.fioccola-rfc8321bis],
takes into account clock error and network delay between network
nodes. Therefore, the mismatch between measurement intervals must
satisfy this condition.
Also, it is worth highlighting that the formula above is exactly the This formula needs to be verified for each measurement point on the
same of [I-D.fioccola-rfc8321bis] if m=0, indeed in case of a point- multipoint path.
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.
skipping to change at page 18, line 44 skipping to change at page 18, line 38
generalized to the case of multipoint flows. It is possible to generalized to the case of multipoint flows. It is possible to
compute the average one-way delay of packets in one block, a cluster, compute the average one-way delay of packets in one block, a cluster,
or the entire monitored network. or the entire monitored network.
The average latency can be measured as the difference between the The average latency can be measured as the difference between the
weighted averages of the mean timestamps of the sets of output and weighted averages of the mean timestamps of the sets of output and
input nodes. This means that, in the calculation, it is possible to input nodes. This means that, in the calculation, it is possible to
weigh the timestamps by considering the number of packets for each weigh the timestamps by considering the number of packets for each
endpoints. endpoints.
Note that, since the one-way delay value is representative of a
multipoint path, it is possible to calculate the two-way delay of a
multipoint path by summing the one-way delays of the two directions,
similarly to [I-D.fioccola-rfc8321bis].
8.2. Delay Measurements on a Single-Packet Basis 8.2. Delay Measurements on a Single-Packet Basis
8.2.1. Single- and Double-Marking Measurement 8.2.1. Single- and Double-Marking Measurement
Delay and delay-variation measurements relative to only one picked Delay and delay-variation measurements relative to only one picked
packet per period (both single and double marked) can be performed in packet per period (both single and double marked) can be performed in
the multipoint scenario, with some limitations: the multipoint scenario, with some limitations:
Single marking based on the first/last packet of the interval Single marking based on the first/last packet of the interval
would not work, because it would not be possible to agree on the would not work, because it would not be possible to agree on the
skipping to change at page 19, line 32 skipping to change at page 19, line 32
scenario, since they would not be representative of the entire flow. scenario, since they would not be representative of the entire flow.
The packets can follow different paths with various delays, and in The packets can follow different paths with various delays, and in
general it can be very difficult to recognize marked packets in a general it can be very difficult to recognize marked packets in a
multipoint-to-multipoint path, especially in the case when there is multipoint-to-multipoint path, especially in the case when there is
more than one per period. more than one per period.
A desirable option is to monitor simultaneously all the paths of a A desirable option is to monitor simultaneously all the paths of a
multipoint path in the same marking period; for this purpose, hashing multipoint path in the same marking period; for this purpose, hashing
can be used, as reported in the next section. can be used, as reported in the next section.
Note that, since the one-way delay measurement is done on a single-
packet basis, it is always possible to calculate the two-way delay
but it is not immediate since it is necessary to couple the
measurement on each single path with the opposite direction. In this
case the NMS can do the calculation.
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-marking] introduces how to use the hash method (RFC [I-D.mizrahi-ippm-marking] introduces how to use the hash method (RFC
skipping to change at page 20, line 20 skipping to change at page 20, line 27
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. number of samples is bounded in each marking period.
In a multipoint environment, the hashing selection MAY be the In a multipoint environment, the hashing selection MAY be the
solution for performing delay measurements on specific packets and solution for performing delay measurements on specific packets and
overcoming the single- and double-marking limitations. overcoming the single- and double-marking limitations.
9. A Closed-Loop Performance-Management Approach 9. Results of the Multipoint Alternate Marking Experiment
The methodology described in the previous sections can be applied to
various performance measurement problems, as also explained in
[I-D.fioccola-rfc8321bis].
Either one or two flag bits might be available for marking in
different deployments:
One flag: packet loss measurement SHOULD be done as described in
Section 5 by applying the network clustering partition described
in Section 6. While delay measurement MAY be done according to
the Mean delay calculation representative of the multipoint path,
as described in Section 8.1.1. Single-marking method based on the
first/last packet of the interval cannot be applied, as mentioned
in Section 8.2.1.
Two flags: packet loss measurement SHOULD be done as described in
Section 5 by applying the network clustering partition described
in Section 6. While delay measurement SHOULD be done on a single
packet basis according to double-marking method Section 8.2.1. In
this case the Mean delay calculation (Section 8.1.1) MAY also be
used as a representative value of a multipoint path.
One flag and hash-based selection: packet loss measurement SHOULD
be done as described in Section 5 by applying the network
clustering partition described in Section 6. Hash-based selection
methodologies, introduced in Section 8.2.2, MAY be used for delay
measurement.
The experiment with Multipoint Alternate Marking methodologies
confirmed the benefits of the Alternate Marking methodology described
in [I-D.fioccola-rfc8321bis], as its extension to the general case of
multipoint-to-multipoint scenarios.
The Multipoint Alternate Marking Method is RECOMMENDED only for
controlled domains, as per [I-D.fioccola-rfc8321bis].
10. 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
clusters that are the smallest subnetworks (group-to-group segments), clusters that are the smallest subnetworks (group-to-group segments),
maintaining the packet-loss property for each subnetwork. The maintaining the packet-loss property for each subnetwork. The
skipping to change at page 21, line 44 skipping to change at page 22, line 42
use a marking period of 1 sec or less. use a marking period of 1 sec or less.
In addition, an SDN controller could also collect the measurement In addition, an SDN controller could also collect the measurement
history. history.
It is important to mention that the Multipoint Alternate Marking It is important to mention that the Multipoint Alternate Marking
framework also helps Traffic Visualization. Indeed, this methodology framework also helps Traffic Visualization. Indeed, this methodology
is very useful for identifying which path or cluster is crossed by is very useful for identifying which path or cluster is crossed by
the flow. the flow.
10. Security Considerations 11. Security Considerations
This document specifies a method of performing measurements that does This document specifies a method of performing measurements that does
not directly affect Internet security or applications that run on the not directly affect Internet security or applications that run on the
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 12. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
12. Contributors 13. Contributors
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.
Email: xiao.min2@zte.com.cn Email: xiao.min2@zte.com.cn
13. Acknowledgements 14. 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 15. References
14.1. Normative References 15.1. Normative References
[I-D.fioccola-rfc8321bis] [I-D.fioccola-rfc8321bis]
Fioccola, G., Cociglio, M., Mirsky, G., and T. Mizrahi, Fioccola, G., Cociglio, M., Mirsky, G., Mizrahi, T., Zhou,
"Alternate-Marking Method", draft-fioccola-rfc8321bis-00 T., and X. Min, "Alternate-Marking Method", draft-
(work in progress), November 2021. fioccola-rfc8321bis-02 (work in progress), February 2022.
[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 14 skipping to change at page 24, line 14
[RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance
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 15.2. Informative References
[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-marking] [I-D.mizrahi-ippm-marking]
Mizrahi, T., Fioccola, G., Cociglio, M., Chen, M., and G. Mizrahi, T., Fioccola, G., Cociglio, M., Chen, M., and G.
Mirsky, "Marking Methods for Performance Measurement", Mirsky, "Marking Methods for Performance Measurement",
skipping to change at page 23, line 36 skipping to change at page 24, line 36
2021. 2021.
[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-08 (work in
progress), July 2021. progress), January 2022.
[IEEE-ACM-ToN-MPNPM] [IEEE-ACM-ToN-MPNPM]
IEEE/ACM TRANSACTION ON NETWORKING, "Multipoint Passive IEEE/ACM TRANSACTION ON NETWORKING, "Multipoint Passive
Monitoring in Packet Networks", Monitoring in Packet Networks",
DOI 10.1109/TNET.2019.2950157, 2019. DOI 10.1109/TNET.2019.2950157, 2019.
[IEEE-Network-PNPM] [IEEE-Network-PNPM]
IEEE Network, "AM-PM: Efficient Network Telemetry using IEEE Network, "AM-PM: Efficient Network Telemetry using
Alternate Marking", DOI 10.1109/MNET.2019.1800152, 2019. Alternate Marking", DOI 10.1109/MNET.2019.1800152, 2019.
skipping to change at page 24, line 29 skipping to change at page 25, line 29
Changes in v-(01) include: Changes in v-(01) include:
o Considerations on BUM traffic o Considerations on BUM traffic
o Reference to RFC8321bis for the fragmentation part o Reference to RFC8321bis for the fragmentation part
o Revised section on "Delay Measurements on a Single-Packet Basis" o Revised section on "Delay Measurements on a Single-Packet Basis"
o Revised section on "Timing Aspects" o Revised section on "Timing Aspects"
Changes in v-(02) include:
o Clarified the formula in the section on "Timing Aspects" to be
aligned with RFC 8321
o Considerations on two-way delay measurements in both sections 8.1
and 8.2 on delay measurements
o Clarified in section 4.1 on "Monitoring Network" that the
description is done for one direction but it can easily be
extended to all direction
o New section on "Results of the Multipoint Alternate Marking
Experiment"
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
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
 End of changes. 35 change blocks. 
74 lines changed or deleted 135 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/