< draft-fz-spring-srv6-alt-mark-00.txt		draft-fz-spring-srv6-alt-mark-01.txt >
	SPRING Working Group G. Fioccola		SPRING Working Group G. Fioccola
	Internet-Draft T. Zhou		Internet-Draft T. Zhou
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: July 23, 2021 M. Cociglio		Expires: January 10, 2022 M. Cociglio
	Telecom Italia		Telecom Italia
	January 19, 2021		July 9, 2021
	Segment Routing Header encapsulation for Alternate Marking Method		Segment Routing Header encapsulation for Alternate Marking Method
	draft-fz-spring-srv6-alt-mark-00		draft-fz-spring-srv6-alt-mark-01
	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 the passive performance measurement tool in an SRv6 network. It		as the passive performance measurement tool in an SRv6 network. It
	defines how Alternate Marking data fields are transported as part of		defines how Alternate Marking data fields are transported as part of
	the Segment Routing with IPv6 data plane (SRv6) header.		the Segment Routing with IPv6 data plane (SRv6) header.
	Requirements Language		Requirements Language
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 23, 2021.		This Internet-Draft will expire on January 10, 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
	2. Application of the Alternate Marking to SRv6 . . . . . . . . 3		2. Application of the Alternate Marking to SRv6 . . . . . . . . 3
	3. Definition of the SRH AltMark TLV . . . . . . . . . . . . . . 3		2.1. Controlled Domain . . . . . . . . . . . . . . . . . . . . 4
			3. Definition of the SRH AltMark TLV . . . . . . . . . . . . . . 4
	3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 4		3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 4
	4. Use of the SRH AltMark TLV . . . . . . . . . . . . . . . . . 5		4. Use of the SRH AltMark TLV . . . . . . . . . . . . . . . . . 6
	5. Alternate Marking Method Operation . . . . . . . . . . . . . 6		5. Alternate Marking Method Operation . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9.1. Normative References . . . . . . . . . . . . . . . . . . 7		9.1. Normative References . . . . . . . . . . . . . . . . . . 8
	9.2. Informative References . . . . . . . . . . . . . . . . . 7		9.2. Informative References . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	[RFC8321] and [RFC8889] describe a passive performance measurement		[RFC8321] and [RFC8889] describe a passive performance measurement
	method, which can be used to measure packet loss, latency and jitter		method, which can be used to measure packet loss, latency and jitter
	on live traffic. Since this method is based on marking consecutive		on live traffic. Since this method is based on marking consecutive
	batches of packets, the method is often referred as Alternate Marking		batches of packets, the method is often referred as Alternate Marking
	Method.		Method.
	This document defines how the Alternate Marking Method ([RFC8321])		This document defines how the Alternate Marking Method ([RFC8321])
	skipping to change at page 3, line 47 ¶		skipping to change at page 3, line 47 ¶
	behaviour. Furthermore the flow label may be changed en route and		behaviour. Furthermore the flow label may be changed en route and
	this may also violate the measurement task. Those reasons make the		this may also violate the measurement task. Those reasons make the
	definition of the FlowMonID necessary for IPv6. Flow Label and		definition of the FlowMonID necessary for IPv6. Flow Label and
	FlowMonID within the same packet have different scope, identify		FlowMonID within the same packet have different scope, identify
	different flows, and associate different uses.		different flows, and associate different uses.
	An important point that will also be discussed in this document is		An important point that will also be discussed in this document is
	the the uniqueness of the FlowMonID and how to allow disambiguation		the the uniqueness of the FlowMonID and how to allow disambiguation
	of the FlowMonID in case of collision.		of the FlowMonID in case of collision.
			The following section highlights an important requirement for the
			application of the Alternate Marking to IPv6 and SRv6. The concept
			of the controlled domain is explained and it is considered an
			essential precondition.
			2.1. Controlled Domain
			[RFC8799] introduces the concept of specific limited domain solutions
			and, in this regard, it is reported the Application of the Alternate
			Marking Method as an example.
			IPv6 has much more flexibility than IPv4 and innovative applications
			have been proposed, but for a number of reasons, such as the
			policies, options supported, the style of network management and
			security requirements, it is suggested to limit some of these
			applications to a controlled domain. This is also the case of the
			Alternate Marking application to SRv6 as assumed hereinafter.
			Therefore, the application of the Alternate Marking Method to SRv6
			MUST NOT be deployed outside a controlled domain. It is RECOMMENDED
			that an implementation can be able to reject packets that carry
			Alternate Marking data and are entering or leaving the controlled
			domains.
	3. Definition of the SRH AltMark TLV		3. Definition of the SRH AltMark TLV
	The desired choice is to define a new TLV for the SRH extension		A new TLV carrying the data fields dedicated to the alternate marking
	headers, carrying the data fields dedicated to the alternate marking		method can be defined for the SRH extension headers.
	method.
	This enables the Alternate Marking Method to take advantage of the		This enables the Alternate Marking Method to take advantage of the
	network programmability capability of SRv6		network programmability capability of SRv6
	([I-D.ietf-spring-srv6-network-programming]). Specifically, the		([I-D.ietf-spring-srv6-network-programming]). Specifically, the
	ability for an SRv6 endpoint to determine whether to process or		ability for an SRv6 endpoint to determine whether to process or
	ignore some specific SRH TLVs is based on the SID function. The		ignore some specific SRH TLVs is based on the SID function. The
	nodes that are not capable of supporting the Alternate Marking		nodes that are not capable of supporting the Alternate Marking
	functionality do not have to look or process the SRH AltMark TLV and		functionality do not have to look or process the SRH AltMark TLV and
	can simply ignore it. This also enables collection of Alternate		can simply ignore it. This also enables collection of Alternate
	Marking data only from the supporting segment endpoints.		Marking data only from the supporting segment endpoints.
	skipping to change at page 6, line 44 ¶		skipping to change at page 7, line 20 ¶
	general. While [I-D.ietf-6man-ipv6-alt-mark] describe in detail the		general. While [I-D.ietf-6man-ipv6-alt-mark] describe in detail the
	application and the Operation of the methodology for IPv6.		application and the Operation of the methodology for IPv6.
	6. Security Considerations		6. Security Considerations
	The security considerations of SRv6 are discussed in [RFC8754] and		The security considerations of SRv6 are discussed in [RFC8754] and
	[I-D.ietf-spring-srv6-network-programming], and the security		[I-D.ietf-spring-srv6-network-programming], and the security
	considerations of Alternate Marking in general and its application to		considerations of Alternate Marking in general and its application to
	IPv6 are discussed in [RFC8321] and [I-D.ietf-6man-ipv6-alt-mark].		IPv6 are discussed in [RFC8321] and [I-D.ietf-6man-ipv6-alt-mark].
	Alternate Marking is a feature applied to a "controlled domain",		The Alternate Marking application to IPv6, defined in
	where one or several operators decide on leveraging and configuring		[I-D.ietf-6man-ipv6-alt-mark], analyzes different security concerns
	Alternate Marking according to their needs. Additionally, operators		and related solutions. These aspects are valid and applicable also
	need to properly secure the Alternate Marking domain to avoid		to this document. In particular the fundamental security requirement
	malicious configuration and use, which could include injecting		is that Alternate Marking MUST be applied in a specific limited
	malicious packets into a domain.		domain, as also mentioned in [RFC8799].
			Alternate Marking is a feature applied to a trusted domain, where one
			or several operators decide on leveraging and configuring Alternate
			Marking according to their needs. Additionally, operators need to
			properly secure the Alternate Marking domain to avoid malicious
			configuration and attacks, which could include injecting malicious
			packets into a domain. So the implementation of Alternate Marking is
			applied within a controlled domain where the network nodes are
			locally administered. A limited administrative domain provides the
			network administrator with the means to select, monitor and control
			the access to the network.
	7. IANA Considerations		7. IANA Considerations
	The SRH TLV Type should be assigned in IANA's Segment Routing Header		The SRH TLV Type should be assigned in IANA's Segment Routing Header
	TLVs Registry.		TLVs Registry.
	This draft requests to allocate a SRH TLV Type for Alternate Marking		This draft requests to allocate a SRH TLV Type for Alternate Marking
	TLV data fields under registry name "Segment Routing Header TLVs"		TLV data fields under registry name "Segment Routing Header TLVs"
	requested by [RFC8754].		requested by [RFC8754].
	skipping to change at page 7, line 34 ¶		skipping to change at page 8, line 21 ¶
	9.1. Normative References		9.1. Normative References
	[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>.
	9.2. Informative References		9.2. Informative References
	[I-D.fioccola-v6ops-ipv6-alt-mark]		[I-D.fioccola-v6ops-ipv6-alt-mark]
	Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6		Fioccola, G., Velde, G. V. D., Cociglio, M., and P. Muley,
	Performance Measurement with Alternate Marking Method",		"IPv6 Performance Measurement with Alternate Marking
	draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress),		Method", draft-fioccola-v6ops-ipv6-alt-mark-01 (work in
	June 2018.		progress), June 2018.
	[I-D.ietf-6man-ipv6-alt-mark]		[I-D.ietf-6man-ipv6-alt-mark]
	Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.		Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
	Pang, "IPv6 Application of the Alternate Marking Method",		Pang, "IPv6 Application of the Alternate Marking Method",
	draft-ietf-6man-ipv6-alt-mark-02 (work in progress),		draft-ietf-6man-ipv6-alt-mark-04 (work in progress), March
	October 2020.		2021.
	[I-D.ietf-spring-segment-routing-policy]		[I-D.ietf-spring-segment-routing-policy]
	Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and		Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
	P. Mattes, "Segment Routing Policy Architecture", draft-		P. Mattes, "Segment Routing Policy Architecture", draft-
	ietf-spring-segment-routing-policy-09 (work in progress),		ietf-spring-segment-routing-policy-11 (work in progress),
	November 2020.		April 2021.
	[I-D.ietf-spring-srv6-network-programming]		[I-D.ietf-spring-srv6-network-programming]
	Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,		Filsfils, C., Garvia, P. C., Leddy, J., Voyer, D.,
	Matsushima, S., and Z. Li, "SRv6 Network Programming",		Matsushima, S., and Z. Li, "Segment Routing over IPv6
	draft-ietf-spring-srv6-network-programming-28 (work in		(SRv6) Network Programming", draft-ietf-spring-srv6-
	progress), December 2020.		network-programming-28 (work in progress), December 2020.
	[I-D.voyer-6man-extension-header-insertion]		[I-D.voyer-6man-extension-header-insertion]
	Voyer, D., Filsfils, C., Dukes, D., Matsushima, S., Leddy,		Voyer, D., Filsfils, C., Dukes, D., Matsushima, S., Leddy,
	J., Li, Z., and J. Guichard, "Deployments With Insertion		J., Li, Z., and J. Guichard, "Deployments With Insertion
	of IPv6 Segment Routing Headers", draft-voyer-6man-		of IPv6 Segment Routing Headers", draft-voyer-6man-
	extension-header-insertion-10 (work in progress), November		extension-header-insertion-10 (work in progress), November
	2020.		2020.
	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,		(IPv6) Specification", STD 86, RFC 8200,
	skipping to change at page 8, line 34 ¶		skipping to change at page 9, line 21 ¶
	L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,		L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
	"Alternate-Marking Method for Passive and Hybrid		"Alternate-Marking Method for Passive and Hybrid
	Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,		Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
	January 2018, <https://www.rfc-editor.org/info/rfc8321>.		January 2018, <https://www.rfc-editor.org/info/rfc8321>.
	[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,		[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
	Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header		Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
	(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,		(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
	<https://www.rfc-editor.org/info/rfc8754>.		<https://www.rfc-editor.org/info/rfc8754>.
			[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
			Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
			<https://www.rfc-editor.org/info/rfc8799>.
	[RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto,		[RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto,
	"Multipoint Alternate-Marking Method for Passive and		"Multipoint Alternate-Marking Method for Passive and
	Hybrid Performance Monitoring", RFC 8889,		Hybrid Performance Monitoring", RFC 8889,
	DOI 10.17487/RFC8889, August 2020,		DOI 10.17487/RFC8889, August 2020,
	<https://www.rfc-editor.org/info/rfc8889>.		<https://www.rfc-editor.org/info/rfc8889>.
	Authors' Addresses		Authors' Addresses
	Giuseppe Fioccola		Giuseppe Fioccola
	Huawei		Huawei
End of changes. 15 change blocks.
	34 lines changed or deleted		73 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/