< draft-ietf-mpls-inband-pm-encapsulation-00.txt		draft-ietf-mpls-inband-pm-encapsulation-01.txt >
	MPLS Working Group W. Cheng		MPLS Working Group W. Cheng
	Internet-Draft China Mobile		Internet-Draft China Mobile
	Intended status: Standards Track X. Min		Intended status: Standards Track X. Min
	Expires: July 29, 2021 ZTE		Expires: October 13, 2021 ZTE Corp.
	T. Zhou		T. Zhou
	Huawei		Huawei
	X. Dong		X. Dong
	FiberHome		FiberHome
	Y. Peleg		Y. Peleg
	Broadcom		Broadcom
	January 25, 2021		April 11, 2021
	Encapsulation For MPLS Performance Measurement with Alternate Marking		Encapsulation For MPLS Performance Measurement with Alternate Marking
	Method		Method
	draft-ietf-mpls-inband-pm-encapsulation-00		draft-ietf-mpls-inband-pm-encapsulation-01
	Abstract		Abstract
	This document defines the encapsulation for MPLS performance		This document defines the encapsulation for MPLS performance
	measurement with alternate marking method, which performs flow-based		measurement with alternate marking method, which performs flow-based
	packet loss, delay, and jitter measurements on live traffic.		packet loss, delay, and jitter measurements on live traffic.
	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
	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 July 29, 2021.		This Internet-Draft will expire on October 13, 2021.
	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 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Conventions Used in This Document . . . . . . . . . . . . 3		1.1. Conventions Used in This Document . . . . . . . . . . . . 3
	1.1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 3		1.1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 3
	1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4		1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4
	2. Flow-based PM Encapsulation in MPLS . . . . . . . . . . . . . 4		2. Flow-based PM Encapsulation in MPLS . . . . . . . . . . . . . 4
	2.1. Examples for Applying Flow-ID Label in a label stack . . 5		2.1. Examples for Applying Flow-ID Label in a label stack . . 5
	3. Procedures of Encapsulation, Look-up and Decapsulation . . . 8		3. Procedures of Encapsulation, Look-up and Decapsulation . . . 8
	4. Procedures of Flow-ID allocation . . . . . . . . . . . . . . 9		4. Procedures of Flow-ID allocation . . . . . . . . . . . . . . 9
	5. FLC and FRLD Considerations . . . . . . . . . . . . . . . . . 10		5. FLC and FRLD Considerations . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. Equal-Cost Multipath Considerations . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . 11		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9.2. Informative References . . . . . . . . . . . . . . . . . 12		10.1. Normative References . . . . . . . . . . . . . . . . . . 12
			10.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	[RFC8321] describes a passive performance measurement method, which		[RFC8321] describes a passive performance measurement method, which
	can be used to measure packet loss, delay, and jitter on live		can be used to measure packet loss, delay, and jitter on live
	traffic. Since this method is based on marking consecutive batches		traffic. Since this method is based on marking consecutive batches
	of packets, the method is often referred to as Alternate Marking		of packets, the method is often referred to as Alternate Marking
	Method.		Method. [RFC8372] discusses the desired capabilities for MPLS flow
	[RFC8372] discusses the desired capabilities for MPLS flow
	identification, in order to perform a better in-band performance		identification, in order to perform a better in-band performance
	monitoring of user data packets. Synonymous Flow Label (SFL), which		monitoring of user data packets.
	is introduced in [I-D.ietf-mpls-sfl-framework], is identified as a
	method of accomplishing MPLS flow identification. This document
	employs a method, other than SFL, to accomplish MPLS flow
	identification. The method described in this document is simple and
	flexible, furthermore, it complies with the current MPLS forwarding
	paradigm.
	On one hand, the method described in this document is complementary
	to the SFL method [I-D.ietf-mpls-sfl-framework]
	[I-D.bryant-mpls-sfl-control], the former targets at hop-by-hop
	performance measurement, and the latter targets at end-to-end
	performance measurement, furthermore, the former supports the
	application scenario where Flow-ID is applied to MPLS LSP and MPLS
	VPN synchronously, and the latter doesn't support this kind of
	application scenario. On the other hand, the method described in
	this document is complementary to the In-situ OAM method
	[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-direct-export], the
	former doesn't introduce any new header but the latter introduces a
	new In-situ OAM header, furthermore, the former allows the network
	nodes to report the refined data (e.g. calculated performance
	metrics) associated with a specified flow, nevertheless the latter
	requests the network nodes to report the data (e.g. ingress interface
	and egress interface) associated with a specified packet.
	This document defines the encapsulation for MPLS performance		This document defines the encapsulation for MPLS performance
	measurement with alternate marking method, which performs flow-based		measurement with alternate marking method, which performs flow-based
	packet loss, delay, and jitter measurements on live traffic.		packet loss, delay, and jitter measurements on live traffic. The
			encapsulation defined in this document supports monitoring at
			intermediate nodes, as well as flow identification at both transport
			and service label.
			This document employs a method, other than Synonymous Flow Label
			(SFL), to accomplish MPLS flow identification. The method described
			in this document is complementary to the SFL method [RFC8957]
			[I-D.ietf-mpls-sfl-control], the former mainly aims at hop-by-hop
			performance measurement, and the latter mainly aims at end-to-end
			performance measurement. Different sets of flows may use different
			methods.
			The method described in this document is also complementary to the
			In-situ OAM method [I-D.ietf-ippm-ioam-data]
			[I-D.ietf-ippm-ioam-direct-export], the former doesn't introduce any
			new header whereas the latter introduces a new In-situ OAM header,
			furthermore, the former requests the network nodes to report the data
			used for performance measurement, and the latter requests the network
			nodes to report the data used for operational and telemetry
			information collection. One set of flows may use both of the two
			methods concurrently.
	1.1. Conventions Used in This Document		1.1. Conventions Used in This Document
	1.1.1. Abbreviations		1.1.1. Abbreviations
			ACL: Access Control List
			cSPL: Composite Special Purpose Label
			ECMP: Equal-Cost Multipath
	ELC: Entropy Label Capability		ELC: Entropy Label Capability
	ERLD: Entropy Readable Label Depth		ERLD: Entropy Readable Label Depth
			eSPL: Extended Special Purpose Label
	FLC: Flow-ID Label Capability		FLC: Flow-ID Label Capability
			FLI: Flow-ID Label Indicator
	FRLD: Flow-ID Readable Label Depth		FRLD: Flow-ID Readable Label Depth
	LSP: Label Switched Path		LSP: Label Switched Path
	MPLS: Multi-Protocol Label Switching		MPLS: Multi-Protocol Label Switching
	NMS: Network Management System		NMS: Network Management System
			PHP: Penultimate Hop Popping
	PM: Performance Measurement		PM: Performance Measurement
	PW: PseudoWire		PW: PseudoWire
	SFL: Synonymous Flow Label		SFL: Synonymous Flow Label
	SID: Segment ID		SID: Segment ID
			SPL: Special Purpose Label
	SR: Segment Routing		SR: Segment Routing
	TC: Traffic Class		TC: Traffic Class
	TTL: Time to Live		TTL: Time to Live
	VC: Virtual Channel		VC: Virtual Channel
	VPN: Virtual Private Network		VPN: Virtual Private Network
	1.1.2. Requirements Language		1.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
	skipping to change at page 4, line 33 ¶		skipping to change at page 4, line 45 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Extension Label (15) | TC |S| TTL |		| Extension Label (15) | TC |S| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flow-ID Label Indicator (TBA1) | TC |S| TTL |		| Flow-ID Label Indicator (TBA1) | TC |S| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flow-ID Label | TC |S| TTL |		| Flow-ID Label | TC |S| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Flow-based PM Encapsulation in MPLS		Figure 1: Flow-based PM Encapsulation in MPLS
	Flow-ID Label Indicator is an Extended Special Purpose Label (eSPL),		Flow-ID Label Indicator (FLI) is an Extended Special Purpose Label
	which is combined with the Extension Label (XL, value 15) to form a		(eSPL), which is combined with the Extension Label (XL, value 15) to
	Composite Special Purpose Label (cSPL), as defined in		form a Composite Special Purpose Label (cSPL), as defined in
	[I-D.ietf-mpls-spl-terminology]. Flow-ID Label Indicator is defined		[RFC9017]. Flow-ID Label Indicator is defined in this document as
	in this document as value TBA1.		value TBA1.
	Analogous to Entropy Label Indicator [RFC6790], the TC and TTL for		Analogous to Entropy Label Indicator [RFC6790], the TC and TTL for
	the Extension Label and the Flow-ID Label Indicator SHOULD follow the		the Extension Label and the Flow-ID Label Indicator SHOULD follow the
	same field values of that label immediately preceding the Extension		same field values of that label immediately preceding the Extension
	Label, otherwise, the TC and TTL for the Extension Label and the		Label, otherwise, the TC and TTL for the Extension Label and the
	Flow-ID Label Indicator MAY be different values if it is known that		Flow-ID Label Indicator MAY be different values if it is known that
	the Extension Label will not be exposed as the top label at any point		the Extension Label will not be exposed as the top label at any point
	along the LSP. The S bit for the Extension Label and the Flow-ID		along the LSP. The S bit for the Extension Label and the Flow-ID
	Label Indicator MUST be zero.		Label Indicator MUST be zero.
	Flow-ID Label is used as MPLS flow identification [RFC8372], its		Flow-ID label is used as MPLS flow identification [RFC8372], its
	value should be unique within the administrative domain. Flow-ID		value should be unique within the administrative domain. Flow-ID
	values can be allocated by an external NMS or a controller, based on		values can be allocated by an external NMS or a controller, based on
	measurement object instance such as LSP or PW. There is a one-to-one		measurement object instance such as LSP or PW. There is a one-to-one
	mapping between Flow-ID and flow. The specific method on how to		mapping between Flow-ID and flow. The specific method on how to
	allocate the Flow-ID values is described in Section 4.		allocate the Flow-ID values is described in Section 4.
	Analogous to Entropy Label [RFC6790], the Flow-ID Label can be placed		Analogous to Entropy Label [RFC6790], the Flow-ID label can be placed
	at either the bottom or the middle of the MPLS label stack, and the		at either the bottom or the middle of the MPLS label stack, and the
	Flow-ID Label MAY appear multiple times in a label stack.		Flow-ID label MAY appear multiple times in a label stack.
	Section 2.1 of this document provides several examples to illustrate		Section 2.1 of this document provides several examples to illustrate
	how to apply Flow-ID Label in a label stack. Again analogous to		how to apply Flow-ID label in a label stack. Again analogous to
	Entropy Label, the TTL for the Flow-ID Label MUST be zero to ensure		Entropy Label, the TTL for the Flow-ID label MUST be zero to ensure
	that it is not used inadvertently for forwarding, the TC for the		that it is not used inadvertently for forwarding, the TC for the
	Flow-ID Label may be any value, the S bit for the Flow-ID Label		Flow-ID label may be any value, the S bit for the Flow-ID Label
	depends on whether or not there are more labels in the label stack.		depends on whether or not there are more labels in the label stack.
	Besides flow identification, a color-marking field is also necessary		Besides flow identification, a color-marking field is also necessary
	for alternate marking method. To achieve the purpose of coloring the		for alternate marking method. To achieve the purpose of coloring the
	MPLS traffic, the current practice when writing this document is to		MPLS traffic, the current practice when writing this document is to
	reuse the Flow-ID Label's TC, i.e., using TC's highest order two bits		reuse the Flow-ID label's TC, i.e., using TC's highest order two bits
	(called double-marking methodology [RFC8321]) as color-marking bits.		(called double-marking methodology [RFC8321]) as color-marking bits.
	Alternatively, allocating multiple Flow-ID Labels to the same flow		Alternatively, allocating multiple Flow-ID labels to the same flow
	may be used for the purpose of alternate marking.		may be used for the purpose of alternate marking.
	2.1. Examples for Applying Flow-ID Label in a label stack		2.1. Examples for Applying Flow-ID Label in a label stack
	Three examples on different layout of Flow-ID Label (4 octets) are		Three examples on different layout of Flow-ID label (4 octets) are
	illustrated as follows:		illustrated as follows:
	(1) Layout of Flow-ID Label when applied to MPLS LSP.		(1) Layout of Flow-ID label when applied to MPLS transport.
	+----------------------+		+----------------------+
	| LSP |		| LSP |
	| Label |		| Label |
	+----------------------+		+----------------------+
	| Extension | <--+		| Extension | <--+
	| Label | |		| Label | |
	+----------------------+ |--- cSPL		+----------------------+ |--- cSPL
	| Flow-ID Label | |		| Flow-ID Label | |
	| Indicator | <--+		| Indicator | <--+
	+----------------------+		+----------------------+
	| Flow-ID |		| Flow-ID |
	| Label |		| Label |
	+----------------------+		+----------------------+
	| VPN |		| Application |
	| Label |		| Label |
	+----------------------+ <= Bottom of stack		+----------------------+ <= Bottom of stack
	| |		| |
	| Payload |		| Payload |
	| |		| |
	+----------------------+		+----------------------+
	Figure 2: Applying Flow-ID to MPLS LSP		Figure 2: Applying Flow-ID to MPLS transport
	(2) Layout of Flow-ID Label when applied to MPLS VPN traffic.		Note that here if penultimate hop popping (PHP) is in use, the PHP
			LSR that recognizes the cSPL MAY choose not to pop the cSPL and the
			following Flow-ID label, otherwise the egress LSR would be excluded
			from the performance measurement.
			Also note that in other examples of applying Flow-ID to MPLS
			transport, one LSP label can be substituted by multiple SID labels in
			the case of using SR Policy, and the combination of cSPL and Flow-ID
			label can be placed between SID labels, as specified in Section 5.
			(2) Layout of Flow-ID label when applied to MPLS service.
	+----------------------+		+----------------------+
	| LSP |		| LSP |
	| Label |		| Label |
	+----------------------+		+----------------------+
	| VPN |		| Application |
	| Label |		| Label |
	+----------------------+		+----------------------+
	| Extension | <--+		| Extension | <--+
	| Label | |		| Label | |
	+----------------------+ |--- cSPL		+----------------------+ |--- cSPL
	| Flow-ID Label | |		| Flow-ID Label | |
	| Indicator | <--+		| Indicator | <--+
	+----------------------+		+----------------------+
	| Flow-ID |		| Flow-ID |
	| Label |		| Label |
	+----------------------+ <= Bottom of stack		+----------------------+ <= Bottom of stack
	| |		| |
	| Payload |		| Payload |
	| |		| |
	+----------------------+		+----------------------+
	Figure 3: Applying Flow-ID to MPLS VPN		Figure 3: Applying Flow-ID to MPLS service
	(3) Layout of Flow-ID Label when applied to both MPLS LSP and MPLS		Note that here application label can be MPLS PW label, MPLS Ethernet
	VPN traffic.		VPN label or MPLS IP VPN label, and it's also called VC label as
			defined in [RFC4026].
			(3) Layout of Flow-ID label when applied to both MPLS transport and
			MPLS service.
	+----------------------+		+----------------------+
	| LSP |		| LSP |
	| Label |		| Label |
	+----------------------+		+----------------------+
	| Extension | <--+		| Extension | <--+
	| Label | |		| Label | |
	+----------------------+ |--- cSPL		+----------------------+ |--- cSPL
	| Flow-ID Label | |		| Flow-ID Label | |
	| Indicator | <--+		| Indicator | <--+
	+----------------------+		+----------------------+
	| Flow-ID |		| Flow-ID |
	| Label |		| Label |
	+----------------------+		+----------------------+
	| VPN |		| Application |
	| Label |		| Label |
	+----------------------+		+----------------------+
	| Extension | <--+		| Extension | <--+
	| Label | |		| Label | |
	+----------------------+ |--- cSPL		+----------------------+ |--- cSPL
	| Flow-ID Label | |		| Flow-ID Label | |
	| Indicator | <--+		| Indicator | <--+
	+----------------------+		+----------------------+
	| Flow-ID |		| Flow-ID |
	| Label |		| Label |
	+----------------------+ <= Bottom of stack		+----------------------+ <= Bottom of stack
	| |		| |
	| Payload |		| Payload |
	| |		| |
	+----------------------+		+----------------------+
	Figure 4: Applying Flow-ID to both MPLS LSP and MPLS VPN		Figure 4: Applying Flow-ID to both MPLS transport and MPLS service
	Note that here VPN label can be MPLS PW label, MPLS Ethernet VPN
	label or MPLS IP VPN label, and it's also called VC label as defined
	in [RFC4026].
	Also note that for this example the two Flow-ID values appearing in a		Note that for this example the two Flow-ID values appearing in a
	label stack MUST be different, that is to say, Flow-ID Label applied		label stack MUST be different, that is to say, Flow-ID label applied
	to MPLS LSP and Flow-ID Label applied to MPLS VPN share the same		to MPLS transport and Flow-ID label applied to MPLS service share the
	value space.		same value space. Also note that the two Flow-ID label values are
			independent from each other, e.g., two packets can belong to the same
			VPN flow but to two different LSP flows, or two packets can belong to
			two different VPN flows but to the same LSP flow.
	3. Procedures of Encapsulation, Look-up and Decapsulation		3. Procedures of Encapsulation, Look-up and Decapsulation
	The procedures for Flow-ID label encapsulation, look-up and		The procedures for Flow-ID label encapsulation, look-up and
	decapsulation are summarized as follows:		decapsulation are summarized as follows:
	o The ingress node inserts the Extension Label, the Flow-ID Label		o The ingress node inserts the Extension Label, the Flow-ID Label
	Indicator, alongside with the Flow-ID label, into the MPLS label		Indicator, alongside with the Flow-ID label, into the MPLS label
	stack. At the same time, the ingress node sets the color-marking		stack. At the same time, the ingress node sets the color-marking
	field, as needed by alternate-marking technique, and sets the		field, as needed by alternate-marking technique, and sets the
	Flow-ID value, as defined in this document.		Flow-ID value, as defined in this document.
	o The transit nodes look up the Flow-ID label with the help of the		o The transit nodes lookup the Flow-ID label with the help of the
	Extension Label and the Flow-ID Label Indicator, and transmit the		Extension Label and the Flow-ID Label Indicator, and transmit the
	collected information to an external NMS or a controller, which		collected information to an external NMS or a controller, which
	includes the values of the block counters and the timestamps of		includes the values of the block counters and the timestamps of
	the marked packets, along with the value of the Flow-ID, referring		the marked packets, along with the value of the Flow-ID, referring
	to the procedures of alternate marking method.		to the procedures of alternate marking method. Note that in order
			to lookup the Flow-ID label, the transit nodes need to perform
			some deep packet inspection beyond the label at the top of the
			label stack used to take forwarding decisions.
	o The egress node pops the Extension Label and the Flow-ID Label		o The egress node pops the Extension Label and the Flow-ID Label
	Indicator, alongside with the Flow-ID label, from the MPLS label		Indicator, alongside with the Flow-ID label, from the MPLS label
	stack. This document doesn't introduce any new procedure		stack. This document doesn't introduce any new procedure
	regarding to the process of the decapsulated packet.		regarding to the process of the decapsulated packet.
	4. Procedures of Flow-ID allocation		4. Procedures of Flow-ID allocation
	There are two ways of allocating Flow-ID, one way is to allocate		There are two ways of allocating Flow-ID, one way is to allocate
	Flow-ID by manual trigger from the network operator, and the other		Flow-ID by manual trigger from the network operator, and the other
	way is to allocate Flow-ID by automatic trigger from the ingress		way is to allocate Flow-ID by automatic trigger from the ingress
	node, details are as follows:		node, details are as follows:
	o In the case of manual trigger, the network operator would manually		o In the case of manual trigger, the network operator would manually
	input the characteristics (e.g. IP five tuples and IP DSCP) of		input the characteristics (e.g. IP five tuples and IP DSCP) of
	the measured IP traffic flow, then the NMS or the controller would		the measured flow, then the NMS or the controller would generate
	generate one or two Flow-IDs based on the input from the network		one or two Flow-IDs based on the input from the network operator,
	operator, and provision the ingress node with the characteristics		and provision the ingress node with the characteristics of the
	of the measured IP traffic flow and the corresponding allocated		measured flow and the corresponding allocated Flow-ID(s).
	Flow-ID(s).
	o In the case of automatic trigger, the ingress node would identify		o In the case of automatic trigger, the ingress node would identify
	the IP traffic flow entering the measured path, export the		the flow entering the measured path, export the characteristics of
	characteristics of the identified IP traffic flow to the NMS or		the identified flow to the NMS or the controller by IPFIX
	the controller by IPFIX [RFC7011], then the NMS or the controller		[RFC7011], then the NMS or the controller would generate one or
	would generate one or two Flow-IDs based on the export from the		two Flow-IDs based on the export from the ingress node, and
	ingress node, and provision the ingress node with the		provision the ingress node with the characteristics of the
	characteristics of the identified IP traffic flow and the		identified flow and the corresponding allocated Flow-ID(s).
	corresponding allocated Flow-ID(s).
	The policy pre-configured at the NMS or the controller decides		The policy pre-configured at the NMS or the controller decides
	whether one Flow-ID or two Flow-IDs would be generated. If the		whether one Flow-ID or two Flow-IDs would be generated. If the
	performance measurement on VPN traffic is enabled, then one Flow-ID		performance measurement on MPLS service is enabled, then one Flow-ID
	applied to MPLS VPN would be generated; if the performance		applied to MPLS service would be generated; if the performance
	measurement on LSP tunnel is enabled, then one Flow-ID applied to		measurement on MPLS transport is enabled, then one Flow-ID applied to
	MPLS LSP would be generated; if both of them are enabled, then two		MPLS transport would be generated; if both of them are enabled, then
	Flow-IDs respectively applied to MPLS VPN and MPLS LSP would be		two Flow-IDs respectively applied to MPLS service and MPLS transport
	generated.		would be generated, in this case the transit nodes need to lookup
			both of the two Flow-IDs by default, and that can be changed to e.g.
			lookup only the Flow-ID applied to MPLS transport by configuration.
	Whether using manual trigger or using automatic trigger, the NMS or		Whether using manual trigger or using automatic trigger, the NMS or
	the controller MUST guarantee every generated Flow-ID is unique		the controller MUST guarantee every generated Flow-ID is unique
	within the administrative domain.		within the administrative domain.
	5. FLC and FRLD Considerations		5. FLC and FRLD Considerations
	Analogous to the Entropy Label Capability (ELC) defined in Section 5		Analogous to the Entropy Label Capability (ELC) defined in Section 5
	of [RFC6790], and the Entropy Readable Label Depth (ERLD) defined in		of [RFC6790], and the Entropy Readable Label Depth (ERLD) defined in
	Section 4 of [RFC8662], the Flow-ID Label Capability (FLC) and the		Section 4 of [RFC8662], the Flow-ID Label Capability (FLC) and the
	Flow-ID Readable Label Depth (FRLD) are defined in this document.		Flow-ID Readable Label Depth (FRLD) are defined in this document.
	Both FLC and FRLD have the similar semantics with ELC and ERLD to a		Both FLC and FRLD have the similar semantics with ELC and ERLD to a
	router, except that the Flow-ID is used in its flow identification		router, except that the Flow-ID is used in its flow identification
	function while the Entropy is used in its load-balancing function.		function while the Entropy is used in its load-balancing function.
	The ingress node MUST insert each Flow-ID Label at an appropriate		The ingress node MUST insert each Flow-ID label at an appropriate
	depth, which ensures the node that needs to process the Flow-ID Label		depth, which ensures the node that needs to process the Flow-ID label
	has the FLC. How the ingress node knows the Flow-ID Label processing		has the FLC. The ingress node SHOULD insert each Flow-ID label
	node has the FLC is outside the scope of this document.		within an appropriate FRLD, which is the minimum FRLD of all on-path
			nodes that needs to read and use the Flow-ID label in question. How
	The ingress node SHOULD insert each Flow-ID Label within an		the ingress node knows the Flow-ID label processing node has the FLC
	appropriate FRLD, which is the minimum FRLD of all on-path nodes that		and the appropriate FRLD for each Flow-ID label are outside the scope
	needs to read and use the Flow-ID Label in question. How the ingress		of this document, whereas [I-D.xzc-lsr-mpls-flc-flrd] provides a
	node knows the appropriate FRLD for each Flow-ID Label is outside the		method to achieve that.
	scope of this document.
	When SR paths are used as transport, the label stack grows as the		When SR paths are used as transport, the label stack grows as the
	number of on-path segments increases, if the number of on-path		number of on-path segments increases, if the number of on-path
	segments is high, that may become a challenge for the Flow-ID Label		segments is high, that may become a challenge for the Flow-ID label
	to be placed within an appropriate FRLD. In order to overcome this		to be placed within an appropriate FRLD. In order to overcome this
	potential challenge, an implementation MAY provide flexibility to the		potential challenge, an implementation MAY provide flexibility to the
	ingress node to place Flow-ID Label between SID labels, i.e.,		ingress node to place Flow-ID label between SID labels, i.e.,
	multiple identical Flow-ID Labels at different depths MAY be		multiple identical Flow-ID labels at different depths MAY be
	interleaved with SID labels, when that happens a sophisticated		interleaved with SID labels, when that happens a sophisticated
	network planning may be needed and it's beyond the scope of this		network planning may be needed and it's beyond the scope of this
	document.		document.
	6. Security Considerations		6. Equal-Cost Multipath Considerations
			Analogous to what's described in Section 5 of [RFC8957], under
			conditions of Equal-Cost Multipath (ECMP), the introduction of a
			Flow-ID label may cause the same problem as the introduction of an
			SFL, and the two solutions proposed for the problem caused by the
			introduction of SFL would also apply here.
			7. Security Considerations
	This document introduces the performance measurement domain that is		This document introduces the performance measurement domain that is
	the scope of a Flow-ID Label. The Flow-ID Label Indicator and Flow-		the scope of a Flow-ID label. The Flow-ID Label Indicator and Flow-
	ID Label MUST NOT be signaled and distributed outside one performance		ID label MUST NOT be signaled and distributed outside one performance
	measurement domain. Improper configuration so that the Flow-ID Label		measurement domain. Improper configuration so that the Flow-ID label
	being passed from one domain to another would likely result in		being passed from one domain to another would likely result in
	potential Flow-ID conflicts.		potential Flow-ID conflicts.
	To prevent packets carrying Flow-ID Label from leaking from one		To prevent packets carrying Flow-ID label from leaking from one
	domain to another, the domain boundary nodes SHOULD deploy some		domain to another, the domain boundary nodes SHOULD deploy some
	policies (e.g., ACL) to filter out the packets. Specifically, in the		policies (e.g., ACL) to filter out the packets. Specifically, in the
	sending end, the domain boundary node SHOULD filter out the packets		sending end, the domain boundary node SHOULD filter out the packets
	that carry the Flow-ID Label Indicator and are sent to other domain;		that carry the Flow-ID Label Indicator and are sent to other domain;
	in the receiving end, the domain boundary node SHOULD drop the		in the receiving end, the domain boundary node SHOULD drop the
	packets that carry the Flow-ID Label Indicator and are from other		packets that carry the Flow-ID Label Indicator and are from other
	domains.		domains.
	7. IANA Considerations		8. IANA Considerations
	In the Special-Purpose MPLS Label Values registry defined in		In the Special-Purpose MPLS Label Values registry defined in [SPL], a
	[SP-MPLS-Label], a new Extended Special-Purpose MPLS Label Value for		new Extended Special-Purpose MPLS Label Value for Flow-ID Label
	Flow-ID Label Indicator is requested from IANA as follows:		Indicator is requested from IANA as follows:
	+-----------------------+----------------+--------------+-----------+		+-----------------------+----------------+--------------+-----------+
	| Extended Special- | Description | Semantics | Reference |		| Extended Special- | Description | Semantics | Reference |
	| Purpose MPLS Label | | Definition | |		| Purpose MPLS Label | | Definition | |
	| Value | | | |		| Value | | | |
	+-----------------------+----------------+--------------+-----------+		+-----------------------+----------------+--------------+-----------+
	| TBA1 | Flow-ID Label | Section 2 | This |		| TBA1 | Flow-ID Label | Section 2 | This |
	| | Indicator | | Document |		| | Indicator | | Document |
	+-----------------------+----------------+--------------+-----------+		+-----------------------+----------------+--------------+-----------+
	Table 1: New Extended Special-Purpose MPLS Label Value for Flow-ID		Table 1: New Extended Special-Purpose MPLS Label Value for Flow-ID
	Label Indicator		Label Indicator
	8. Acknowledgements		9. Acknowledgements
	The authors would like to acknowledge Loa Andersson, Tarek Saad,		The authors would like to acknowledge Loa Andersson, Tarek Saad,
	Stewart Bryant, Rakesh Gandhi, Greg Mirsky, Aihua Liu, Shuangping		Stewart Bryant, Rakesh Gandhi, Greg Mirsky, Aihua Liu, Shuangping
	Zhan and Ming Ke for their careful review and very helpful comments.		Zhan and Ming Ke for their careful review and very helpful comments.
	9. References		The authors would like to acknowledge Italo Busi and Chandrasekar
			Ramachandran for their insightful MPLS-RT review and very helpful
			comments.
	9.1. Normative References		10. References
			10.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>.
	[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>.
	[SP-MPLS-Label]		[SPL] IANA, "Special-Purpose Multiprotocol Label Switching
	"Special-Purpose MPLS Label Values", 2019,		(MPLS) Label Values",
	<https://www.iana.org/assignments/mpls-label-values/mpls-		<https://www.iana.org/assignments/mpls-label-values/>.
	label-values.xml>.
	9.2. Informative References
	[I-D.bryant-mpls-sfl-control]		10.2. Informative References
	Bryant, S., Swallow, G., and S. Sivabalan, "A Simple
	Control Protocol for MPLS SFLs", draft-bryant-mpls-sfl-
	control-09 (work in progress), December 2020.
	[I-D.ietf-ippm-ioam-data]		[I-D.ietf-ippm-ioam-data]
	Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields		Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
	for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in		for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in
	progress), November 2020.		progress), November 2020.
	[I-D.ietf-ippm-ioam-direct-export]		[I-D.ietf-ippm-ioam-direct-export]
	Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F.,		Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F.,
	Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ		Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ
	OAM Direct Exporting", draft-ietf-ippm-ioam-direct-		OAM Direct Exporting", draft-ietf-ippm-ioam-direct-
	export-02 (work in progress), November 2020.		export-02 (work in progress), November 2020.
	[I-D.ietf-mpls-sfl-framework]		[I-D.ietf-mpls-sfl-control]
	Bryant, S., Chen, M., Swallow, G., Sivabalan, S., and G.		Bryant, S., Swallow, G., and S. Sivabalan, "A Simple
	Mirsky, "Synonymous Flow Label Framework", draft-ietf-		Control Protocol for MPLS SFLs", draft-ietf-mpls-sfl-
	mpls-sfl-framework-11 (work in progress), October 2020.		control-00 (work in progress), January 2021.
	[I-D.ietf-mpls-spl-terminology]
	Andersson, L., Kompella, K., and A. Farrel, "Special
	Purpose Label terminology", draft-ietf-mpls-spl-
	terminology-06 (work in progress), January 2021.
	[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual		[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
	Private Network (VPN) Terminology", RFC 4026,		Private Network (VPN) Terminology", RFC 4026,
	DOI 10.17487/RFC4026, March 2005,		DOI 10.17487/RFC4026, March 2005,
	<https://www.rfc-editor.org/info/rfc4026>.		<https://www.rfc-editor.org/info/rfc4026>.
	[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and		[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
	L. Yong, "The Use of Entropy Labels in MPLS Forwarding",		L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
	RFC 6790, DOI 10.17487/RFC6790, November 2012,		RFC 6790, DOI 10.17487/RFC6790, November 2012,
	<https://www.rfc-editor.org/info/rfc6790>.		<https://www.rfc-editor.org/info/rfc6790>.
	skipping to change at page 13, line 22 ¶		skipping to change at page 13, line 28 ¶
	Mirsky, "MPLS Flow Identification Considerations",		Mirsky, "MPLS Flow Identification Considerations",
	RFC 8372, DOI 10.17487/RFC8372, May 2018,		RFC 8372, DOI 10.17487/RFC8372, May 2018,
	<https://www.rfc-editor.org/info/rfc8372>.		<https://www.rfc-editor.org/info/rfc8372>.
	[RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S.,		[RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S.,
	Shakir, R., and J. Tantsura, "Entropy Label for Source		Shakir, R., and J. Tantsura, "Entropy Label for Source
	Packet Routing in Networking (SPRING) Tunnels", RFC 8662,		Packet Routing in Networking (SPRING) Tunnels", RFC 8662,
	DOI 10.17487/RFC8662, December 2019,		DOI 10.17487/RFC8662, December 2019,
	<https://www.rfc-editor.org/info/rfc8662>.		<https://www.rfc-editor.org/info/rfc8662>.
			[RFC8957] Bryant, S., Chen, M., Swallow, G., Sivabalan, S., and G.
			Mirsky, "Synonymous Flow Label Framework", RFC 8957,
			DOI 10.17487/RFC8957, January 2021,
			<https://www.rfc-editor.org/info/rfc8957>.
			[RFC9017] Andersson, L., Kompella, K., and A. Farrel, "Special-
			Purpose Label Terminology", RFC 9017,
			DOI 10.17487/RFC9017, April 2021,
			<https://www.rfc-editor.org/info/rfc9017>.
	Authors' Addresses		Authors' Addresses
	Weiqiang Cheng		Weiqiang Cheng
	China Mobile		China Mobile
	Beijing		Beijing
	China		China
	Email: chengweiqiang@chinamobile.com		Email: chengweiqiang@chinamobile.com
	Xiao Min		Xiao Min
	ZTE		ZTE Corp.
	Nanjing		Nanjing
	China		China
	Email: xiao.min2@zte.com.cn		Email: xiao.min2@zte.com.cn
	Tianran Zhou		Tianran Zhou
	Huawei		Huawei
	Beijing		Beijing
	China		China
End of changes. 56 change blocks.
	137 lines changed or deleted		173 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/