MPLS Working Group L. Andersson Internet-Draft Bronze Dragon Consulting Intended status: Standards Track November 2, 2020 Expires: May 6, 2021 MPLS IANA Registries Structure draft-andersson-mpls-iana-registries-structure-00 Abstract The structure of the MPLS IANA registries is not entirely intuitive. This document proposes a clarification. The intention is to make a structure that is implicit in the MPLS IANA registries clearly visible. This document does not change any RFC, nor are the content of any registry touched. 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 May 6, 2021. 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Andersson Expires May 6, 2021 [Page 1] Internet-Draft MPLS IANA registries November 2020 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 2 1.2. Terminology Used in this Document . . . . . . . . . . . . 2 2. MPLS IANA Registry Structure . . . . . . . . . . . . . . . . 3 2.1. Lack of Structure . . . . . . . . . . . . . . . . . . . . 3 2.2. Implicit Structure . . . . . . . . . . . . . . . . . . . 4 2.3. Structure made Explicit . . . . . . . . . . . . . . . . . 5 3. Multiprotocol Label Switching Architecture (MPLS) . . . . . . 5 4. Comments on Section 3 . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction This document describes a re-organization of the IANA web pages that hold the MPLS IANA registries [MPLS-code-points]. The intent is to make the structure of the MPLS IANA registries clearer, and registries and code points easier to find. 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. 1.2. Terminology Used in this Document This document uses some terms that relates to IANA registries in this way: Top Level Registry E.g. the entry to the MPLS IANA registries [MPLS-code-points] as captured on the main IANA web page [IANA-prot-reg]. Note: It might be that we want to call the IANA Protocol Registry "Top Level", in which case we call this level "First Level Registry". Andersson Expires May 6, 2021 [Page 2] Internet-Draft MPLS IANA registries November 2020 IANA Name Space, a name space is an optional grouping immediately below top level registry. An example could be "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" [IANA-LSP-PING]. A name space is most often a container for registries that hold code points that share some affinity. IANA Registry, an IANA registry holds code points, and lists the registration procedures and allocation of code points these code points. One example would be the "TLVs" registry [IANA-TLV-reg]. IANA Sub-registry, a sub-registry is used when a code point allocated in a registry needs code points scoped by that or a set of code points. An example of a sub-registry that holds code points for more than one TLV is "Sub-TLVs for TLV Types 1, 16, and 21" [IANA-Sub-1-16-21] RFC 8126 [RFC8126] discusses the terminology used to describe different level registries, but in Section 2.1. also say "Regardless of the terminology used, ... related registries (should) be grouped together". This leaves us some freedom when it comes the terminology, however if we converge on a terminology it will be used for this document. It is not the intent of this document to change registry names and/or structure in such a way that that the "IANA Consideration" sections of any RFCs need to be updated. 2. MPLS IANA Registry Structure 2.1. Lack of Structure On the main IANA web page "Protocol Registries" [IANA-prot-reg] there one header for MPLS code points "Multiprotocol Label Switching Architecture (MPLS)" [MPLS-arch]. MPLS registries (name spaces and sub-registries excluded) are listed under this heading alphabetically. "Guidelines for Writing an IANA Considerations Section in RFCs" section 2.1 [RFC8126] stresses "... document authors should pay attention to the registry groupings, should request that related registries be grouped together to make related registries easier to find, and, when creating a new registry, should check whether that registry might best be included in an existing group." Andersson Expires May 6, 2021 [Page 3] Internet-Draft MPLS IANA registries November 2020 The listing under "Multiprotocol Label Switching Architecture (MPLS)" does not seem to consider which registries and code points that should be grouped together. Nor does "alphabetic order" supply enough of grouping. 2.2. Implicit Structure However, just by scratching a little bit on what actually is there in the MPLS IANA registries, it becomes clear that there is an intended (but not immediately visible) structure. For example, starting on the MPLS IANA main page clicking on the "G-ACh Advertisement Protocol Application Registry" [G-ACh-prot-adv] and a page with the title "Generic Associated Channel (G-ACh) Parameters" will show up. This page very neatly lists all the registries that are related to the G-ACh. This seems to be a good way to group registries that belong together on the same page. Like wise, starting on the MPLS IANA main page clicking on the "TLVs" [TLVs] and a page with the title "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" will show up. This page lists all the registries that are related to LSP Ping. Actually there are five such pages forming a good structure for the MPLS IANA registries. Those pages are: o G-ACh Advertisement Protocol Application Registry Listing all code points that relates to the Generic Associated Channel. o MPLS Multi-Topology Identifiers Listing all code points that relates to MPLS Multi-Topology. o Multiprotocol Label Switching Architecture (MPLS) Identifier Types Listing all code points that relates to ITU-T Q.Recommendations. o Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters Listing all code points that relates to the LSP Ping protocol. o Special-Purpose Multiprotocol Label Switching (MPLS) Label Values Listing all code points that relates to the Special Purpose Labels. Andersson Expires May 6, 2021 [Page 4] Internet-Draft MPLS IANA registries November 2020 2.3. Structure made Explicit What is needed to meet the criteria in RFC 8126 [RFC8126] section 2.1. "... related registries (should) be grouped together to make related registries easier to find", is to make the existing structure visible from the main IANA webpage. Section 3 "Multiprotocol Label Switching Architecture (MPLS)" in this document outlines this explicit or "made visible" structure. Section 3 is "clean", i.e. there is nothing but the text that should show up on the main IANA web page. All comments has been deferred to Section 4 3. Multiprotocol Label Switching Architecture (MPLS) o Generic Associated Channel (G-ACh) Parameters * MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types) * G-ACh Advertisement Protocol Application Registry * G-ACh Advertisement Protocol: GAP TLV Objects (Application ID 0) * G-ACh Advertisement Protocol: Ethernet Interface Parameters * CC/CV MEP-ID TLV Registry * Measurement Timestamp Type * Loss/Delay Measurement Control Code: Query Codes * Loss/Delay Measurement Control Code: Response Codes * MPLS Loss/Delay Measurement TLV Object * MPLS Fault OAM Message Type Registry * MPLS Fault OAM Flag Registry * MPLS Fault OAM TLV Registry * MPLS PSC Request Registry * MPLS PSC TLV Registry * MPLS PSC Capability Flag Registry Andersson Expires May 6, 2021 [Page 5] Internet-Draft MPLS IANA registries November 2020 * MPLS RTM TLV Registry + MPLS RTM Sub-TLV Registry * MPLS-TP DHC TLVs * MPLS RPS Request Code Registry o MPLS Multi-Topology Identifiers * MPLS Multi-Topology Identifiers o Multiprotocol Label Switching Architecture (MPLS) Identifier Types * Information Field and Protocol Identifier in the Q.2941 Generic Identifier * Q.2957 User-to-user Signaling for the Internet Protocol o Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters * Message Types * Reply Modes * Return Codes * TLVs + Sub-TLVs for TLV Types 1, 16, and 21 + Sub-TLVs for TLV Type 6 + Sub-TLVs for TLV Type 9 + Sub-TLVs for TLV Type 11 + Sub-TLVs for TLV Type 20 + Sub-TLVs for TLV Type 23 + Sub-TLVs for TLV Type 27 * Measurement Timestamp Type * Loss/Delay Measurement Control Code: Query Codes Andersson Expires May 6, 2021 [Page 6] Internet-Draft MPLS IANA registries November 2020 * Loss/Delay Measurement Control Code: Response Codes * MPLS Loss/Delay Measurement TLV Object * Global Flags * Downstream Detailed Mapping Address Type Registry * Next Hop Address Type Registry * Reply Path Return Codes * DS Flags * Multipath Types * Pad Types * Interface and Label Stack and Detailed Interface and Label Stack Address Types * Proxy Flags * MPLS OAM Function Flags * Protocol in the Segment ID sub-TLV * Adjacency Type in the IGP-Adjacency Segment ID * Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV * LSR Capability Flags * Interface Index Flags o Special-Purpose Multiprotocol Label Switching (MPLS) Label Values * Special-Purpose MPLS Label Values * Extended Special-Purpose MPLS Label Values 4. Comments on Section 3 In Section 3 the section header matches the top level entry for MPLS code points "Multiprotocol Label Switching Architecture (MPLS)" [MPLS-arch] on the main IANA web page "Protocol Registries" [IANA-prot-reg]. Andersson Expires May 6, 2021 [Page 7] Internet-Draft MPLS IANA registries November 2020 The five namespace entries (G-ACh, Architecture, LSP Ping, Multi- topology, and SPL are new entries to the main IANA page. The registries and sub-registries should be sorted under these new headers as shown in Section 3. Registries for sub-TLVs (sub-registries) has not normally listed on the main IANA web page for MPLS, while we see a value of having all registreis listed, we believe that listing of sub-TLV registries should be discussed carefully before it is done. see Tentatively the following structure is proposed: o Top Level Registry I.e. "Multiprotocol Label Switching Architecture (MPLS)" * Namespace E.g. "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" + Registry E.g. "TLVs" - Sub-registry E.g. "Sub-TLVs for TLV Types 1, 16, and 21" 5. Security Considerations This document updates IANA registries. It also updates 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 according to this document. The IANA consideration section to be detailed. 7. Acknowledgements TBA. Andersson Expires May 6, 2021 [Page 8] Internet-Draft MPLS IANA registries November 2020 8. References 8.1. Normative References [G-ACh-generic] "Generic Associated Channel (G-ACh) Parameters", . [G-ACh-prot-adv] "G-ACh Advertisement Protocol Application Registry", . [IANA-LSP-PING] "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters", . [IANA-prot-reg] "Protocol Registries", . [IANA-Sub-1-16-21] "Sub-TLVs for TLV Types 1, 16, and 21", . [IANA-TLV-reg] "TLVs", . [LSP-Ping] "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters", . [MPLS-arch] "Multiprotocol Label Switching Architecture (MPLS)", . [MPLS-code-points] "Multiprotocol Label Switching Architecture (MPLS)", . Andersson Expires May 6, 2021 [Page 9] Internet-Draft MPLS IANA registries November 2020 [Multi-Topology] "MPLS Multi-Topology Identifiers", . [Prot-ID] "Multiprotocol Label Switching Architecture (MPLS) Identifier Types", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [SPL-Labels] "Special-Purpose Multiprotocol Label Switching (MPLS) Label Values", . [TLVs] "TLVs", . 8.2. Informative References [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Author's Address Loa Andersson Bronze Dragon Consulting Email: loa@pi.nu Andersson Expires May 6, 2021 [Page 10]