< draft-ietf-6man-ipv6-alt-mark-13.txt   draft-ietf-6man-ipv6-alt-mark-14.txt >
6MAN Working Group G. Fioccola 6MAN Working Group G. Fioccola
Internet-Draft T. Zhou Internet-Draft T. Zhou
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: October 2, 2022 M. Cociglio Expires: October 30, 2022 M. Cociglio
Telecom Italia Telecom Italia
F. Qin F. Qin
China Mobile China Mobile
R. Pang R. Pang
China Unicom China Unicom
March 31, 2022 April 28, 2022
IPv6 Application of the Alternate Marking Method IPv6 Application of the Alternate Marking Method
draft-ietf-6man-ipv6-alt-mark-13 draft-ietf-6man-ipv6-alt-mark-14
Abstract Abstract
This document describes how the Alternate Marking Method can be used This document describes how the Alternate Marking Method can be used
as a passive performance measurement tool in an IPv6 domain. It as a passive performance measurement tool in an IPv6 domain. It
defines a new Extension Header Option to encode Alternate Marking defines a new Extension Header Option to encode Alternate Marking
information in both the Hop-by-Hop Options Header and Destination information in both the Hop-by-Hop Options Header and Destination
Options Header. Options Header.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 October 2, 2022. This Internet-Draft will expire on October 30, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3. Definition of the AltMark Option . . . . . . . . . . . . . . 7 3. Definition of the AltMark Option . . . . . . . . . . . . . . 7
3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 7 3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 7
4. Use of the AltMark Option . . . . . . . . . . . . . . . . . . 8 4. Use of the AltMark Option . . . . . . . . . . . . . . . . . . 8
5. Alternate Marking Method Operation . . . . . . . . . . . . . 10 5. Alternate Marking Method Operation . . . . . . . . . . . . . 10
5.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 10 5.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 10
5.2. Packet Delay Measurement . . . . . . . . . . . . . . . . 12 5.2. Packet Delay Measurement . . . . . . . . . . . . . . . . 12
5.3. Flow Monitoring Identification . . . . . . . . . . . . . 13 5.3. Flow Monitoring Identification . . . . . . . . . . . . . 13
5.4. Multipoint and Clustered Alternate Marking . . . . . . . 15 5.4. Multipoint and Clustered Alternate Marking . . . . . . . 15
5.5. Data Collection and Calculation . . . . . . . . . . . . . 16 5.5. Data Collection and Calculation . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
[I-D.fioccola-rfc8321bis] and [I-D.fioccola-rfc8889bis] describe a [I-D.ietf-ippm-rfc8321bis] and [I-D.ietf-ippm-rfc8889bis] describe a
passive performance measurement method, which can be used to measure passive performance measurement method, which can be used to measure
packet loss, latency and jitter on live traffic. Since this method packet loss, latency and jitter on live traffic. Since this method
is based on marking consecutive batches of packets, the method is is based on marking consecutive batches of packets, the method is
often referred to as the Alternate Marking Method. often referred to as the Alternate Marking Method.
This document defines how the Alternate Marking Method can be used to This document defines how the Alternate Marking Method can be used to
measure performance metrics in IPv6. The rationale is to apply the measure performance metrics in IPv6. The rationale is to apply the
Alternate Marking methodology to IPv6 and therefore allow detailed Alternate Marking methodology to IPv6 and therefore allow detailed
packet loss, delay and delay variation measurements both hop-by-hop packet loss, delay and delay variation measurements both hop-by-hop
and end-to-end to exactly locate the issues in an IPv6 network. and end-to-end to exactly locate the issues in an IPv6 network.
skipping to change at page 3, line 30 skipping to change at page 3, line 30
domain. domain.
The threat model for the application of the Alternate Marking Method The threat model for the application of the Alternate Marking Method
in an IPv6 domain is reported in Section 6. As with all on-path in an IPv6 domain is reported in Section 6. As with all on-path
telemetry techniques, the only definitive solution is that this telemetry techniques, the only definitive solution is that this
methodology MUST be applied in a controlled domain. methodology MUST be applied in a controlled domain.
1.1. Terminology 1.1. Terminology
This document uses the terms related to the Alternate Marking Method This document uses the terms related to the Alternate Marking Method
as defined in [I-D.fioccola-rfc8321bis] and as defined in [I-D.ietf-ippm-rfc8321bis] and
[I-D.fioccola-rfc8889bis]. [I-D.ietf-ippm-rfc8889bis].
1.2. Requirements Language 1.2. 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. Alternate Marking application to IPv6 2. Alternate Marking application to IPv6
skipping to change at page 8, line 8 skipping to change at page 8, line 8
this Option if they do not recognize and that the data of this this Option if they do not recognize and that the data of this
Option do not change en route, indeed the source is the only one Option do not change en route, indeed the source is the only one
that can write it. that can write it.
o Opt Data Len: 4. It is the length of the Option Data Fields of o Opt Data Len: 4. It is the length of the Option Data Fields of
this Option in bytes. this Option in bytes.
o FlowMonID: 20-bit unsigned integer. The FlowMon identifier is o FlowMonID: 20-bit unsigned integer. The FlowMon identifier is
described in Section 5.3. As further discussed below, it has been described in Section 5.3. As further discussed below, it has been
picked as 20 bits since it is a reasonable value and a good picked as 20 bits since it is a reasonable value and a good
compromise in relation to the chance of collision if it is set compromise in relation to the chance of collision. It MUST be set
pseudo randomly by the source node or set by a centralized pseudo randomly by the source node or by a centralized controller.
controller.
o L: Loss flag for Packet Loss Measurement as described in o L: Loss flag for Packet Loss Measurement as described in
Section 5.1; Section 5.1;
o D: Delay flag for Single Packet Delay Measurement as described in o D: Delay flag for Single Packet Delay Measurement as described in
Section 5.2; Section 5.2;
o Reserved: is reserved for future use. These bits MUST be set to o Reserved: is reserved for future use. These bits MUST be set to
zero on transmission and ignored on receipt. zero on transmission and ignored on receipt.
skipping to change at page 10, line 17 skipping to change at page 10, line 16
it is important to be aware that the things may be different in the it is important to be aware that the things may be different in the
implementation and it can happen that packets with Hop-by-Hop are implementation and it can happen that packets with Hop-by-Hop are
forced onto the slow path, but this is a general issue, as also forced onto the slow path, but this is a general issue, as also
explained in [I-D.hinden-6man-hbh-processing]. It is also worth explained in [I-D.hinden-6man-hbh-processing]. It is also worth
mentioning that the application to a controlled domain should avoid mentioning that the application to a controlled domain should avoid
the risk of arbitrary nodes dropping packets with Hop-by-Hop Options. the risk of arbitrary nodes dropping packets with Hop-by-Hop Options.
5. Alternate Marking Method Operation 5. Alternate Marking Method Operation
This section describes how the method operates. This section describes how the method operates.
[I-D.fioccola-rfc8321bis] introduces several applicable methods which [I-D.ietf-ippm-rfc8321bis] introduces several applicable methods
are reported below, and a new field is introduced to facilitate the which are reported below, and a new field is introduced to facilitate
deployment and improve the scalability. the deployment and improve the scalability.
5.1. Packet Loss Measurement 5.1. Packet Loss Measurement
The measurement of the packet loss is really straightforward in The measurement of the packet loss is really straightforward in
comparison to the existing mechanisms, as detailed in comparison to the existing mechanisms, as detailed in
[I-D.fioccola-rfc8321bis]. The packets of the flow are grouped into [I-D.ietf-ippm-rfc8321bis]. The packets of the flow are grouped into
batches, and all the packets within a batch are marked by setting the batches, and all the packets within a batch are marked by setting the
L bit (Loss flag) to a same value. The source node can switch the L bit (Loss flag) to a same value. The source node can switch the
value of the L bit between 0 and 1 after a fixed number of packets or value of the L bit between 0 and 1 after a fixed number of packets or
according to a fixed timer, and this depends on the implementation. according to a fixed timer, and this depends on the implementation.
The source node is the only one that marks the packets to create the The source node is the only one that marks the packets to create the
batches, while the intermediate nodes only read the marking values batches, while the intermediate nodes only read the marking values
and identify the packet batches. By counting the number of packets and identify the packet batches. By counting the number of packets
in each batch and comparing the values measured by different network in each batch and comparing the values measured by different network
nodes along the path, it is possible to measure the packet loss nodes along the path, it is possible to measure the packet loss
occurred in any single batch between any two nodes. Each batch occurred in any single batch between any two nodes. Each batch
represents a measurable entity recognizable by all network nodes represents a measurable entity recognizable by all network nodes
along the path. along the path.
Both fixed number of packets and fixed timer can be used by the Both fixed number of packets and fixed timer can be used by the
source node to create packet batches. But, as also explained in source node to create packet batches. But, as also explained in
[I-D.fioccola-rfc8321bis], the timer-based batches are preferable [I-D.ietf-ippm-rfc8321bis], the timer-based batches are preferable
because they are more deterministic than the counter-based batches. because they are more deterministic than the counter-based batches.
There is no definitive rule for counter-based batches, differently There is no definitive rule for counter-based batches, differently
from timer-based batches. Using a fixed timer for the switching from timer-based batches. Using a fixed timer for the switching
offers better control over the method, indeed the length of the offers better control over the method, indeed the length of the
batches can be chosen large enough to simplify the collection and the batches can be chosen large enough to simplify the collection and the
comparison of the measures taken by different network nodes. In the comparison of the measures taken by different network nodes. In the
implementation the counters can be sent out by each node to the implementation the counters can be sent out by each node to the
controller that is responsible for the calculation. It is also controller that is responsible for the calculation. It is also
possible to exchange this information by using other on-path possible to exchange this information by using other on-path
techniques. But this is out of scope for this document. techniques. But this is out of scope for this document.
Packets with different L values may get swapped at batch boundaries, Packets with different L values may get swapped at batch boundaries,
and in this case, it is required that each marked packet can be and in this case, it is required that each marked packet can be
assigned to the right batch by each router. It is important to assigned to the right batch by each router. It is important to
mention that for the application of this method there are two mention that for the application of this method there are two
elements to consider: the clock error between network nodes and the elements to consider: the clock error between network nodes and the
network delay. These can create offsets between the batches and out- network delay. These can create offsets between the batches and out-
of-order of the packets. The mathematical formula on timing aspects, of-order of the packets. The mathematical formula on timing aspects,
explained in section 5 of [I-D.fioccola-rfc8321bis], must be explained in section 5 of [I-D.ietf-ippm-rfc8321bis], must be
satisfied and it takes into considerations the different causes of satisfied and it takes into considerations the different causes of
reordering such as clock error and network delay. The assumption is reordering such as clock error and network delay. The assumption is
to define the available counting interval where to get stable to define the available counting interval where to get stable
counters and to avoid these issues. Specifically, if the effects of counters and to avoid these issues. Specifically, if the effects of
network delay are ignored, the condition to implement the methodology network delay are ignored, the condition to implement the methodology
is that the clocks in different nodes MUST be synchronized to the is that the clocks in different nodes MUST be synchronized to the
same clock reference with an accuracy of +/- B/2 time units, where B same clock reference with an accuracy of +/- B/2 time units, where B
is the fixed time duration of the batch, which refers to the original is the fixed time duration of the batch, which refers to the original
marking interval at the source node considering that this interval marking interval at the source node considering that this interval
could fluctuate along the path. In this way each marked packet can could fluctuate along the path. In this way each marked packet can
skipping to change at page 14, line 20 skipping to change at page 14, line 20
the collectors. the collectors.
The FlowMonID MUST only be used as a monitored flow identifier in The FlowMonID MUST only be used as a monitored flow identifier in
order to determine a monitored flow within the measurement domain. order to determine a monitored flow within the measurement domain.
This entails not only an easy identification but improved correlation This entails not only an easy identification but improved correlation
as well. as well.
The value of 20 bits has been selected for the FlowMonID since it is The value of 20 bits has been selected for the FlowMonID since it is
a good compromise and implies a low rate of ambiguous FlowMonIDs that a good compromise and implies a low rate of ambiguous FlowMonIDs that
can be considered acceptable in most of the applications. The can be considered acceptable in most of the applications. The
disambiguation issue is more visible when the FlowMonID is pseudo disambiguation issue can be solved by tagging the pseudo randomly
randomly generated but, it can be solved by tagging the FlowMonID generated FlowMonID with additional flow information. In particular,
with additional flow information. In particular, it is RECOMMENDED it is RECOMMENDED to consider the 3-tuple FlowMonID, source and
to consider the 3-tuple FlowMonID, source and destination addresses: destination addresses:
o If the 20 bit FlowMonID is set independently and pseudo randomly o If the 20 bit FlowMonID is set independently and pseudo randomly
in a distributed way there is a chance of collision. Indeed, by in a distributed way there is a chance of collision. Indeed, by
using the well-known birthday problem in probability theory, if using the well-known birthday problem in probability theory, if
the 20 bit FlowMonID is set independently and pseudo randomly the 20 bit FlowMonID is set independently and pseudo randomly
without any additional input entropy, there is a 50% chance of without any additional input entropy, there is a 50% chance of
collision for 1206 flows. So, for more entropy, FlowMonID is collision for 1206 flows. So, for more entropy, FlowMonID is
combined with source and destination addresses. Since there is a combined with source and destination addresses. Since there is a
1% chance of collision for 145 flows, it is possible to monitor 1% chance of collision for 145 flows, it is possible to monitor
145 concurrent flows per host pairs with a 1% chance of collision. 145 concurrent flows per host pairs with a 1% chance of collision.
o If the 20 bits FlowMonID is set in a centralized way, the o If the 20 bits FlowMonID is set pseudo randomly but in a
controller can instruct the nodes properly in order to guarantee centralized way, the controller can instruct the nodes properly in
the uniqueness of the FlowMonID. With 20 bits, the number of order to guarantee the uniqueness of the FlowMonID. With 20 bits,
combinations is 1048576, and the controller should ensure that all the number of combinations is 1048576, and the controller should
the FlowMonID values are used without any collision. Therefore, ensure that all the FlowMonID values are used without any
by considering source and destination addresses together with the collision. Therefore, by considering source and destination
FlowMonID, it can be possible to monitor 1048576 concurrent flows addresses together with the FlowMonID, it can be possible to
per host pairs. monitor 1048576 concurrent flows per host pairs.
A consistent approach MUST be used in the Alternate Marking A consistent approach MUST be used in the Alternate Marking
deployment to avoid the mixture of different ways of identifying. deployment to avoid the mixture of different ways of identifying.
All the nodes along the path and involved into the measurement SHOULD All the nodes along the path and involved into the measurement SHOULD
use the same mode for identification. As mentioned, it is use the same mode for identification. As mentioned, it is
RECOMMENDED to use the FlowMonID for identification purpose in RECOMMENDED to use the FlowMonID for identification purpose in
combination with source and destination addresses to identify a flow. combination with source and destination addresses to identify a flow.
By considering source and destination addresses together with the By considering source and destination addresses together with the
FlowMonID it can be possible to monitor 145 concurrent flows per host FlowMonID it can be possible to monitor 145 concurrent flows per host
pairs with a 1% chance of collision in case of pseudo randomly pairs with a 1% chance of collision in case of pseudo randomly
generated FlowMonID, or 1048576 concurrent flows per host pairs in generated FlowMonID, or 1048576 concurrent flows per host pairs in
case of centralized controller. It is worth mentioning that the case of centralized controller. It is worth mentioning that the
solution with the centralized control allows finer granularity and solution with the centralized control allows finer granularity and
therefore adds even more flexibility to the flow identification. therefore adds even more flexibility to the flow identification.
The FlowMonID field is set at the source node, which is the ingress The FlowMonID field is set at the source node, which is the ingress
point of the measurement domain, and can be set in two ways: point of the measurement domain, and can be set in two ways:
a. It can be algorithmically generated by the source node, that can a. It can be algorithmically generated by the source node, that can
set it pseudo-randomly with some chance of collision. This set it pseudo-randomly with some chance of collision. This
approach cannot guarantee the uniqueness of FlowMonID but, approach cannot guarantee the uniqueness of FlowMonID since
considering the recommendation to use FlowMonID with source and conflicts and collisions are possible. But, considering the
destination addresses the conflict probability is reduced due to recommendation to use FlowMonID with source and destination
the FlowMonID space available for each endpoint pair (i.e. 145 addresses the conflict probability is reduced due to the
flows with 1% chance of collision). FlowMonID space available for each endpoint pair (i.e. 145 flows
with 1% chance of collision).
b. It can be assigned by the central controller. Since the b. It can be assigned by the central controller. Since the
controller knows the network topology, it can set the value controller knows the network topology, it can allocate the value
properly to avoid or minimize ambiguity and guarantee the properly to avoid or minimize ambiguity and guarantee the
uniqueness. In this regard, the controller can simply verify uniqueness. In this regard, the controller can verify that there
that there is no ambiguity between different pseudo-randomly is no ambiguity between different pseudo-randomly generated
generated FlowMonIDs on the same path. The conflict probability FlowMonIDs on the same path. The conflict probability is really
is really small given that the FlowMonID is coupled with source small given that the FlowMonID is coupled with source and
and destination addresses and up to 1048576 flows can be destination addresses and up to 1048576 flows can be monitored
monitored for each endpoint pair. for each endpoint pair. When all values in the FlowMonID space
are consumed, the centralized controller can keep track and
reassign the values that are not used any more by old flows.
If the FlowMonID is set by the source node, the intermediate nodes If the FlowMonID is set by the source node, the intermediate nodes
can read the FlowMonIDs from the packets in flight and act can read the FlowMonIDs from the packets in flight and act
accordingly. While, if the FlowMonID is set by the controller, both accordingly. While, if the FlowMonID is set by the controller, both
possibilities are feasible for the intermediate nodes which can learn possibilities are feasible for the intermediate nodes which can learn
by reading the packets or can be instructed by the controller. by reading the packets or can be instructed by the controller.
When all values in the FlowMonID space are consumed, the centralized
controller can keep track and reassign the values that are not used
any more by old flows, while if the FlowMonID is pseudo randomly
generated by the source, conflicts and collisions are possible.
5.4. Multipoint and Clustered Alternate Marking 5.4. Multipoint and Clustered Alternate Marking
The Alternate Marking method can also be extended to any kind of The Alternate Marking method can also be extended to any kind of
multipoint to multipoint paths, and the network clustering approach multipoint to multipoint paths, and the network clustering approach
allows a flexible and optimized performance measurement, as described allows a flexible and optimized performance measurement, as described
in [I-D.fioccola-rfc8889bis]. in [I-D.ietf-ippm-rfc8889bis].
The Cluster is the smallest identifiable subnetwork of the entire The Cluster is the smallest identifiable subnetwork of the entire
Network graph that still satisfies the condition that the number of Network graph that still satisfies the condition that the number of
packets that goes in is the same that goes out. With network packets that goes in is the same that goes out. 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. So, for Multipoint Alternate Marking, FlowMonID can identify detail. So, for Multipoint Alternate Marking, FlowMonID can identify
in general a multipoint-to-multipoint flow and not only a point-to- in general a multipoint-to-multipoint flow and not only a point-to-
point flow. point flow.
skipping to change at page 17, line 21 skipping to change at page 17, line 19
type of attack can be avoided. For this reason, the implementation type of attack can be avoided. For this reason, the implementation
of the method is not done on the end node if it is not fully managed of the method is not done on the end node if it is not fully managed
and does not belong to the controlled domain. Packets generated and does not belong to the controlled domain. Packets generated
outside the controlled domain may consume router resources by outside the controlled domain may consume router resources by
maliciously using the HbH Option, but this can be mitigated by maliciously using the HbH Option, but this can be mitigated by
filtering these packets at the controlled domain boundary. This can filtering these packets at the controlled domain boundary. This can
be done because, if the end node does not belong to the controlled be done because, if the end node does not belong to the controlled
domain, it is not supposed to add the AltMark HbH Option, and it can domain, it is not supposed to add the AltMark HbH Option, and it can
be easily recognized. be easily recognized.
An attacker that does not belong to the controlled domain can
maliciously send packets with AltMark Option. But if Alternate
Marking is not supported in the controlled domain, no problem happens
because the AltMark Option is treated as any other unrecognized
option and will not be considered by the nodes since they are not
configured to deal with it, so the only effect is the increased MTU
(by 48 bits). While if Alternate Marking is supported in the
controlled domain, it is also necessary to avoid that the
measurements are affected and external packets with AltMark Option
MUST be filtered. As any other Hop-by-Hop Options or Destination
Options, it is possible to filter AltMark Options entering or leaving
the domain e.g. by using ACL extensions for filtering.
The flow identifier (FlowMonID) composes the AltMark Option together The flow identifier (FlowMonID) composes the AltMark Option together
with the two marking bits (L and D). As explained in Section 5.3, with the two marking bits (L and D). As explained in Section 5.3,
there is a chance of collision if the FlowMonID is set pseudo there is a chance of collision if the FlowMonID is set pseudo
randomly and a solution exists. In general this may not be a problem randomly and a solution exists. In general this may not be a problem
and a low rate of ambiguous FlowMonIDs can be acceptable, since this and a low rate of ambiguous FlowMonIDs can be acceptable, since this
does not cause significant harm to the operators or their clients and does not cause significant harm to the operators or their clients and
this harm may not justify the complications of avoiding it. But, for this harm may not justify the complications of avoiding it. But, for
large scale measurements, a big number of flows could be monitored large scale measurements, a big number of flows could be monitored
and the probability of a collision is higher, thus the disambiguation and the probability of a collision is higher, thus the disambiguation
of the FlowMonID field can be considered. of the FlowMonID field can be considered.
skipping to change at page 18, line 48 skipping to change at page 19, line 9
domain boundaries to filter both external packets with AltMark Option domain boundaries to filter both external packets with AltMark Option
entering the domain and internal packets with AltMark Option leaving entering the domain and internal packets with AltMark Option leaving
the domain. Therefore, the trusted domain is unlikely subject to the domain. Therefore, the trusted domain is unlikely subject to
hijacking of packets since packets with AltMark Option are processed hijacking of packets since packets with AltMark Option are processed
and used only within the controlled domain. and used only within the controlled domain.
As stated, the application to a controlled domain ensures the control As stated, the application to a controlled domain ensures the control
over the packets entering and leaving the domain, but despite that, over the packets entering and leaving the domain, but despite that,
leakages may happen for different reasons, such as a failure or a leakages may happen for different reasons, such as a failure or a
fault. In this case, nodes outside the domain MUST simply ignore fault. In this case, nodes outside the domain MUST simply ignore
packets with AltMark Option since they should not process it. packets with AltMark Option since they are not configured to handle
it and should not process it.
Additionally, it is to be noted that the AltMark Option is carried by Additionally, it is to be noted that the AltMark Option is carried by
the Options Header and it may have some impact on the packet sizes the Options Header and it may have some impact on the packet sizes
for the monitored flow and on the path MTU, since some packets might for the monitored flow and on the path MTU, since some packets might
exceed the MTU. However, the relative small size (48 bit in total) exceed the MTU. However, the relative small size (48 bit in total)
of these Option Headers and its application to a controlled domain of these Option Headers and its application to a controlled domain
help to mitigate the problem. help to mitigate the problem.
It is worth mentioning that the security concerns may change based on It is worth mentioning that the security concerns may change based on
the specific deployment scenario and related threat analysis, which the specific deployment scenario and related threat analysis, which
skipping to change at page 20, line 22 skipping to change at page 20, line 32
The authors would like to thank Bob Hinden, Ole Troan, Martin Duke, The authors would like to thank Bob Hinden, Ole Troan, Martin Duke,
Lars Eggert, Roman Danyliw, Alvaro Retana, Eric Vyncke, Warren Lars Eggert, Roman Danyliw, Alvaro Retana, Eric Vyncke, Warren
Kumari, Benjamin Kaduk, Stewart Bryant, Christopher Wood, Yoshifumi Kumari, Benjamin Kaduk, Stewart Bryant, Christopher Wood, Yoshifumi
Nishida, Tom Herbert, Stefano Previdi, Brian Carpenter, Greg Mirsky, Nishida, Tom Herbert, Stefano Previdi, Brian Carpenter, Greg Mirsky,
Ron Bonica for the precious comments and suggestions. Ron Bonica for the precious comments and suggestions.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.fioccola-rfc8321bis] [I-D.ietf-ippm-rfc8321bis]
Fioccola, G., Cociglio, M., Mirsky, G., Mizrahi, T., Zhou, Fioccola, G., Cociglio, M., Mirsky, G., Mizrahi, T., and
T., and X. Min, "Alternate-Marking Method", draft- T. Zhou, "Alternate-Marking Method", draft-ietf-ippm-
fioccola-rfc8321bis-03 (work in progress), February 2022. rfc8321bis-01 (work in progress), April 2022.
[I-D.fioccola-rfc8889bis] [I-D.ietf-ippm-rfc8889bis]
Fioccola, G., Cociglio, M., Sapio, A., Sisto, R., and T. Fioccola, G., Cociglio, M., Sapio, A., Sisto, R., and T.
Zhou, "Multipoint Alternate-Marking Method", draft- Zhou, "Multipoint Alternate-Marking Clustered Method",
fioccola-rfc8889bis-03 (work in progress), February 2022. draft-ietf-ippm-rfc8889bis-01 (work in progress), April
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>.
[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>.
 End of changes. 25 change blocks. 
56 lines changed or deleted 68 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/