< draft-andersson-mpls-mna-fwk-01.txt		framework.txt
	MPLS Working Group L. Andersson		MPLS Working Group L. Andersson
	Internet-Draft Bronze Dragon Consulting		Internet-Draft Bronze Dragon Consulting
	Intended status: Informational S. Bryant		Intended status: Informational S. Bryant
	Expires: 29 October 2022 University of Surrey 5GIC		Expires: 27 November 2022 University of Surrey 5GIC
	M. Bocci		M. Bocci
	Nokia		Nokia
	T. Li		T. Li
	Juniper Networks		Juniper Networks
	27 April 2022		26 May 2022
	MPLS Network Actions Framework		MPLS Network Actions Framework
	draft-andersson-mpls-mna-fwk-01		draft-andersson-mpls-mna-fwk-02
	Abstract		Abstract
	This document specifies an architectural framework for the MPLS		This document specifies an architectural framework for the MPLS
	Network Actions (MNA) technologies. MNA technologies are used to		Network Actions (MNA) technologies. MNA technologies are used to
	indicate actions for Label Switched Paths (LSPs) and/or packets and		indicate actions for Label Switched Paths (LSPs) and/or MPLS packets
	to transfer data needed for these actions.		and to transfer data needed for these actions.
	The document describes a common set of protocol actions and		The document describes a common set of network actions and
	information elements supporting additional operational models and		information elements supporting additional operational models and
	capabilities of MPLS networks. Some of these actions are defined in		capabilities of MPLS networks. Some of these actions are defined in
	existing MPLS specifications, while others require extensions to		existing MPLS specifications, while others require extensions to
	existing specifications to meet the requirements found in		existing specifications to meet the requirements found in
	"Requirements for MPLS Label Stack Indicators and Ancillary Data".		"Requirements for MPLS Network Action Indicators and Ancillary Data".
	This document is the result of work started in MPLS Open Desgign
	Team, with participation by the 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 29 October 2022.		This Internet-Draft will expire on 27 November 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (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
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirement Language . . . . . . . . . . . . . . . . . . 4		1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2.1. Normative Definitions . . . . . . . . . . . . . . . . 4		1.2.1. Normative Definitions . . . . . . . . . . . . . . . . 4
	1.2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . 5		1.2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . 4
	2. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1. Scopes . . . . . . . . . . . . . . . . . . . . . . . . . 7		2.1. Scopes . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.2. Partial Processing . . . . . . . . . . . . . . . . . . . 7		2.2. Partial Processing . . . . . . . . . . . . . . . . . . . 7
	2.3. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 8		2.3. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.4. Positioning . . . . . . . . . . . . . . . . . . . . . . . 8		2.4. Positioning . . . . . . . . . . . . . . . . . . . . . . . 8
	2.5. State . . . . . . . . . . . . . . . . . . . . . . . . . . 8		2.5. State . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.1. The MNA Label . . . . . . . . . . . . . . . . . . . . . . 9		3.1. The MNA Label . . . . . . . . . . . . . . . . . . . . . . 8
	3.1.1. Existing Base SPL . . . . . . . . . . . . . . . . . . 9		3.1.1. Existing Base SPL . . . . . . . . . . . . . . . . . . 8
	3.1.2. New Base SPL . . . . . . . . . . . . . . . . . . . . 9		3.1.2. New Base SPL . . . . . . . . . . . . . . . . . . . . 8
	3.1.3. New Extended SPL . . . . . . . . . . . . . . . . . . 9		3.1.3. New Extended SPL . . . . . . . . . . . . . . . . . . 9
	3.1.4. User-Defined Label . . . . . . . . . . . . . . . . . 9		3.1.4. User-Defined Label . . . . . . . . . . . . . . . . . 9
	3.2. TC and TTL . . . . . . . . . . . . . . . . . . . . . . . 9		3.2. TC and TTL . . . . . . . . . . . . . . . . . . . . . . . 9
	3.2.1. TC and TTL retained . . . . . . . . . . . . . . . . . 9		3.2.1. TC and TTL retained . . . . . . . . . . . . . . . . . 9
	3.2.2. TC and TTL Repurposed . . . . . . . . . . . . . . . . 10		3.2.2. TC and TTL Repurposed . . . . . . . . . . . . . . . . 9
	3.3. Length of the NAS . . . . . . . . . . . . . . . . . . . . 10		3.3. Length of the NAS . . . . . . . . . . . . . . . . . . . . 10
	3.3.1. Last/Continuation Bits . . . . . . . . . . . . . . . 10		3.3.1. Last/Continuation Bits . . . . . . . . . . . . . . . 10
	3.3.2. Length Field . . . . . . . . . . . . . . . . . . . . 11		3.3.2. Length Field . . . . . . . . . . . . . . . . . . . . 10
	3.4. Encoding of Scopes . . . . . . . . . . . . . . . . . . . 11		3.4. Encoding of Scopes . . . . . . . . . . . . . . . . . . . 10
	3.5. Encoding a Network Action . . . . . . . . . . . . . . . . 11		3.5. Encoding a Network Action . . . . . . . . . . . . . . . . 11
	3.5.1. Bit Catalogs . . . . . . . . . . . . . . . . . . . . 11		3.5.1. Bit Catalogs . . . . . . . . . . . . . . . . . . . . 11
	3.5.2. Operation Codes . . . . . . . . . . . . . . . . . . . 12		3.5.2. Operation Codes . . . . . . . . . . . . . . . . . . . 11
	3.6. Encoding of Post-Stack Data . . . . . . . . . . . . . . . 12		3.6. Encoding of Post-Stack Data . . . . . . . . . . . . . . . 12
	3.6.1. First Nibble Considerations . . . . . . . . . . . . . 12		3.6.1. First Nibble Considerations . . . . . . . . . . . . . 12
	4. Definition of a Network Action . . . . . . . . . . . . . . . 13		4. Definition of a Network Action . . . . . . . . . . . . . . . 13
	5. Management Considerations . . . . . . . . . . . . . . . . . . 14		5. Management Considerations . . . . . . . . . . . . . . . . . . 13
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	9. Editorial attic . . . . . . . . . . . . . . . . . . . . . . . 14		9. Editorial attic . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Process Note on E2E . . . . . . . . . . . . . . . . . . . 15		9.1. Process Note on E2E . . . . . . . . . . . . . . . . . . . 14
	9.2. Concepts used in this Framework . . . . . . . . . . . . . 15		9.2. Concepts used in this Framework . . . . . . . . . . . . . 15
	9.3. LSE . . . . . . . . . . . . . . . . . . . . . . . . . . . 16		9.3. LSE . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.4. MPLS Forwarding model . . . . . . . . . . . . . . . . . . 16		9.4. MPLS Forwarding model . . . . . . . . . . . . . . . . . . 16
	9.4.1. Orginal Model . . . . . . . . . . . . . . . . . . . . 16		9.4.1. Orginal Model . . . . . . . . . . . . . . . . . . . . 16
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	10.1. Normative References . . . . . . . . . . . . . . . . . . 17		10.1. Normative References . . . . . . . . . . . . . . . . . . 17
	10.2. Informative References . . . . . . . . . . . . . . . . . 18		10.2. Informative References . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	This document specifies an architectural framework for the MPLS		This document specifies an architectural framework for the MPLS
	Network Actions (MNA) technologies. MNA technologies are used to		Network Actions (MNA) technologies. MNA technologies are used to
	indicate actions for LSPs and/or packets and to transfer data needed		indicate actions for LSPs and/or MPLS packets and to transfer data
	for these actions.		needed for these actions.
	The document describes a common set of protocol actions and		The document describes a common set of network actions and
	information elements supporting additional operational models and		information elements supporting additional operational models and
	capabilities of MPLS networks. Some of these actions are defined in		capabilities of MPLS networks. Some of these actions are defined in
	existing MPLS specifications, while others require extensions to		existing MPLS specifications, while others require extensions to
	existing specifications to meet the requirements found in		existing specifications to meet the requirements found in
	[I-D.bocci-mpls-miad-adi-requirements]. [Ed.: In a future draft, the		[I-D.ietf-mpls-miad-mna-requirements].
	language in the requirements draft will be changed to align with the
	terminology found here.]
	Forwarding actions are instructions to MPLS routers to apply		Forwarding actions are instructions to MPLS routers to apply
	additional actions when forwarding a packet. These might include		additional actions when forwarding a packet. These might include
	load-balancing a packet given its entropy, whether or not to perform		load-balancing a packet given its entropy, whether or not to perform
	fast reroute on a failure, and whether or not a packet has metadata		fast reroute on a failure, and whether or not a packet has metadata
	relevant to the forwarding decisions along the path.		relevant to the forwarding decisions along the path.
	This document generalizes the concept of "forwarding actions" into		This document generalizes the concept of "forwarding actions" into
	"network actions" to include any action that an MPLS router is		"network actions" to include any action that an MPLS router is
	requested to take on the packet. That includes any forwarding		requested to take on the packet. That includes any forwarding
	action, but may include other operations (such as security functions,		action, but may include other operations (such as security functions,
	OAM procedures, etc.) that are not directly related to forwarding of		OAM procedures, etc.) that are not directly related to forwarding of
	the packet.		the packet.
	This document is the result of work started in MPLS Open Desgign
	Team, with participation by the MPLS, PALS and DETNET working groups.
	1.1. Requirement Language		1.1. Requirement 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		"OPTIONAL" in this document are to be interpreted as described in
	BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	1.2. Terminology		1.2. Terminology
	1.2.1. Normative Definitions		1.2.1. Normative Definitions
	* Ancillary Data (AD): Data relating to the MPLS packet that may be		* Ancillary Data (AD): Data relating to the MPLS packet that may be
	used to affect the forwarding or other processing of that packet,		used to affect the forwarding or other processing of that packet,
	either at an Label Edge Router (LER) [RFC4221] or Label Switching		or resulting from the processing of the packet, either at an Label
	Router (LSR). This data may be encoded within a network action		Edge Router (LER) [RFC4221] or Label Switching Router (LSR). This
	sub-stack (see below) (in-stack data), and/or after the bottom of		data may be encoded within a network action sub-stack (see below)
	the label stack (post-stack data).		(in-stack data), and/or after the bottom of the label stack (post-
			stack data).
	* Network Action: An operation to be performed on a packet. A		* Network Action: An operation to be performed on a packet. A
	network action may affect router state, packet forwarding, or it		network action may affect router state, packet forwarding, or it
	may affect the packet in some other way. A network action is said		may affect the packet in some other way. A network action is said
	to be present if there is an indicator in the packet that invokes		to be present if there is an indicator in the packet that invokes
	the action.		the action.
	* Network Action Indication (NAI): An indication in the packet that		* Network Action Indication (NAI): An indication in the packet that
	a certain network action is to be perfomed. There may be		a certain network action is to be perfomed. There may be
	associated ancillary data in the packet.		associated ancillary data in the packet.
	* Network Action Sub-Stack (NAS): A set of related, contiguous Label		* Network Action Sub-Stack (NAS): A set of related, contiguous Label
	Stack Entries (LSEs). The first LSE is the Network Action Sub-		Stack Entries (LSEs) in the label stack. The first LSE is the
	stack Indicator. The TC and TTL values in the sub-stack may be		Network Action Sub-stack Indicator. The TC and TTL values in the
	redefined. The label field in the second and following LSE may be		sub-stack may be redefined. The label field in the second and
	redefined. Solutions MUST NOT redefine the S bit. See		following LSE may be redefined. Solutions MUST NOT redefine the S
	Section 3.1 through Section 3.5.		bit. See Section 3.1 through Section 3.5.
	* Network Action Sub-Stack Indicator (NSI): An LSE that contains a		* Network Action Sub-Stack Indicator (NSI): An LSE that contains a
	special label that indicates the start of a Network Action Sub-		special label that indicates the start of a Network Action Sub-
	stack.		stack.
	* Scope: The set of nodes that should perform a given action.		* Scope: The set of nodes that should perform a given action.
	1.2.2. Abbreviations		1.2.2. Abbreviations
	+==============+===========+========================================+		+==============+===========+=======================================+
	| Abbreviation |Meaning | Reference |		| Abbreviation | Meaning | Reference |
	+==============+===========+========================================+		+==============+===========+=======================================+
	| AD |Ancillary | [I-D.bocci-mpls-miad-adi-requirements] |		| AD | Ancillary | [I-D.ietf-mpls-miad-mna-requirements] |
	| |Data | |		| | Data | |
	+--------------+-----------+----------------------------------------+		+--------------+-----------+---------------------------------------+
	| bSPL |Base | [RFC9017] |		| bSPL | Base | [RFC9017] |
	| |Special | |		| | Special | |
	| |Purpose | |		| | Purpose | |
	| |Label | |		| | Label | |
	+--------------+-----------+----------------------------------------+		+--------------+-----------+---------------------------------------+
	| ECMP |Equal Cost | |		| ECMP | Equal | |
	| |Multipath | |		| | Cost | |
	+--------------+-----------+----------------------------------------+		| | Multipath | |
	| eSPL |Extended | [RFC9017] |		+--------------+-----------+---------------------------------------+
	| |Special | |		| eSPL | Extended | [RFC9017] |
	| |Purpose | |		| | Special | |
	| |Label | |		| | Purpose | |
	+--------------+-----------+----------------------------------------+		| | Label | |
	| HBH |Hop by hop | In the MNA context, this document. |		+--------------+-----------+---------------------------------------+
	+--------------+-----------+----------------------------------------+		| HBH | Hop by | In the MNA context, this document. |
	| I2E |Ingress to | In the MNA context, this document. |		| | hop | |
	| |Egress | |		+--------------+-----------+---------------------------------------+
	+--------------+-----------+----------------------------------------+		| I2E | Ingress | In the MNA context, this document. |
	| ISD |In stack | [I-D.bocci-mpls-miad-adi-requirements] |		| | to Egress | |
	| |data | |		+--------------+-----------+---------------------------------------+
	+--------------+-----------+----------------------------------------+		| ISD | In stack | [I-D.ietf-mpls-miad-mna-requirements] |
	| LSE |Label Stack| [RFC3032] |		| | data | |
	| |Entry | |		+--------------+-----------+---------------------------------------+
	+--------------+-----------+----------------------------------------+		| LSE | Label | [RFC3032] |
	| MNA |MPLS | This documnent |		| | Stack | |
	| |Network | |		| | Entry | |
	| |Actions | |		+--------------+-----------+---------------------------------------+
	+--------------+-----------+----------------------------------------+		| MNA | MPLS | This documnent |
	| NAI |Network | [I-D.bocci-mpls-miad-adi-requirements] |		| | Network | |
	| |Action | |		| | Actions | |
	| |Indicator | |		+--------------+-----------+---------------------------------------+
	+--------------+-----------+----------------------------------------+		| NAI | Network | [I-D.ietf-mpls-miad-mna-requirements] |
	| NAS |Network | This document |		| | Action | |
	| |Action Sub-| |		| | Indicator | |
	| |Stack | |		+--------------+-----------+---------------------------------------+
	+--------------+-----------+----------------------------------------+		| NAS | Network | This document |
	| PSD |Post stack | [I-D.bocci-mpls-miad-adi-requirements] |		| | Action | |
	| |data | and Section 3.6 |		| | Sub-Stack | |
	+--------------+-----------+----------------------------------------+		+--------------+-----------+---------------------------------------+
	| SPL |Special | [RFC9017] |		| PSD | Post | [I-D.ietf-mpls-miad-mna-requirements] |
	| |Purpose | |		| | stack | and Section 3.6 |
	| |Label | |		| | data | |
	+--------------+-----------+----------------------------------------+		+--------------+-----------+---------------------------------------+
			| SPL | Special | [RFC9017] |
			| | Purpose | |
			| | Label | |
			+--------------+-----------+---------------------------------------+
	Table 1: Abbreviations		Table 1: Abbreviations
	2. Structure		2. Structure
	An MNA solution is envisioned as a set of network action sub-stacks		An MNA solution is envisioned as a set of network action sub-stacks
	that indicate the network actions being invoked, plus possible post-		that indicate the network actions being invoked, plus possible post-
	stack data. A solution must specify where in the label stack the		stack data. A solution must specify where in the label stack the
	network actions sub-stacks occur, if and how frequently they should		network actions sub-stacks occur, if and how frequently they should
	be replicated, and how network action sub-stack and post-stack data		be replicated, and how network action sub-stack and post-stack data
	are encoded.		are encoded.
	skipping to change at page 8, line 44 ¶		skipping to change at page 8, line 29 ¶
	Several possibilities to carry NAI's have been discussed in MNA		Several possibilities to carry NAI's have been discussed in MNA
	drafts and in the MPLS Open DT. In this section, we enumerate the		drafts and in the MPLS Open DT. In this section, we enumerate the
	possibilities and some considerations for the various alternatives.		possibilities and some considerations for the various alternatives.
	All types of network actions are represented in the MPLS label stack		All types of network actions are represented in the MPLS label stack
	by a set of LSEs termed a network action sub-stack (NAS). An NAS		by a set of LSEs termed a network action sub-stack (NAS). An NAS
	consists of a special label, followed by LSEs that specify which		consists of a special label, followed by LSEs that specify which
	network actions are to be performed on the packet, and the in-stack		network actions are to be performed on the packet, and the in-stack
	ancillary data for each indicated network action.		ancillary data for each indicated network action.
	[I-D.bocci-mpls-miad-adi-requirements] requires that a solution not		[I-D.ietf-mpls-miad-mna-requirements] requires that a solution not
	add unnecessary LSEs to the sub-stack (Section 3.1, requirement 5).		add unnecessary LSEs to the sub-stack (Section 3.1, requirement 6).
	Accordingly, solutions should also make efficient use of the bits		Accordingly, solutions should also make efficient use of the bits
	within the sub-stack, as inefficient use of the bits will result in		within the sub-stack, as inefficient use of the bits will result in
	the addition of unnecessary LSEs.		the addition of unnecessary LSEs.
	3.1. The MNA Label		3.1. The MNA Label
	The first LSE in a network action sub-stack contains a special label		The first LSE in a network action sub-stack contains a special label
	that indicates a network action sub-stack. A solution has several		that indicates a network action sub-stack. A solution has several
	choices for this special label.		choices for this special label.
	skipping to change at page 13, line 41 ¶		skipping to change at page 13, line 26 ¶
	only the egress node that pops the final label off of the label		only the egress node that pops the final label off of the label
	stack, or specific nodes along the label switched path.		stack, or specific nodes along the label switched path.
	* State: The document should specify if the network action can		* State: The document should specify if the network action can
	modify state in the network, and if so, the state that may be		modify state in the network, and if so, the state that may be
	modified and its side-effects.		modified and its side-effects.
	* Required/Optional: The document should specify whether a node is		* Required/Optional: The document should specify whether a node is
	required to perform the network action.		required to perform the network action.
	* In-Stack Data: The number of LSEs of in-stack data. If this is of		* In-Stack Data: The number of LSEs of in-stack data and its
	a variable length, then the solution must specify how an		encoding. If this is of a variable length, then the solution must
	implementation can determine this length without implementing the		specify how an implementation can determine this length without
	network action.		implementing the network action.
	* Post-Stack Data: The encoding of post-stack data, if any. If this		* Post-Stack Data: The encoding of post-stack data, if any. If this
	is of a variable length, then the solution must specify how an		is of a variable length, then the solution must specify how an
	implementation can determine this length without implementing the		implementation can determine this length without implementing the
	network action.		network action.
	A solution should create an IANA registry for network actions.		A solution should create an IANA registry for network actions.
	5. Management Considerations		5. Management Considerations
	skipping to change at page 14, line 41 ¶		skipping to change at page 14, line 30 ¶
	This document does not make any allocations of code points from IANA		This document does not make any allocations of code points from IANA
	registries.		registries.
	As long as the "does not make any allocations ..." from IANA is true,		As long as the "does not make any allocations ..." from IANA is true,
	this pragraph shoukd be removed by the RFC-Editor. If it turns out		this pragraph shoukd be removed by the RFC-Editor. If it turns out
	that we will need to do IANA allocation, a proper IANA section will		that we will need to do IANA allocation, a proper IANA section will
	be added.		be added.
	8. Acknowledgements		8. Acknowledgements
			This document is the result of work started in MPLS Open Desgign
			Team, with participation by the MPLS, PALS and DETNET working groups.
	The authors would like to thank Adrian Farrel for his contributions		The authors would like to thank Adrian Farrel for his contributions
	and to John Drake for his comments.		and to John Drake for his comments.
	9. Editorial attic		9. Editorial attic
	This section contains old material that will be discarded before		This section contains old material that will be discarded before
	publication, assuming we don't find it useful between now and then.		publication, assuming we don't find it useful between now and then.
	9.1. Process Note on E2E		9.1. Process Note on E2E
	skipping to change at page 17, line 4 ¶		skipping to change at page 16, line 49 ¶
	| | +------------+ | | +----------------------+ |		| | +------------+ | | +----------------------+ |
	| +----------------------| | |		| +----------------------| | |
	| | | +----------------------+ |		| | | +----------------------+ |
	| +-->|Forwarding Parameters | |		| +-->|Forwarding Parameters | |
	| +----------------------+ |		| +----------------------+ |
	| |		| |
	| |		| |
	| LSE = Label Stack Entry (what many people call a label) |		| LSE = Label Stack Entry (what many people call a label) |
	| FIB = Forwarding Information (date)Base |		| FIB = Forwarding Information (date)Base |
	+-----------------------------------------------------------------+		+-----------------------------------------------------------------+
	Figure 2: MPLS Original Forwarding Model		Figure 2: MPLS Original Forwarding Model
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.bocci-mpls-miad-adi-requirements]		[I-D.ietf-mpls-miad-mna-requirements]
	Bocci, M. and S. Bryant, "Requirements for MPLS Network		Bocci, M. and S. Bryant, "Requirements for MPLS Network
	Action Indicators and MPLS Ancillary Data", Work in		Action Indicators and MPLS Ancillary Data", Work in
	Progress, Internet-Draft, draft-bocci-mpls-miad-adi-		Progress, Internet-Draft, draft-ietf-mpls-miad-mna-
	requirements-04, 11 April 2022,		requirements-00, 5 May 2022,
	<https://www.ietf.org/archive/id/draft-bocci-mpls-miad-		<https://www.ietf.org/archive/id/draft-ietf-mpls-miad-mna-
	adi-requirements-04.txt>.		requirements-00.txt>.
	[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>.
	[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
	Label Switching Architecture", RFC 3031,		Label Switching Architecture", RFC 3031,
	DOI 10.17487/RFC3031, January 2001,		DOI 10.17487/RFC3031, January 2001,
	<https://www.rfc-editor.org/info/rfc3031>.		<https://www.rfc-editor.org/info/rfc3031>.
End of changes. 35 change blocks.
	107 lines changed or deleted		107 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/