draft-ietf-mpls-lsp-ping-registries-update-02.txt		draft-ietf-mpls-lsp-ping-registries-update-03.txt
	MPLS Working Group L. Andersson		MPLS Working Group L. Andersson
	Internet-Draft Bronze Dragon Consulting		Internet-Draft Bronze Dragon Consulting
	Updates: 8029, 8611 (if approved) M. Chen		Updates: 8029, 8611 (if approved) M. Chen
	Intended status: Standards Track Huawei Techologies		Intended status: Standards Track Huawei Techologies
	Expires: October 18, 2020 C. Pignataro		Expires: February 18, 2021 C. Pignataro
	Cisco Systems		Cisco Systems
	T. Saad		T. Saad
	Juniper Networks		Juniper Networks
	April 16, 2020		August 17, 2020
	Updating the IANA MPLS LSP Ping Parameters		Updating the IANA MPLS LSP Ping Parameters
	draft-ietf-mpls-lsp-ping-registries-update-02		draft-ietf-mpls-lsp-ping-registries-update-03
	Abstract		Abstract
	This document updates RFC 8029 and RFC 8611 that both define IANA		This document updates RFC 8029 and RFC 8611 that both define IANA
	registries for MPLS LSP Ping. It also updates the language that is		registries for MPLS LSP Ping. It also updates the description of the
	used to define the procedures for responses are sent when an unkwon		procedures for the responses sent when an unknown or erroneous code
	or errored code point is found. The updates are for clarification		point is found. The updates are to clarify and align this name space
	and to align this name space with recent developments.		with recent developments.
	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 October 18, 2020.		This Internet-Draft will expire on February 18, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 19 ¶		skipping to change at page 2, line 19 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3
	2. Updating the Message Types, Reply Mode and Return Codes		2. Updating the Message Types, Reply Mode and Return Codes
	Registries . . . . . . . . . . . . . . . . . . . . . . . . . 3		Registries . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Updating the TLV and sub-TLV registries . . . . . . . . . . . 4		3. Updating the TLV and sub-TLV registries . . . . . . . . . . . 4
	3.1. General principles the LSP Ping TLV and sub-TLV		3.1. General principles the LSP Ping TLV and sub-TLV
	registries . . . . . . . . . . . . . . . . . . . . . . . 4		registries . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1.1. Unrecognized Experimental and Private TLVs and sub-		3.1.1. Unrecognized Experimental Use TLVs and sub-TLVs . . . 5
	TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Changes to the LSP Ping Registries . . . . . . . . . . . 5		3.2. Changes to the LSP Ping Registries . . . . . . . . . . . 5
	3.2.1. Common Changes to the TLV and sub-TLV Registries . . 5		3.2.1. Common Changes to the TLV and sub-TLV Registries . . 5
	4. Text Chages/Updates to Related RFCs . . . . . . . . . . . . . 6		4. Updates to Related RFCs . . . . . . . . . . . . . . . . . . . 6
	4.1. Text Changes to RFC 8029 . . . . . . . . . . . . . . . . 6		4.1. Updates to RFC 8029 . . . . . . . . . . . . . . . . . . . 6
	4.2. Text Changes to RFC 8611 . . . . . . . . . . . . . . . . 7		4.2. Updates to RFC 8611 . . . . . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	6.1. Updates of Message Type, Reply Mode and Return Codes		6.1. Updates of Message Type, Reply Mode and Return Codes
	Registries . . . . . . . . . . . . . . . . . . . . . . . 8		Registries . . . . . . . . . . . . . . . . . . . . . . . 9
	6.2. Common Registration Procedures for TLVs and sub-TLVs . . 9		6.2. Common Registration Procedures for TLVs and sub-TLVs . . 9
	6.3. IANA Assignments for TLVs and sub-TLVs . . . . . . . . . 9		6.3. IANA Assignments for TLVs and sub-TLVs . . . . . . . . . 10
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . 11		8.1. Normative References . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	When RFC 8029 [RFC8029] was published it contained updates to the		When RFC 8029 [RFC8029] was published it contained updates to the
	"Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)		"Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
	Ping Parameters" IANA name space [IANA-LSP-PING].		Ping Parameters" IANA name space [IANA-LSP-PING].
	RFC 8611 [RFC8611] updated the LSP Ping IANA registries to match RFC		RFC 8611 [RFC8611] updated the LSP Ping IANA registries to match RFC
	8029. This document further clarifies the entries in those		8029. This document further clarifies the entries in those
	registries and makes the definitions more precise.		registries and makes the definitions more precise.
	skipping to change at page 3, line 27 ¶		skipping to change at page 3, line 27 ¶
	o Sub-TLVs for TLV 11 [IANA-Sub-11]		o Sub-TLVs for TLV 11 [IANA-Sub-11]
	o Sub-TLVs for TLV 20 [IANA-Sub-20]		o Sub-TLVs for TLV 20 [IANA-Sub-20]
	o Sub-TLVs for TLV 23 [IANA-Sub-23]		o Sub-TLVs for TLV 23 [IANA-Sub-23]
	o Sub-TLVs for TLV 27 [IANA-Sub-27]		o Sub-TLVs for TLV 27 [IANA-Sub-27]
	The registry for sub-TLVs for TLV 9 [IANA-Sub-9] is not updated.		The registry for sub-TLVs for TLV 9 [IANA-Sub-9] is not updated.
	Third, some code points (TLVs and sub-TLVs) are "mandatory" and		Third, some code points (TLVs and sub-TLVs) are "mandatory" or
	"optional". Contrary to how other RFCs use these words, indicating		"optional". Contrary to how other RFCs use these words, indicating
	that it is mandatory or optional to include the code points in a		that it is mandatory or optional to include the code points in a
	message, RFC 8029 use the words to indicate that an acction might or		message, RFC 8029 use the words to indicate that an action might or
	might nt be nesesary. The words "mandatory and "optional" are		might not be necessary. This document drops the words "mandatory and
	dropped and the text is changed to focus on what should be doen.		"optional" and the text is changed to focus on what should be done.
	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 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
	capitals, as shown here.		capitals, as shown here.
	2. Updating the Message Types, Reply Mode and Return Codes Registries		2. Updating the Message Types, Reply Mode and Return Codes Registries
	The following changes are made to the Message Types, Reply Modes and		The following changes are made to the Message Types, Reply Modes and
	Return Codes [IANA-MT] registries.		Return Codes [IANA-MT] registries.
	o In the listing of assignments the term "Vendor Private Use" is		o in the listing of assiged code points the term "Vendor Private
	changed to "Private Use"		Use" is changed to "Private Use".
	o a small set of code points (4 code points) for Experimental Use is
	added by reducing the range for "Private Use".
	o the registration procedure "Specification Required" is changed to		o the registration procedure "Specification Required" is changed to
	"RFC Required" and the note "Experimental RFC needed" is removed		"RFC Required" and the note "Experimental RFC needed" is removed
			o a small set of code points (4 code points) for Experimental Use is
			added by reducing the range for "RFC Required" range.
	o the registration procedures "Private Use" and "Experimental Use"		o the registration procedures "Private Use" and "Experimental Use"
	are added to the table of registration procedures		are added to the table of registration procedures
	o A note "Not to be assigned" is added for the registration		o A note "Not to be assigned" is added for the registration
	procedures "Private Use" and "Experimental Use"		procedures "Private Use" and "Experimental Use"
	o In the list that capture the assignment status, the fields that		o In the lists that capture the assignment status, the fields that
	are reserved, i.e. 0, Private Use and Experimental Use are		are reserved, i.e. 0 (zero), Private Use and Experimental Use are
	clearly marked.		clearly marked as such.
	* In the Return Codes [IANA-RC] registry the code point "0"		* In the Return Codes [IANA-RC] [IANA-RC] registry the code point
	already been assigned. This assignment is not changed and this		"0" has already been assigned. This assignment is not changed
	registry will not have the "0" value "Reserved".		and in this registry the code point "0" continues to be
			assigned as "No Return Code".
	The new Registration Procedures layout and the new assignments for		The new Registration Procedures, the registry layouts and the new
	these registries will be found in Section 6.1.		assignments for these registries will be found in Section 6.1.
	3. Updating the TLV and sub-TLV registries		3. Updating the TLV and sub-TLV registries
	3.1. General principles the LSP Ping TLV and sub-TLV registries		3.1. General principles the LSP Ping TLV and sub-TLV registries
	The following principles are valid for all the LSP Ping TLV and sub-		The following principles are valid for all the LSP Ping TLV and sub-
	TLV IANA registries		TLV IANA registries
	o all TLVs and sub-TLVs with a typ in the the range 0-32767 require		o all TLVs and sub-TLVs with a type in the range 0-32767 require a
	a response if they are not recognized		response if they are not recognized
	o all TLVs and sub-TLVs in the range 32768-65535 may be silently		o all TLVs and sub-TLVs in the range 32768-65535 may be silently
	dropped if the are not recognized		dropped if they are not recognized
	The range of each TLV and sub-TLV registry is divided into wto		The range of each TLV and sub-TLV registry is divided into two
	blocks, one with a range from 0 to 32767 for TLVs and sub-TLVs that		blocks, one with a range from 0 to 32767 for TLVs and sub-TLVs that
	require a response if not recognized. Another block in the range		require a response if not recognized. The other block in the range
	from 32768 to 65535, this block is for TLVs and sub-TLVs that may be		from 32768 to 65535 for TLVs and sub-TLVs that may be silently
	silently dropped if not recognized.		dropped, possibly stepped over, if not recognized.
	Each of the blocks has code point spaces with the following		Each of the blocks has code point spaces with the following
	registration procedures:		registration procedures:
	o Standards Action		o Standards Action
	o RFC Required		o RFC Required
	o Experimental Use		o Experimental Use
	o Private Use		o First come, first served (FCFS)
	The exact defintion of registration procedures for IANA registries		The exact defintions of these procedures are found in [RFC8126]
	are found in [RFC8126]
	3.1.1. Unrecognized Experimental and Private TLVs and sub-TLVs		3.1.1. Unrecognized Experimental Use TLVs and sub-TLVs
	Unrecognized TLVs and sub-TLVs for Expereimetal USe and Privagte Use		Unrecognized TLVs and sub-TLVs in the Experimetal Use, and FCFS
	are handled as any other unrecognised TLV or sub-TLV.		ranges are handled as any other unrecognized TLV or sub-TLV.
	o If the unrecognized TLV or sub-TLV is from the Experimental Use		o If the unrecognized TLV or sub-TLV is from the Experimental Use
	range (37144-37147) or from the Private Use range (31748-32767) a		range (37140-37143) or from the FCFS range (31744-32767) a the
	the Return Code of 2 ("One or more of the TLVs was not		Return Code of 2 ("One or more of the TLVs was not understood")
	understood") will be sent in the echo response.		will be sent in the echo response.
	o If the unrecognized TLV or sub-TLV is from the Experimental Use		o If the unrecognized TLV or sub-TLV is from the Experimental Use
	range (64512-64515) or from the Private Use range (64515-65535)		range (64508-64511) or from the Private Use range (64512-65535)
	the TLVs SHOULD be silently ignored.		the TLVs SHOULD be silently ignored and possibly be stepped over.
	IETF does not prescribe how recognized or unrecognized Experimental		IETF does not prescribe how recognized or unrecognized Experimental
	Use and Private Use TLVs and sub-TLVs are handled in experimental or		Use and Private Use TLVs and sub-TLVs are handled in experimental or
	private networks, that is up to the agency running the experiment or		private networks, that is up to the agency running the experiment or
	the private network. The statement above relates to how standard		the private network. The statement above describes how standards
	compliant implementations will treat the unrecognized TLVs and sub-		compliant implementations will treat the unrecognized TLVs and sub-
	TLVs from these ranges.		TLVs from these ranges.
	3.2. Changes to the LSP Ping Registries		3.2. Changes to the LSP Ping Registries
	This section lists the changes to each MPLS LSP Ping Registry.		This section lists the changes to each MPLS LSP Ping TLV and sub-TLV
	Section 6.1, Section 6.2 and Section 6.3 set out how the new versions		Registry. Section 6.1, Section 6.2 and Section 6.3 outline how the
	of the IANA registries should look, together with the registration		new versions of the IANA registries should look, together with the
	procedures.		registration procedures for each registry.
	3.2.1. Common Changes to the TLV and sub-TLV Registries		3.2.1. Common Changes to the TLV and sub-TLV Registries
	The following changes are made to the TLV and sub-TLV registries.		The following changes are made to the TLV and sub-TLV registries.
	o the registration procedures "Private Use" and "Experimental Use"		o the registration procedures "First Come Frst Served (FCFS)" and
	are added to the table of registration procedures		"Experimental Use" are added to the table of registration
			procedures
	o two small sets of code points (2 times 4 code points) for		o two small sets of code points (4 code points each) for
	experimental use is added, actually they are take from the range		Experiemental Use are created. The first set are for the range
	for "Private Use".		that requires a response if the TLV or sub-TLV is not recognised;
			the sedond set are for the range there the TLV or sub-TLV that MAY
			be silently dropped if not recognized. The code points for
			experimental use are actually taken from the two ranges now called
			"RFC Required".
	o the registration procedure "Specification Required" is changed to		o the registration procedure "Specification Required" is changed to
	"RFC Required" and the note "Experimental RFC needed" is removed		"RFC Required" and the note "Experimental RFC needed" is removed
	o In the listing of assignements the term "Vendor Private Use" is		o In the listing of assignments the term "Vendor Private Use" is
	changed to "Private Use"		changed to "First Come First Served (FCFS)"
	o In the listing of assignments the range for "Experimental Use" is		o In the listing of assignments the range for "Experimental Use" is
	added		added
	o A note "Not to be assigned" is added for the registration		o A note saying "Not to be assigned" is added for the registration
	procedures "Experimental Use" and "Private Use"		procedures "Experimental Use"
	o In the list that capture assignment status, the fields that are		o In the list that capture assignment status, the fields that are
	reserved, i.e. 0, Experimental Use and Private Use are clearly		reserved, i.e. 0 (zero) and Experimental Use are clearly marked.
	marked.
	The new Registration Procedures description and the new assignments		The new Registration Procedures description and the new assignments
	for these registries will be found in Section 6.2 and Section 6.3.		for these registries are shown in Section 6.2 and Section 6.3.
	4. Text Chages/Updates to Related RFCs		4. Updates to Related RFCs
	Some referenced RFCs are using the concept "mandatory TLVs" and		Some referenced RFCs are using the concept "mandatory TLVs" and
	"mandatory sub-TLVs" to indicate that if a TLV or sub-TLV of the		"mandatory sub-TLVs" to indicate that, if a TLV or sub-TLV of the
	range 0-16383 or 16384-31743 is present in a message but not		range 0-16383 or 16384-31743 in a message is not understood, an error
	understood, error message need to be sent in response.		message needs to be sent in response.
	Since other RFCs are using "mandatory TLVs" and "mandatory sub-TLVs"		The same RFCs use "optional TLVs" and "optional sub-TLVs" to mean
	to indicate TLVs and sub-TLVs that must be present in a message, we		TLVs or sub-TLVs that can be silently ignored if not recognized.
	want to discontinue the use of "mandatory" to indicate TLVs and sub-
	TLVs that requires an error message in response if not understood.
	The changes to the RFCs below are intended to align with this
	practice.
	4.1. Text Changes to RFC 8029		Since other RFCs use "mandatory TLVs" and "mandatory sub-TLVs" to
			indicate TLVs and sub-TLVs that must be present in a message, we want
			to discontinue the use of "mandatory" to indicate TLVs and sub-TLVs
			that requires an error message in response if not understood. The
			changes to the RFCs below are intended to align with this practice.
	Mandatory and optional is used in this way on page 14 and 15 in		4.1. Updates to RFC 8029
			Mandatory and optional is used to indicate whether are response ir
			needed or if at TLV or sub-TLV is not understoond page 14 and 15 in
	Section 3 of RFC 8029.		Section 3 of RFC 8029.
	The text in those two paragraphs are now changed to:		The text in those two paragraphs are now updated to the following:
	TLV and sub-TLV Types less than 32768 (i.e., with the high-order		TLV and sub-TLV Types less than 32768 (i.e., with the high-order
	bit equal to 0) are TLVs and sub-TLVs that MUST either be		bit equal to 0) are TLVs and sub-TLVs that MUST either be
	supported by an implementation or result in the Return Code of 2		supported by an implementation or result in the Return Code of 2
	("One or more of the TLVs was not understood") being sent in the		("One or more of the TLVs was not understood") being sent in the
	echo response.		echo response.
	An implementation that does not understand or support a received		An implementation that does not understand or support a received
	TLV or sub-TLV with Type greater than or equal to 32768 (i.e.,		TLV or sub-TLV with Type greater than or equal to 32768 (i.e.,
	with the high-order bit equal to 1) SHOULD ignore and step over		with the high-order bit equal to 1) SHOULD ignore and step over
	the TLV or sub-TLV, however an implementation MAY send an echo		the TLV or sub-TLV, however an implementation MAY send an echo
	response with Return Code 2 ("One or more of the TLVs was not		response with Return Code 2 ("One or more of the TLVs was not
	understood") as it would have doen if the high order bit had been		understood") as it would have done if the high order bit had been
	clear.		clear.
	In Section 3.8 of RFC 8029 "mandatory" is used in the same way. The		In Section 3.8 of RFC 8029 "mandatory" is used in the same way. The
	first two paragaraphs of this section ar now changed to read:		first two paragraphs of this section are now updated to read as
			follows:
	The following TLV is a TLV that MAY be included in an echo reply		The following TLV is a TLV that MAY be included in an echo reply
	to inform the sender of an echo request icluding TLVs or sub-TLVs		to inform the sender of an echo request that includes TLVs or sub-
	Types greater than or equal to 32768 (i.e., with the high-order		TLVs Types greater than or equal to 32768 (i.e., with the high-
	bit equal to 1) are iether nor supported by the implementation or		order bit equal to 1) are either not supported by the
	parsed and found to be in error.		implementation or parsed and found to be in error.
	The Value field contains the TLVs, including sub-TLVs, that were		The Value field contains the TLVs, including sub-TLVs, that were
	not understood, encoded as sub-TLVs.		not understood, encoded as sub-TLVs.
	4.2. Text Changes to RFC 8611		4.2. Updates to RFC 8611
	The "Sub-TLVs for TLV Type 6" registry is now updated to align with		The "Sub-TLVs for TLV Type 6" registry is now updated to align with
	changes defined in this document.		changes defined in this document.
	The registration procedures for the "Sub-TLVs for TLV Type 6"		The registration procedures for the "Sub-TLVs for TLV Type 6"
	registry will now be like this:		registry will now be as follows:
	+-------------+-------------------+---------------------------------+		+-------------+-------------------+---------------------------------+
	| Range | Registration | Note |		| Range | Registration | Note |
	| | Procedures | |		| | Procedures | |
	+-------------+-------------------+---------------------------------+		+-------------+-------------------+---------------------------------+
	| 0-16383 | Standards Action | This range is for sub-TLVs that |		| 0-16383 | Standards Action | This range is for sub-TLVs that |
	| | | require an error message if not |		| | | require an error message if not |
	| | | recognized. |		| | | recognized. |
	| 16384-31743 | RFC Required | This range is for sub-TLVs that |		| 16384-31739 | RFC Required | This range is for sub-TLVs that |
			| | | require an error message if not |
			| | | recognized. |
			| 31740-31743 | Experimental Use | Reserved not to be assigned |
			| 31744-32767 | FCFS | This range is for sub-TLVs that |
	| | | require an error message if not |		| | | require an error message if not |
	| | | recognized. |		| | | recognized. |
	| 31744-32767 | Private Use | Not to be assigned |
	| 32768-49161 | Standards Action | This range is for sub-TLVs that |		| 32768-49161 | Standards Action | This range is for sub-TLVs that |
	| | | can be silently dropped if not |		| | | can be silently dropped if not |
	| | | recognized. |		| | | recognized. |
	| 49162-64511 | RFC Required | This range is for sub-TLVs that |		| 49162-64507 | RFC Required | This range is for sub-TLVs that |
			| | | can be silently dropped if not |
			| | | recognized. |
			| 64508-64511 | Experimental Use | Reserved not to be assigned |
			| 64512-65535 | FCFS | This range is for sub-TLVs that |
	| | | can be silently dropped if not |		| | | can be silently dropped if not |
	| | | recognized. |		| | | recognized. |
	| 64512-65535 | Private Use | Not to be assigned |
	+-------------+-------------------+---------------------------------+		+-------------+-------------------+---------------------------------+
	Sub-TLVs for TLV Type 6 Registration Procedures		Sub-TLVs for TLV Type 6 Registration Procedures
	5. Security Considerations		5. Security Considerations
	This document updates IANA registries, some terminology used to		This document updates IANA registries. It also updates terminology
	define, and clarifies the terminology related to the code points in		used to define, and clarifies the terminology related to the code
	the registries. The document does not change how the code-points in		points in the registries. The document does not change how the code-
	the registries are used. This should not create any new threats.		points in the registries are used. This should not create any new
			threats.
	However, the updated terminology and the clarifications improve		However, the updated terminology and the clarifications improve
	security because it makes it more likely that implementations will be		security because it makes it more likely that implementations will be
	consistent and harder to attack.		consistent and harder to attack.
	6. IANA Considerations		6. IANA Considerations
	IANA is requested to update the LSP Ping name space as described in		IANA is requested to update the LSP Ping name space as described in
	this document.		this document.
	6.1. Updates of Message Type, Reply Mode and Return Codes Registries		6.1. Updates of Message Type, Reply Mode and Return Codes Registries
	This section details the updated registration procedures and		This section details the updated registration procedures and
	allocations for: Message Type, Reply Mode and Return Codes		allocations for Message Type, Reply Mode and Return Codes registries.
	registries.
	+---------+--------------------+------------------------------------+		+---------+--------------------+------------------------------------+
	| Range | Registration | Note |		| Range | Registration | Note |
	| | Procedures | |		| | Procedures | |
	+---------+--------------------+------------------------------------+		+---------+--------------------+------------------------------------+
	| 0-191 | Standards Action | |		| 0-191 | Standards Action | |
	| 192-247 | RFC Required | |		| 192-247 | RFC Required | |
	| 248-251 | Experimental Use | Not to be assigned |		| 248-251 | Experimental Use | Not to be assigned |
	| 252-255 | Private Use | Not to be assigned |		| 252-255 | Private Use | Not to be assigned |
	+---------+--------------------+------------------------------------+		+---------+--------------------+------------------------------------+
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 35 ¶
	| 0 | Reserved | This document |		| 0 | Reserved | This document |
	| 1-247 | No changes to the existing | |		| 1-247 | No changes to the existing | |
	| | assignments | |		| | assignments | |
	| 248-251 | Reserved for Experimental Use | This document |		| 248-251 | Reserved for Experimental Use | This document |
	| 252-255 | Reserved for Private Use | [RFC8029] |		| 252-255 | Reserved for Private Use | [RFC8029] |
	+---------+---------------------------------+-----------------------+		+---------+---------------------------------+-----------------------+
	Common Assignments for the Message Types, Reply Mode and Return Code		Common Assignments for the Message Types, Reply Mode and Return Code
	registries		registries
	Note that for the Return Code registry the assignment for code point		Note that for the Return Code registry an assignment for code point
	zero has been previously assigned, it is not changed but will remain:		zero has been previously msde, it is not changed but remains:
	+-------+----------------------------------+------------------------+		+-------+----------------------------------+------------------------+
	| Value | Meaning | Reference |		| Value | Meaning | Reference |
	+-------+----------------------------------+------------------------+		+-------+----------------------------------+------------------------+
	| 0 | No return code | [RFC8029] |		| 0 | No return code | [RFC8029] |
	+-------+----------------------------------+------------------------+		+-------+----------------------------------+------------------------+
	Assignment for code point 0 in the Return Code registry		Assignment for code point 0 in the Return Code registry
	6.2. Common Registration Procedures for TLVs and sub-TLVs		6.2. Common Registration Procedures for TLVs and sub-TLVs
	This section describes the new registration procedures for the TLV		This section describes the new registration procedures for the TLV
	and sub-TLV registries. The registry for sub-TLV 9 ([IANA-Sub-9] is		and sub-TLV registries. The registry for sub-TLV 9 ([IANA-Sub-9] is
	not changed.		not changed.
	+-------------+-------------------+---------------------------------+		+-------------+-------------------+---------------------------------+
	| Range | Registration | Note |		| Range | Registration | Note |
	| | Procedures | |		| | Procedures | |
	+-------------+-------------------+---------------------------------+		+-------------+-------------------+---------------------------------+
	| 0-16383 | Standards Action | This range is for TLVs that |		| 0-16383 | Standards Action | This range is for TLVs anf sub- |
	| | | require an error message if not |		| | | TLVs that require an error |
	| | | recognized. |		| | | message if not recognized. |
	| 16384-31743 | RFC Required | This range is for TLVs that |		| 16384-31739 | RFC Required | This range is for TLVs anf sub- |
	| | | require an error message if not |		| | | TLVs that require an error |
	| | | recognized. |		| | | message if not recognized. |
	| 37144-37147 | Experimental Use | Not to be assigned |		| 37140-37144 | Experimental Use | Rserved, not to be assigned |
	| 31748-32767 | Private Use | Not to be assigned |		| 31748-32767 | FCFS | This range is for TLVs anf sub- |
	| 32768-49161 | Standards Action | This range is for TLVs that can |		| | | TLVs that require an error |
	| | | be silently dropped if not |		| | | message if not recognized. |
	| | | recognized. |		| 32768-49161 | Standards Action | This range is for TLVs and sub- |
	| 49162-64511 | RFC Required | This range is for TLVs that can |		| | | TLVs that can be silently |
	| | | be silently dropped if not |		| | | dropped if not recognized. |
	| | | recognized. |		| 49162-64507 | RFC Required | This range is for TLVs and sub- |
	| 64512-64515 | Experimental Use | Not to be assigned |		| | | TLVs that can be silently |
	| 64515-65535 | Private Use | Not to be assigned |		| | | dropped if not recognized. |
			| 64508-64511 | Experimental Use | Rserved, not to be assigned |
			| 64512-65535 | FCFS | This range is for TLVs and sub- |
			| | | TLVs that can be silently |
			| | | dropped if not recognized. |
	+-------------+-------------------+---------------------------------+		+-------------+-------------------+---------------------------------+
	TLV and sub-TLV Registration Procedures		TLV and sub-TLV Registration Procedures
	6.3. IANA Assignments for TLVs and sub-TLVs		6.3. IANA Assignments for TLVs and sub-TLVs
	The two tables in this section describes the updated IANA assignments		The two tables in this section describes the updated IANA assignments
	for the TLV and sub-TLV registries. The registry for sub-TLV 9		for the TLV and sub-TLV registries. The registry for sub-TLV 9
	([IANA-Sub-9] is not changed.		([IANA-Sub-9] is not changed.
	+-------------+-------------------+------------------+--------------+		Updated TLV assignments are as follows:
	| Type | TLV name | Reference | sub-TLV |
	| | | | registry |		+--------------+------------------+------------------+--------------+
	+-------------+-------------------+------------------+--------------+		| Type | TLV name | Reference | sub-TLV |
	| 0 | Reserved | This document | |		| | | | registry |
	| 1-31743 | [any] | No changes to | [any] |		+--------------+------------------+------------------+--------------+
	| | | the current | |		| 0 | Reserved | This document | |
	| | | registry | |		| 1-31739 | [any] | No changes to | [any] |
	| 37144-37147 | Reserved for | This document | NA |		| | | the current | |
	| | Experimental Use | | |		| | | registry | |
	| 31748-32767 | Reserved for | This document | NA |		| 37140-37143 | Reserved for | This document | NA |
	| | Private Use | | |		| | Experimental Use | | |
	| 32768-64511 | [any] | No changes to | [any] |		| 31744-32767 | FCFS | This document | NA |
	| | | the current | |		| 32768-64507 | [any] | No changes to | [any] |
	| | | registry. | |		| | | the current | |
	| 64512-64515 | Reserved for | This document | NA |		| | | registry. | |
	| | Experimental Use | | |		| 64508-64511 | Reserved for | This document | NA |
	| 64515-65535 | Reserved for | This document | NA |		| | Experimental Use | | |
	| | Private Use | | |		| 645152-65535 | FCFS | This document | NA |
	+-------------+-------------------+------------------+--------------+		+--------------+------------------+------------------+--------------+
	TLV Assignments		TLV Assignments
	Updated Sub-TLV assignments		Updated Sub-TLV assignments are as follows:
	+-------------+-------------------------------+---------------------+		+-------------+-------------------------------+---------------------+
	| Type | TLV name | Reference |		| Type | TLV name | Reference |
	+-------------+-------------------------------+---------------------+		+-------------+-------------------------------+---------------------+
	| 0 | Reserved | This document |		| 0 | Reserved | This document |
	| 1-31743 | [any] | No changes to the |		| 1-31739 | [any] | No changes to the |
	| | | current registry |		| | | current registry |
	| 37144-37147 | Reserved for Experimental Use | This document |		| 37140-37143 | Reserved for Experimental Use | This document |
	| 31748-32767 | Reserved for Private Use | This document |		| 31744-32767 | FCFS | This document |
	| 32768-64511 | [any] | No changes to the |		| 32768-64507 | [any] | No changes to the |
	| | | current registry. |		| | | current registry. |
	| 64512-64515 | Reserved for Experimental Use | This document |		| 64508-64511 | Reserved for Experimental Use | This document |
	| 64515-65535 | Reserved for Private Use | This document |		| 64512-65535 | FSFC | This document |
	+-------------+-------------------------------+---------------------+		+-------------+-------------------------------+---------------------+
	Sub-TLV Assignments		Sub-TLV Assignments
	7. Acknowledgements		7. Acknowledgements
	The authors wish to thank Adrian Farrel, who both made very useful		The authors wish to thank Adrian Farrel, who both made very useful
	comments and agreed to serve as the document shepherd.		comments and agreed to serve as the document shepherd.
	The authors also wish to thank Micelle Cotton who very patiently		The authors also wish to thank Micelle Cotton who very patiently
	worked with us to determine how our registries could and should be		worked with us to determine how our registries could and should be
	updated.		updated.
			The authors thanks Donald Eatlake for a careful and detailed review.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[IANA-LSP-PING]		[IANA-LSP-PING]
	"Multiprotocol Label Switching (MPLS) Label Switched Paths		"Multiprotocol Label Switching (MPLS) Label Switched Paths
	(LSPs) Ping Parameters",		(LSPs) Ping Parameters",
	<https://www.iana.org/assignments/mpls-lsp-ping-		<https://www.iana.org/assignments/mpls-lsp-ping-
	parameters/mpls-lsp-ping-parameters.xhtml/>.		parameters/mpls-lsp-ping-parameters.xhtml/>.
End of changes. 59 change blocks.
	148 lines changed or deleted		167 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/