--- 1/draft-ietf-mpls-lsp-ping-registries-update-01.txt 2020-04-16 04:15:00.366356138 -0700 +++ 2/draft-ietf-mpls-lsp-ping-registries-update-02.txt 2020-04-16 04:15:01.558391177 -0700 @@ -1,46 +1,48 @@ MPLS Working Group L. Andersson Internet-Draft Bronze Dragon Consulting Updates: 8029, 8611 (if approved) M. Chen Intended status: Standards Track Huawei Techologies -Expires: September 6, 2020 C. Pignataro +Expires: October 18, 2020 C. Pignataro Cisco Systems T. Saad Juniper Networks - March 5, 2020 + April 16, 2020 Updating the IANA MPLS LSP Ping Parameters - draft-ietf-mpls-lsp-ping-registries-update-01 + draft-ietf-mpls-lsp-ping-registries-update-02 Abstract - This document updates RFC 8029 and RFC 8611 that define IANA - registries for MPLS LSP Ping. The updates are mostly for - clarification and to align this registry with recent developments.. + This document updates RFC 8029 and RFC 8611 that both define IANA + registries for MPLS LSP Ping. It also updates the language that is + used to define the procedures for responses are sent when an unkwon + or errored code point is found. The updates are for clarification + and to align this name space with recent developments. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 6, 2020. + This Internet-Draft will expire on October 18, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -51,188 +53,148 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 2. Updating the Message Types, Reply Mode and Return Codes Registries . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Updating the TLV and sub-TLV registries . . . . . . . . . . . 4 3.1. General principles the LSP Ping TLV and sub-TLV - registries . . . . . . . . . . . . . . . . . . . . . . . 5 + registries . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Unrecognized Experimental and Private TLVs and sub- - TLVs . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.2. Changes to the LSP Ping registries . . . . . . . . . . . 6 - 3.2.1. Common changes to the TLV and sub-TLV registries . . 6 - 4. Text chages/updates to related RFCs . . . . . . . . . . . . . 7 - 4.1. Text changes to RFC 8029 . . . . . . . . . . . . . . . . 7 - 4.1.1. Comments to this changes to RFC 8029 . . . . . . . . 8 - 4.2. Text changes to RFC 8611 . . . . . . . . . . . . . . . . 8 - 4.2.1. Comments to this changes to RFC 8611 . . . . . . . . 9 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 - 6.1. New Message Type, Reply Mode and Return Codes registries 9 - 6.2. Common Registration Procedures for TLVs and sub-TLVs . . 10 - 6.3. IANA assignments for TLVs and sub-TLVs . . . . . . . . . 11 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 - 8.2. Informative References . . . . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 + TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.2. Changes to the LSP Ping Registries . . . . . . . . . . . 5 + 3.2.1. Common Changes to the TLV and sub-TLV Registries . . 5 + 4. Text Chages/Updates to Related RFCs . . . . . . . . . . . . . 6 + 4.1. Text Changes to RFC 8029 . . . . . . . . . . . . . . . . 6 + 4.2. Text Changes to RFC 8611 . . . . . . . . . . . . . . . . 7 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 6.1. Updates of Message Type, Reply Mode and Return Codes + Registries . . . . . . . . . . . . . . . . . . . . . . . 8 + 6.2. Common Registration Procedures for TLVs and sub-TLVs . . 9 + 6.3. IANA Assignments for TLVs and sub-TLVs . . . . . . . . . 9 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 8.2. Informative References . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction - When RFC 8029 [RFC8029] was published it contained among other things - updates to the "Multiprotocol Label Switching (MPLS) Label Switched - Paths (LSPs) Ping Parameters" IANA name space [IANA-LSP-PING]. + When RFC 8029 [RFC8029] was published it contained updates to the + "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) + Ping Parameters" IANA name space [IANA-LSP-PING]. RFC 8611 [RFC8611] updated the LSP Ping IANA registries to match RFC - 8029, but the registrations can be further clarified and their - definitions more precise. + 8029. This document further clarifies the entries in those + registries and makes the definitions more precise. This document updates RFC 8029 [[RFC8029] and RFC 8611 [RFC8611] by - updating two groups of registries. + updating two groups of registries as follows: First the registries for Message Types [IANA-MT], Reply Modes - [IANA-RM] and Return Codes [IANA-RC]. The changes to these - registries are minor. + [IANA-RM] and Return Codes [IANA-RC] are updated. The changes to + these registries are minor. Second, this document updates the TLV and sub-TLV registries. o TLVs [IANA-TLV-reg] o Sub-TLVs for TLVs 1, 16 and 21 [IANA-Sub-1-16-21] o Sub-TLVs for TLV 6 [IANA-Sub-6] o Sub-TLVs for TLV 11 [IANA-Sub-11] o Sub-TLVs for TLV 20 [IANA-Sub-20] o Sub-TLVs for TLV 23 [IANA-Sub-23] o Sub-TLVs for TLV 27 [IANA-Sub-27] 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 + "optional". Contrary to how other RFCs use these words, indicating + 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 + might nt be nesesary. The words "mandatory and "optional" are + dropped and the text is changed to focus on what should be doen. + 1.1. Requirement Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Updating the Message Types, Reply Mode and Return Codes Registries The following changes are made to the Message Types, Reply Modes and Return Codes [IANA-MT] registries. - o a small set of code points (4 code points) for experimental use is - added, actually they are take from the range for "Private Use". + o In the listing of assignments the term "Vendor Private 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 "RFC Required" and the note "Experimental RFC needed" is removed - o In the listing of assignments the term "Vendor Private Use" is - changed to "Private Use" - o the registration procedures "Private Use" and "Experimental Use" are added to the table of registration procedures o A note "Not to be assigned" is added for the registration procedures "Private Use" and "Experimental Use" o In the list that capture the assignment status, the fields that are reserved, i.e. 0, Private Use and Experimental Use are clearly marked. * In the Return Codes [IANA-RC] registry the code point "0" already been assigned. This assignment is not changed and this registry will not have the "0" value "Reserved". The new Registration Procedures layout and the new assignments for these registries will be found in Section 6.1. 3. Updating the TLV and sub-TLV registries - When a new LSP Ping sub-TLV registry were created by RFC 8611 - [RFC8611] this registry "Sub-TLVs for TLV Type 6" [IANA-Sub-6] was - set up following the intentions of RFC 8029. - - The registry for "Sub-TLVs for TLV Type 6" will serve as a model to - change/update the rest of the TLV and sub-TLV registries in this name - space. - - The registration procedures in the current registry for "Sub-TLVs for - TLV Type 6" looks like this (2019-06-20). This will be used as a - base-line and some additions/changes will be made as captured in the - Appendixes: - - +-------------+-------------------+---------------------------------+ - | Range | Registration | Note | - | | Procedures | | - +-------------+-------------------+---------------------------------+ - | 0-16383 | Standards Action | This range is for mandatory | - | | | TLVs or for optional TLVs that | - | | | require an error message if not | - | | | recognized. | - | 16384-31743 | RFC Required | This range is for mandatory | - | | | TLVs or for optional TLVs that | - | | | require an error message if not | - | | | recognized. | - | 31744-32767 | Private Use | Not to be assigned | - | 32768-49161 | Standards Action | This range is for optional TLVs | - | | | that can be silently dropped if | - | | | not recognized. | - | 49162-64511 | RFC Required | This range is for optional TLVs | - | | | that can be silently dropped if | - | | | not recognized. | - | 64512-65535 | Private Use | Not to be assigned | - +-------------+-------------------+---------------------------------+ - - Sub-TLVs for TLV Type 6 Registration Procedures - - This document adds small ranges of code points for Experimental Use - to this registry and to registries listed in Section 6.2. - - All registries will be changed to reflect the same model. - 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- TLV IANA registries - o all mandatory TLVs and sub-TLVs requires a response if the are not - recognized - - o some optional TLVs and sub-TLVs requires a response if the are not - recognized + o all TLVs and sub-TLVs with a typ in the the range 0-32767 require + a response if they are not recognized - o some optional TLVs and sub-TLVs may be silently dropped if the are - not recognized + o all TLVs and sub-TLVs in the range 32768-65535 may be silently + dropped if the are not recognized - The range of each TLV and sub-TLV registry is divided into to blocks, - one with a range from 0 to 49161 for TLVs and sub-TLVs that require a - response if not recognized. Another block in the range from 49161 to - 65535, this block is for TLVs and sub-TLVs that may be silently - dropped if not recognized. + The range of each TLV and sub-TLV registry is divided into wto + 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 + from 32768 to 65535, this block is for TLVs and sub-TLVs that may be + silently dropped if not recognized. - Each of the blocks have code point spaces with the following + Each of the blocks has code point spaces with the following registration procedures: o Standards Action o RFC Required o Experimental Use - o Private Use The exact defintion of registration procedures for IANA registries are found in [RFC8126] 3.1.1. Unrecognized Experimental and Private TLVs and sub-TLVs Unrecognized TLVs and sub-TLVs for Expereimetal USe and Privagte Use are handled as any other unrecognised TLV or sub-TLV. @@ -245,127 +207,111 @@ range (64512-64515) or from the Private Use range (64515-65535) the TLVs SHOULD be silently ignored. IETF does not prescribe how recognized or unrecognized Experimental 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 the private network. The statement above relates to how standard compliant implementations will treat the unrecognized TLVs and sub- 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, in - Section 6.1, Section 6.2 and Section 6.3 the changes are detailed and - it is shown what the IANA registry version of the registration - procedures and assignments would look like. + This section lists the changes to each MPLS LSP Ping Registry. + Section 6.1, Section 6.2 and Section 6.3 set out how the new versions + of the IANA registries should look, together with the registration + procedures. -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. - o two small set of code points (2 times 4 code points) for + o the registration procedures "Private Use" and "Experimental Use" + are added to the table of registration procedures + + o two small sets of code points (2 times 4 code points) for experimental use is added, actually they are take from the range for "Private Use". o the registration procedure "Specification Required" is changed to "RFC Required" and the note "Experimental RFC needed" is removed o In the listing of assignements the term "Vendor Private Use" is changed to "Private Use" o In the listing of assignments the range for "Experimental Use" is added - o the registration procedures "Private Use" and "Experimental Use" - are added to the table of registration procedures - o A note "Not to be assigned" is added for the registration procedures "Experimental Use" and "Private Use" o In the list that capture assignment status, the fields that are reserved, i.e. 0, Experimental Use and Private Use are clearly marked. The new Registration Procedures description and the new assignments for these registries will be found in Section 6.2 and Section 6.3. -4. Text chages/updates to related RFCs +4. Text Chages/Updates to Related RFCs Some referenced RFCs are using the concept "mandatory TLVs" and "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 understood, error message need to be sent in response. Since other RFCs are using "mandatory TLVs" and "mandatory sub-TLVs" - to indicate TLVs and sub-TLVs ths must be present in a message, we + 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. -4.1. Text changes to RFC 8029 - - In section 3 RFC 8029 says: - - Types less than 32768 (i.e., with the high-order bit equal to 0) - are mandatory TLVs that MUST either be 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 echo response. +4.1. Text Changes to RFC 8029 - Types greater than or equal to 32768 (i.e., with the high-order - bit equal to 1) are optional TLVs that SHOULD be ignored if the - implementation does not understand or support them. + Mandatory and optional is used in this way on page 14 and 15 in + Section 3 of RFC 8029. - This text is nows changed to: + The text in those two paragraphs are now changed to: 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 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 echo response. - TLV and sub-TLV Types greater than or equal to 32768 (i.e., with - the high-order bit equal to 1) are TLVs and sub-TLVs that SHOULD - be ignored if the implementation does not understand or support - them. - -4.1.1. Comments to this changes to RFC 8029 - - 1. RFC 8029 is a Standard Tracks RFC. Ranges 0-16383 and - 32768-49161 are assigned by Standards Action. Ranges 31744-32767 - and 49162-64511 are assigned by RFC Required, as specified e.g. - in Section 6.2 in this doucument. - - 2. The text is change in two ways + An implementation that does not understand or support a received + 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 + 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 + understood") as it would have doen if the high order bit had been + clear. - First, the ambigous use of "mandatory" and "optional" is - removed, + 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: - Second, it is clarified that both un-supported or not - recognized TLVs and sub-TLVs will generate an error message in - the Echo Reply message. + 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 + Types greater than or equal to 32768 (i.e., with the high-order + bit equal to 1) are iether nor supported by the implementation or + parsed and found to be in error. - 3. The name of the TLV used in the Echo Reply message is "TLV not - understood", however it applies equally to sub-TLVs. If a sub- - TLV is not understood or supported, the entire TLV that includes - the sub-TLV is returned. + The Value field contains the TLVs, including sub-TLVs, that were + not understood, encoded as sub-TLVs. -4.2. Text changes to RFC 8611 +4.2. Text Changes to RFC 8611 - RFC 8611 defines a sub-TLV registry - "Sub-TLVs for TLV Type 6". The - allocation policies for this registry is described in Section 3 of - this document. The "Sub-TLVs for TLV Type 6" registry is now updated - to align with changes defined in this document. + The "Sub-TLVs for TLV Type 6" registry is now updated to align with + changes defined in this document. - The registration procedurs for the "Sub-TLVs for TLV Type 6" registry - will now be like this: + The registration procedures for the "Sub-TLVs for TLV Type 6" + registry will now be like this: +-------------+-------------------+---------------------------------+ | Range | Registration | Note | | | Procedures | | +-------------+-------------------+---------------------------------+ | 0-16383 | Standards Action | This range is for sub-TLVs that | | | | require an error message if not | | | | recognized. | | 16384-31743 | RFC Required | This range is for sub-TLVs that | | | | require an error message if not | @@ -375,44 +321,41 @@ | | | can be silently dropped if not | | | | recognized. | | 49162-64511 | RFC Required | This range is for sub-TLVs that | | | | can be silently dropped if not | | | | recognized. | | 64512-65535 | Private Use | Not to be assigned | +-------------+-------------------+---------------------------------+ Sub-TLVs for TLV Type 6 Registration Procedures -4.2.1. Comments to this changes to RFC 8611 - - While it is true that the same rules apply to sub-TLVs and TLVs when - it comes tu return am error message if a TLV or sub-TLV is not - recognized. In the case if the registry for "Sub-TLVs for TLV Type 6 - Registration Procedures" ir only includes sub-TLVs. - - The changes described in this section aligns RFC 8611 with the - changes/updates described in the rest of this document. - 5. Security Considerations - This document only updates IANA registries, not how the code-points - in the registries are used. This should not create any new threats. + This document updates IANA registries, some terminology used to + define, and clarifies the terminology related to the code points in + the registries. The document does not change how the code-points in + the registries are used. This should not create any new threats. + + However, the updated terminology and the clarifications improve + security because it makes it more likely that implementations will be + consistent and harder to attack. 6. IANA Considerations IANA is requested to update the LSP Ping name space as described in - this document and documented in the Appendixies. + this document. -6.1. New 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 for Message - Type, Reply Mode and Return Codes registries. + This section details the updated registration procedures and + allocations for: Message Type, Reply Mode and Return Codes + registries. +---------+--------------------+------------------------------------+ | Range | Registration | Note | | | Procedures | | +---------+--------------------+------------------------------------+ | 0-191 | Standards Action | | | 192-247 | RFC Required | | | 248-251 | Experimental Use | Not to be assigned | | 252-255 | Private Use | Not to be assigned | +---------+--------------------+------------------------------------+ @@ -466,21 +409,21 @@ | | | recognized. | | 49162-64511 | RFC Required | This range is for TLVs that can | | | | be silently dropped if not | | | | recognized. | | 64512-64515 | Experimental Use | Not to be assigned | | 64515-65535 | Private Use | Not to be assigned | +-------------+-------------------+---------------------------------+ 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 for the TLV and sub-TLV registries. The registry for sub-TLV 9 ([IANA-Sub-9] is not changed. +-------------+-------------------+------------------+--------------+ | Type | TLV name | Reference | sub-TLV | | | | | registry | +-------------+-------------------+------------------+--------------+ | 0 | Reserved | This document | |