draft-ietf-mpls-mna-usecases-11.txt		draft-ietf-mpls-mna-usecases-12.txt
	MPLS Working Group T. Saad		MPLS Working Group T. Saad
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems, Inc.
	Intended status: Informational K. Makhijani		Intended status: Informational K. Makhijani
	Expires: 28 February 2025 Independent		Expires: 16 March 2025 Independent
	H. Song		H. Song
	Futurewei Technologies		Futurewei Technologies
	G. Mirsky		G. Mirsky
	Ericsson		Ericsson
	27 August 2024		12 September 2024
	Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data		Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data
	draft-ietf-mpls-mna-usecases-11		draft-ietf-mpls-mna-usecases-12
	Abstract		Abstract
	This document presents use cases that have a common feature in that		This document presents use cases that have a common feature that may
	they may be addressed by encoding network action indicators and		be addressed by encoding network action indicators and associated
	associated ancillary data within MPLS packets. There is community		ancillary data within MPLS packets. There is community interest in
	interest in extending the MPLS data plane to carry such indicators		extending the MPLS data plane to carry such indicators and ancillary
	and ancillary data to address the use cases that are described in		data to address the use cases that are described in this document.
	this document.
	The use cases described in this document are not an exhaustive set,		The use cases described in this document are not an exhaustive set,
	but rather the ones that are actively discussed by members of the		but rather the ones that are actively discussed by members of the
	IETF MPLS, PALS, and DetNet working groups.		IETF MPLS, PALS, and DetNet working groups.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 28 February 2025.		This Internet-Draft will expire on 16 March 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Conventions used in this document . . . . . . . . . . . . 3		1.2. Conventions used in this document . . . . . . . . . . . . 3
	1.2.1. Acronyms and Abbreviations . . . . . . . . . . . . . 3		1.2.1. Acronyms and Abbreviations . . . . . . . . . . . . . 3
	2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. No Further Fast Reroute . . . . . . . . . . . . . . . . . 4		2.1. No Further Fast Reroute . . . . . . . . . . . . . . . . . 4
	2.2. Applicability of Hybrid Measurement Methods . . . . . . . 4		2.2. Applicability of Hybrid Measurement Methods . . . . . . . 5
	2.2.1. In-situ OAM . . . . . . . . . . . . . . . . . . . . . 5		2.2.1. In-situ OAM . . . . . . . . . . . . . . . . . . . . . 5
	2.2.2. Alternate Marking Method . . . . . . . . . . . . . . 5		2.2.2. Alternate Marking Method . . . . . . . . . . . . . . 6
	2.3. Network Slicing . . . . . . . . . . . . . . . . . . . . . 6		2.3. Network Slicing . . . . . . . . . . . . . . . . . . . . . 6
	2.4. NSH-based Service Function Chaining . . . . . . . . . . . 6		2.4. NSH-based Service Function Chaining . . . . . . . . . . . 6
	2.5. Network Programming . . . . . . . . . . . . . . . . . . . 7		2.5. Network Programming . . . . . . . . . . . . . . . . . . . 7
	3. Existing MPLS Use cases . . . . . . . . . . . . . . . . . . . 7		3. Co-existence with the Existing MPLS Services Using Post-Stack
			Headers . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Co-existence of the MNA Use Cases . . . . . . . . . . . . . . 8		4. Co-existence of the MNA Use Cases . . . . . . . . . . . . . . 8
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8.1. Informative References . . . . . . . . . . . . . . . . . 8		8.1. Normative References . . . . . . . . . . . . . . . . . . 9
			8.2. Informative References . . . . . . . . . . . . . . . . . 9
	Appendix A. Use Cases for Continued Discussion . . . . . . . . . 12		Appendix A. Use Cases for Continued Discussion . . . . . . . . . 12
	A.1. Generic Delivery Functions . . . . . . . . . . . . . . . 12		A.1. Generic Delivery Functions . . . . . . . . . . . . . . . 12
	A.2. Delay Budgets for Time-Bound Applications . . . . . . . . 12		A.2. Delay Budgets for Time-Bound Applications . . . . . . . . 13
	A.3. Stack-Based Methods for Latency Control . . . . . . . . . 13		A.3. Stack-Based Methods for Latency Control . . . . . . . . . 13
	Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 13		Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	This document describes use cases that introduce functions that		This document describes use cases that introduce functions that
	require special processing by forwarding hardware. The current state		require special processing by forwarding hardware. The current state
	of the art requires allocating a new special-purpose label [RFC3032]		of the art requires allocating a new special-purpose label (SPL)
	or extended special-purpose label. To conserve that limited		[RFC3032] or extended special-purpose label (eSPL). SPLs are a very
	resource, an MPLS Network Action (MNA) approach was proposed to		limited resource, while eSPL requires an extra Label Stack Entry per
	extend the MPLS architecture. MNA is expected to enable functions		Network Action, which is expensive. Therefore, an MPLS Network
	that may require carrying additional ancillary data within the MPLS		Action (MNA) [RFC9613] approach was proposed to extend the MPLS
	packets, as well as a means to indicate the ancillary data is present		architecture. MNA is expected to enable functions that may require
	and a specific action needs to be performed on the packet.		carrying additional ancillary data within the MPLS packets, as well
			as a means to indicate the ancillary data is present and a specific
			action needs to be performed on the packet.
	This document lists various use cases that could benefit extensively		This document lists various use cases that could benefit extensively
	from the MNA framework [I-D.ietf-mpls-mna-fwk]. Supporting a		from the MNA framework [I-D.ietf-mpls-mna-fwk]. Supporting a
	solution of the general MNA framework provides a common foundation		solution of the general MNA framework provides a common foundation
	for future network actions that can be exercised in the MPLS data		for future network actions that can be exercised in the MPLS data
	plane.		plane.
	1.1. Terminology		1.1. Terminology
	The following terminology is used in the document:		The following terminology is used in the document:
	RFC 9543 Network Slice		RFC 9543 Network Slice
	is interpreted as defined in [RFC9543]. Furthermore, this		is interpreted as defined in [RFC9543]. Furthermore, this
	document uses "network slice" interchangeably as a shorter version		document uses "network slice" interchangeably as a shorter version
	of the RFC 9543 Network Slice term.		of the RFC 9543 Network Slice term.
	The MPLS Ancillary Data (AD) is classified as:		The MPLS Ancillary Data (AD) is classified as:
	* residing within the MPLS label stack and referred to as In		* residing within the MPLS label stack and referred to as In-
	Stack Data (ISD), and		Stack Data (ISD), and
	* residing after the Bottom of Stack (BoS) and referred to as		* residing after the Bottom of Stack (BoS) and referred to as
	Post Stack Data (PSD).		Post-Stack Data (PSD).
	1.2. Conventions used in this document		1.2. Conventions used in this document
	1.2.1. Acronyms and Abbreviations		1.2.1. Acronyms and Abbreviations
	ISD: In-stack data		ISD: In-Stack data
	PSD: Post-stack data		PSD: Post-Stack data
	MNA: MPLS Network Action		MNA: MPLS Network Action
	NAI: Network Action Indicator		NAI: Network Action Indicator
	AD: Ancillary Data		AD: Ancillary Data
	DEX: Direct Export		DEX: Direct Export
	GDF: Generic Delivery Function
	I2E: Ingress to Edge		I2E: Ingress to Edge
	HbH: Hop by Hop		HbH: Hop by Hop
	PW: Pseudowire		PW: Pseudowire
	BoS: Bottom of Stack		BoS: Bottom of Stack
	ToS: Top of Stack		ToS: Top of Stack
	NSH: Network Service Header		NSH: Network Service Header
	FRR: Fast Reroute		FRR: Fast Reroute
	IOAM: In-situ Operations, Administration, and Maintenance		IOAM: In-situ Operations, Administration, and Maintenance
	G-ACh: Generic Associated Channel		G-ACh: Generic Associated Channel
	LSP: Label Switched Path		LSP: Label Switched Path
	LSR: Label Switch Router		LSR: Label Switch Router
	NRP: Network Resource Partition		NRP: Network Resource Partition
			SPL: Special Purpose Label
			eSPL: extended Special Purpose Label
	AMM: Alternative Marking Method		AMM: Alternative Marking Method
	2. Use Cases		2. Use Cases
	2.1. No Further Fast Reroute		2.1. No Further Fast Reroute
	MPLS Fast Reroute [RFC4090], [RFC5286] and [RFC7490] is a useful and		MPLS Fast Reroute [RFC4090], [RFC5286] and [RFC7490] is a useful and
	widely deployed tool for minimizing packet loss in the case of a link		widely deployed tool for minimizing packet loss in the case of a link
	or node failure.		or node failure.
	skipping to change at page 6, line 40 ¶		skipping to change at page 6, line 50 ¶
	essential for these actions. For example, MNA can carry the NRP		essential for these actions. For example, MNA can carry the NRP
	Selector [I-D.ietf-teas-ns-ip-mpls] in MPLS packets.		Selector [I-D.ietf-teas-ns-ip-mpls] in MPLS packets.
	2.4. NSH-based Service Function Chaining		2.4. NSH-based Service Function Chaining
	[RFC8595] describes how Service Function Chaining can be realized in		[RFC8595] describes how Service Function Chaining can be realized in
	an MPLS network by emulating the Network Service Header (NSH)		an MPLS network by emulating the Network Service Header (NSH)
	[RFC8300] using only MPLS label stack elements.		[RFC8300] using only MPLS label stack elements.
	The approach in [RFC8595] introduces some limitations discussed in		The approach in [RFC8595] introduces some limitations discussed in
	[I-D.lm-mpls-sfc-path-verification]. This approach, however, can		[I-D.lm-mpls-sfc-path-verification]. However, that approach can
	benefit from the framework introduced with MNA in		benefit from the framework introduced with MNA in
	[I-D.ietf-mpls-mna-fwk].		[I-D.ietf-mpls-mna-fwk].
	MNA can be used to extend NSH emulation using MPLS labels [RFC8595]		MNA can be used to extend NSH emulation using MPLS labels [RFC8595]
	to support the functionality of NSH Context Headers, whether fixed or		to support the functionality of NSH Context Headers, whether fixed or
	variable-length. For example, MNA could support Flow ID [RFC9263]		variable-length. For example, MNA could support Flow ID [RFC9263]
	that may be used for load-balancing among Service Function Forwarders		that may be used for load-balancing among Service Function Forwarders
	and/or the Service Functions within the same Service Function Path.		and/or the Service Functions within the same Service Function Path.
	2.5. Network Programming		2.5. Network Programming
	skipping to change at page 7, line 22 ¶		skipping to change at page 7, line 28 ¶
	segment list to any complex user-defined behavior.		segment list to any complex user-defined behavior.
	Network Programming combines SR functions to achieve a networking		Network Programming combines SR functions to achieve a networking
	objective beyond mere packet routing.		objective beyond mere packet routing.
	Encoding a pointer to a function and its arguments within an MPLS		Encoding a pointer to a function and its arguments within an MPLS
	packet transport header may be desirable. MNA can be used to encode		packet transport header may be desirable. MNA can be used to encode
	the FUNC::ARGs to support the functional equivalent of FUNC::ARG in		the FUNC::ARGs to support the functional equivalent of FUNC::ARG in
	SRv6 as described in [RFC8986].		SRv6 as described in [RFC8986].
	3. Existing MPLS Use cases		3. Co-existence with the Existing MPLS Services Using Post-Stack
			Headers
	Several services can be transported over MPLS networks today. These		Several services can be transported over MPLS networks today. These
	include providing Layer-3 (L3) connectivity (e.g., for unicast and		include providing Layer-3 (L3) connectivity (e.g., for unicast and
	multicast L3 services), and Layer-2 (L2) connectivity (e.g., for		multicast L3 services), and Layer-2 (L2) connectivity (e.g., for
	unicast Pseudowires (PWs), multicast E-Tree, and broadcast E-LAN L2		unicast Pseudowires (PWs), multicast E-Tree, and broadcast E-LAN L2
	services). In those cases, the user service traffic is encapsulated		services). In those cases, the user service traffic is encapsulated
	as the payload in MPLS packets.		as the payload in MPLS packets.
	For L2 service traffic, it is possible to use Control Word (CW)		For L2 service traffic, it is possible to use Control Word (CW)
	[RFC4385] and [RFC5085] immediately after the MPLS header to		[RFC4385] and [RFC5085] immediately after the MPLS header to
	skipping to change at page 8, line 15 ¶		skipping to change at page 8, line 21 ¶
	For pseudowires, the Generic Associated Channel [RFC7212] uses the		For pseudowires, the Generic Associated Channel [RFC7212] uses the
	first four bits of the PW control word to provide the initial		first four bits of the PW control word to provide the initial
	discrimination between data packets and packets belonging to the		discrimination between data packets and packets belonging to the
	associated channel, as described in [RFC4385].		associated channel, as described in [RFC4385].
	MPLS can be used as the data plane for DetNet [RFC8655]. The DetNet		MPLS can be used as the data plane for DetNet [RFC8655]. The DetNet
	sub-layers, forwarding, and service are realized using the MPLS label		sub-layers, forwarding, and service are realized using the MPLS label
	stack, the DetNet Control Word [RFC8964], and the DetNet Associated		stack, the DetNet Control Word [RFC8964], and the DetNet Associated
	Channel Header [RFC9546].		Channel Header [RFC9546].
	It is expected that new use cases described in this document will		MNA-based solutions for the use cases described in this document and
	allow for the co-existence and backward compatibility with all such		proposed in the future are expected to allow for coexistence and
	existing MPLS services.		backward compatibility with all existing MPLS services.
	4. Co-existence of the MNA Use Cases		4. Co-existence of the MNA Use Cases
	Two or more of the discussed cases may co-exist in the same packet.		Two or more of the discussed cases may co-exist in the same packet.
	That may require the presence of multiple ancillary data (whether In-		That may require the presence of multiple ancillary data (whether In-
	stack or Post-stack ancillary data) to be present in the same MPLS		stack or Post-stack ancillary data) to be present in the same MPLS
	packet.		packet.
	For example, IOAM may provide essential functions along with network		For example, IOAM may provide essential functions along with network
	slicing to help ensure that critical network slice SLOs are being met		slicing to help ensure that critical network slice SLOs are being met
	skipping to change at page 8, line 49 ¶		skipping to change at page 9, line 7 ¶
	7. Acknowledgement		7. Acknowledgement
	The authors gratefully acknowledge the input of the members of the		The authors gratefully acknowledge the input of the members of the
	MPLS Open Design Team. Also, the authors sincerely thank Loa		MPLS Open Design Team. Also, the authors sincerely thank Loa
	Andersson, Xiao Min, and Jie Dong for their thoughtful suggestions		Andersson, Xiao Min, and Jie Dong for their thoughtful suggestions
	and help in improving the document.		and help in improving the document.
	8. References		8. References
	8.1. Informative References		8.1. Normative References
	[I-D.ietf-mpls-mna-fwk]		[I-D.ietf-mpls-mna-fwk]
	Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS		Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
	Network Actions (MNA) Framework", Work in Progress,		Network Actions (MNA) Framework", Work in Progress,
	Internet-Draft, draft-ietf-mpls-mna-fwk-10, 6 August 2024,		Internet-Draft, draft-ietf-mpls-mna-fwk-10, 6 August 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-		<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
	mna-fwk-10>.		mna-fwk-10>.
			8.2. Informative References
	[I-D.ietf-teas-ns-ip-mpls]		[I-D.ietf-teas-ns-ip-mpls]
	Saad, T., Beeram, V. P., Dong, J., Wen, B., Ceccarelli,		Saad, T., Beeram, V. P., Dong, J., Wen, B., Ceccarelli,
	D., Halpern, J. M., Peng, S., Chen, R., Liu, X.,		D., Halpern, J. M., Peng, S., Chen, R., Liu, X.,
	Contreras, L. M., Rokui, R., and L. Jalil, "Realizing		Contreras, L. M., Rokui, R., and L. Jalil, "Realizing
	Network Slices in IP/MPLS Networks", Work in Progress,		Network Slices in IP/MPLS Networks", Work in Progress,
	Internet-Draft, draft-ietf-teas-ns-ip-mpls-04, 28 May		Internet-Draft, draft-ietf-teas-ns-ip-mpls-04, 28 May
	2024, <https://datatracker.ietf.org/doc/html/draft-ietf-		2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
	teas-ns-ip-mpls-04>.		teas-ns-ip-mpls-04>.
	[I-D.lm-mpls-sfc-path-verification]		[I-D.lm-mpls-sfc-path-verification]
	skipping to change at page 12, line 22 ¶		skipping to change at page 12, line 27 ¶
	Framework for Network Slices in Networks Built from IETF		Framework for Network Slices in Networks Built from IETF
	Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,		Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,
	<https://www.rfc-editor.org/info/rfc9543>.		<https://www.rfc-editor.org/info/rfc9543>.
	[RFC9546] Mirsky, G., Chen, M., and B. Varga, "Operations,		[RFC9546] Mirsky, G., Chen, M., and B. Varga, "Operations,
	Administration, and Maintenance (OAM) for Deterministic		Administration, and Maintenance (OAM) for Deterministic
	Networking (DetNet) with the MPLS Data Plane", RFC 9546,		Networking (DetNet) with the MPLS Data Plane", RFC 9546,
	DOI 10.17487/RFC9546, February 2024,		DOI 10.17487/RFC9546, February 2024,
	<https://www.rfc-editor.org/info/rfc9546>.		<https://www.rfc-editor.org/info/rfc9546>.
			[RFC9613] Bocci, M., Ed., Bryant, S., and J. Drake, "Requirements
			for Solutions that Support MPLS Network Actions (MNAs)",
			RFC 9613, DOI 10.17487/RFC9613, August 2024,
			<https://www.rfc-editor.org/info/rfc9613>.
	Appendix A. Use Cases for Continued Discussion		Appendix A. Use Cases for Continued Discussion
	Several use cases for which MNA can provide a viable solution have		Several use cases for which MNA can provide a viable solution have
	been discussed. The discussion of these aspirational cases is		been discussed. The discussion of these aspirational cases is
	ongoing.		ongoing.
	A.1. Generic Delivery Functions		A.1. Generic Delivery Functions
	The Generic Delivery Functions (GDFs), defined in		The Generic Delivery Functions (GDFs), defined in
	[I-D.zzhang-intarea-generic-delivery-functions], provide a new		[I-D.zzhang-intarea-generic-delivery-functions], provide a new
End of changes. 26 change blocks.
	38 lines changed or deleted		51 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/