< draft-ietf-6man-ipv6-alt-mark-10.txt		draft-ietf-6man-ipv6-alt-mark-11.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: March 18, 2022 M. Cociglio		Expires: April 24, 2022 M. Cociglio
	Telecom Italia		Telecom Italia
	F. Qin		F. Qin
	China Mobile		China Mobile
	R. Pang		R. Pang
	China Unicom		China Unicom
	September 14, 2021		October 21, 2021
	IPv6 Application of the Alternate Marking Method		IPv6 Application of the Alternate Marking Method
	draft-ietf-6man-ipv6-alt-mark-10		draft-ietf-6man-ipv6-alt-mark-11
	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 March 18, 2022.		This Internet-Draft will expire on April 24, 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
	skipping to change at page 14, line 12 ¶		skipping to change at page 14, line 12 ¶
	a flexible granularity for the flow definition, indeed, it can be		a flexible granularity for the flow definition, indeed, it can be
	used together with other identifiers (e.g. 5-tuple).		used together with other identifiers (e.g. 5-tuple).
	o Second, it simplifies the counters handling. Hardware processing		o Second, it simplifies the counters handling. Hardware processing
	of flow tuples (and ACL matching) is challenging and often incurs		of flow tuples (and ACL matching) is challenging and often incurs
	into performance issues, especially in tunnel interfaces.		into performance issues, especially in tunnel interfaces.
	o Third, it eases the data export encapsulation and correlation for		o Third, it eases the data export encapsulation and correlation for
	the collectors.		the collectors.
	The FlowMonID MUST only be used as a monitored flow identifier and		The FlowMonID MUST only be used as a monitored flow identifier in
	two usage modes can be possible:		order to determine a monitored flow within the measurement domain.
			This entails not only an easy identification but improved correlation
	* using just the FlowMonID for identification purpose. This		as well.
	entails not only an easy identification but improved correlation
	as well;
	* using FlowMonID in combination with the tuples to identify a		The value of 20 bits has been selected for the FlowMonID since it is
	flow. This also allows finer granularity and therefore adds		a good compromise and implies a low rate of ambiguous FlowMonIDs that
	flexibility to the flow identification.		can be considered acceptable in most of the applications. Indeed,
			with 20 bits the number of combinations is 1048576. The requirement
			of the controlled domain also reduces the probability of FlowMonID
			collisions, since the AltMark Option is not spread over the internet.
	The FlowMon identifier field is to determine a monitored flow within		A consistent approach MUST be used in the implementation to avoid the
	the measurement domain. It is RECOMMENDED to use a consistent		mixture of different ways of identifying. Therefore, all the nodes
	approach in the implementation to avoid the mixture of different ways		along the path and involved into the measurement SHOULD use the same
	of identifying. Therefore, all the nodes along the path and involved		mode for identification. It is RECOMMENDED to use the FlowMonID for
	into the measurement SHOULD use the same mode for identification		identification purpose in combination with source and destination
	(FlowMonID alone or in combination with other identifiers).		addresses to identify a flow. By considering source and destination
			addresses together with the the FlowMonID it can be possible to
			monitor 1048576 concurrent flows per host pairs. This allows finer
			granularity and 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:
	* It can be assigned by the central controller. Since the		* 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 set 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 that		uniqueness. In this regard, the controller can simply verify that
	there is no ambiguity between different pseudo-randomly generated		there is no ambiguity between different pseudo-randomly generated
	FlowMonIDs on the same path.		FlowMonIDs on the same path.
	* It can be algorithmically generated by the source node, that can		* 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 it may		approach cannot guarantee the uniqueness of FlowMonID but,
	be preferred for local or private networks, where the conflict		considering the recommendation to use FlowMonID with source and
	probability is small due to the large FlowMonID space.		destination addresses the conflict probability is small due to the
			large FlowMonID space available for each endpoint pair.
	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
	can be considered acceptable in most of the applications. Indeed,
	with 20 bits the number of combinations is 1048576.
	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		When all values in the FlowMonID space are consumed, the centralized
	controller can keep track and reassign the values that are not used		controller can keep track and reassign the values that are not used
	any more by old flows, while if the FlowMonID is pseudo randomly		any more by old flows, while if the FlowMonID is pseudo randomly
	generated by the source, conflicts and collisions are possible.		generated by the source, conflicts and collisions are possible.
	5.3.1. Uniqueness of FlowMonID		5.3.1. Uniqueness of FlowMonID
	It is important to note that if the 20 bit FlowMonID is set		It is important to note that if the 20 bit FlowMonID is set
	independently and pseudo randomly there is a chance of collision.		independently and pseudo randomly there is a chance of collision.
	Indeed, by using the well-known birthday problem in probability		Indeed, by using the well-known birthday problem in probability
	theory, if the 20 bit FlowMonID is set independently and pseudo		theory, if the 20 bit FlowMonID is set independently and pseudo
	randomly without any additional input entropy, there is a 50% chance		randomly without any additional input entropy, there is a 50% chance
	of collision for 1206 flows. So, for more entropy, FlowMonID can		of collision for 1206 flows. So, for more entropy, FlowMonID SHOULD
	either be combined with other identifying flow information in a		be combined with other identifying flow information in a packet and,
	packet (e.g. it is possible to consider the hashed 3-tuple Flow		as mentioned, it is RECOMMENDED to consider the 3-tuple FlowMonID,
	Label, Source and Destination addresses).		source and destination addresses.
	This issue is more visible when the FlowMonID is pseudo randomly		This issue is more visible when the FlowMonID is pseudo randomly
	generated by the source node and there needs to tag it with		generated by the source node and there needs to tag it with
	additional flow information to allow disambiguation. While, in case		additional flow information (i.e. source and destination addresses)
	of a centralized controller, the controller should consider these		to allow disambiguation. While, in case of a centralized controller,
	aspects and instruct the nodes properly in order to guarantee its		the controller should consider these aspects and instruct the nodes
	uniqueness.		properly in order to guarantee its uniqueness.
	It is worth highlighting that in most of the applications a low rate
	of ambiguous FlowMonIDs can be acceptable, since this only affects
	the measurement. For large scale measurements, where it is possible
	to monitor a big number of flows, the disambiguation of the FlowMonID
	field is something to take into account.
	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 [RFC8889].		in [RFC8889].
	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
End of changes. 10 change blocks.
	41 lines changed or deleted		36 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/