idnits 2.17.1
draft-andersson-mpls-iana-registries-structure-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document doesn't use any RFC 2119 keywords, yet seems to have RFC
2119 boilerplate text.
-- The document date (November 2, 2020) is 1264 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Unused Reference: 'G-ACh-generic' is defined on line 388, but no
explicit reference was found in the text
== Unused Reference: 'LSP-Ping' is defined on line 417, but no explicit
reference was found in the text
== Unused Reference: 'Multi-Topology' is defined on line 431, but no
explicit reference was found in the text
== Unused Reference: 'Prot-ID' is defined on line 436, but no explicit
reference was found in the text
== Unused Reference: 'SPL-Labels' is defined on line 449, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'G-ACh-generic'
-- Possible downref: Non-RFC (?) normative reference: ref. 'G-ACh-prot-adv'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-LSP-PING'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-prot-reg'
-- Possible downref: Non-RFC (?) normative reference: ref.
'IANA-Sub-1-16-21'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-TLV-reg'
-- Possible downref: Non-RFC (?) normative reference: ref. 'LSP-Ping'
-- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-arch'
-- Possible downref: Non-RFC (?) normative reference: ref.
'MPLS-code-points'
-- Possible downref: Non-RFC (?) normative reference: ref. 'Multi-Topology'
-- Possible downref: Non-RFC (?) normative reference: ref. 'Prot-ID'
-- Possible downref: Non-RFC (?) normative reference: ref. 'SPL-Labels'
-- Possible downref: Non-RFC (?) normative reference: ref. 'TLVs'
Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 14 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 MPLS Working Group L. Andersson
3 Internet-Draft Bronze Dragon Consulting
4 Intended status: Standards Track November 2, 2020
5 Expires: May 6, 2021
7 MPLS IANA Registries Structure
8 draft-andersson-mpls-iana-registries-structure-00
10 Abstract
12 The structure of the MPLS IANA registries is not entirely intuitive.
13 This document proposes a clarification. The intention is to make a
14 structure that is implicit in the MPLS IANA registries clearly
15 visible.
17 This document does not change any RFC, nor are the content of any
18 registry touched.
20 Status of This Memo
22 This Internet-Draft is submitted in full conformance with the
23 provisions of BCP 78 and BCP 79.
25 Internet-Drafts are working documents of the Internet Engineering
26 Task Force (IETF). Note that other groups may also distribute
27 working documents as Internet-Drafts. The list of current Internet-
28 Drafts is at https://datatracker.ietf.org/drafts/current/.
30 Internet-Drafts are draft documents valid for a maximum of six months
31 and may be updated, replaced, or obsoleted by other documents at any
32 time. It is inappropriate to use Internet-Drafts as reference
33 material or to cite them other than as "work in progress."
35 This Internet-Draft will expire on May 6, 2021.
37 Copyright Notice
39 Copyright (c) 2020 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents
44 (https://trustee.ietf.org/license-info) in effect on the date of
45 publication of this document. Please review these documents
46 carefully, as they describe your rights and restrictions with respect
47 to this document. Code Components extracted from this document must
48 include Simplified BSD License text as described in Section 4.e of
49 the Trust Legal Provisions and are provided without warranty as
50 described in the Simplified BSD License.
52 Table of Contents
54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
55 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 2
56 1.2. Terminology Used in this Document . . . . . . . . . . . . 2
57 2. MPLS IANA Registry Structure . . . . . . . . . . . . . . . . 3
58 2.1. Lack of Structure . . . . . . . . . . . . . . . . . . . . 3
59 2.2. Implicit Structure . . . . . . . . . . . . . . . . . . . 4
60 2.3. Structure made Explicit . . . . . . . . . . . . . . . . . 5
61 3. Multiprotocol Label Switching Architecture (MPLS) . . . . . . 5
62 4. Comments on Section 3 . . . . . . . . . . . . . . . . . . . . 7
63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
67 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
68 8.2. Informative References . . . . . . . . . . . . . . . . . 10
69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
71 1. Introduction
73 This document describes a re-organization of the IANA web pages that
74 hold the MPLS IANA registries [MPLS-code-points]. The intent is to
75 make the structure of the MPLS IANA registries clearer, and
76 registries and code points easier to find.
78 1.1. Requirement Language
80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
82 "OPTIONAL" in this document are to be interpreted as described in BCP
83 14 [RFC2119] [RFC8174] when, and only when, they appear in all
84 capitals, as shown here.
86 1.2. Terminology Used in this Document
88 This document uses some terms that relates to IANA registries in this
89 way:
91 Top Level Registry
92 E.g. the entry to the MPLS IANA registries [MPLS-code-points] as
93 captured on the main IANA web page [IANA-prot-reg].
94 Note: It might be that we want to call the IANA Protocol Registry
95 "Top Level", in which case we call this level "First Level
96 Registry".
98 IANA Name Space,
99 a name space is an optional grouping immediately below top level
100 registry. An example could be "Multiprotocol Label Switching
101 (MPLS) Label Switched Paths (LSPs) Ping Parameters"
102 [IANA-LSP-PING]. A name space is most often a container for
103 registries that hold code points that share some affinity.
105 IANA Registry,
106 an IANA registry holds code points, and lists the registration
107 procedures and allocation of code points these code points. One
108 example would be the "TLVs" registry [IANA-TLV-reg].
110 IANA Sub-registry,
111 a sub-registry is used when a code point allocated in a registry
112 needs code points scoped by that or a set of code points. An
113 example of a sub-registry that holds code points for more than one
114 TLV is "Sub-TLVs for TLV Types 1, 16, and 21" [IANA-Sub-1-16-21]
116 RFC 8126 [RFC8126] discusses the terminology used to describe
117 different level registries, but in Section 2.1. also say "Regardless
118 of the terminology used, ... related registries (should) be grouped
119 together". This leaves us some freedom when it comes the
120 terminology, however if we converge on a terminology it will be used
121 for this document.
123 It is not the intent of this document to change registry names and/or
124 structure in such a way that that the "IANA Consideration" sections
125 of any RFCs need to be updated.
127 2. MPLS IANA Registry Structure
129 2.1. Lack of Structure
131 On the main IANA web page "Protocol Registries" [IANA-prot-reg] there
132 one header for MPLS code points
133 "Multiprotocol Label Switching Architecture (MPLS)" [MPLS-arch].
134 MPLS registries (name spaces and sub-registries excluded) are listed
135 under this heading alphabetically.
137 "Guidelines for Writing an IANA Considerations Section in RFCs"
138 section 2.1 [RFC8126] stresses
140 "... document authors should pay attention to the registry
141 groupings, should request that related registries be grouped
142 together to make related registries easier to find, and, when
143 creating a new registry, should check whether that registry might
144 best be included in an existing group."
146 The listing under "Multiprotocol Label Switching Architecture (MPLS)"
147 does not seem to consider which registries and code points that
148 should be grouped together. Nor does "alphabetic order" supply
149 enough of grouping.
151 2.2. Implicit Structure
153 However, just by scratching a little bit on what actually is there in
154 the MPLS IANA registries, it becomes clear that there is an intended
155 (but not immediately visible) structure.
157 For example, starting on the MPLS IANA main page clicking on the
158 "G-ACh Advertisement Protocol Application Registry" [G-ACh-prot-adv]
159 and a page with the title
160 "Generic Associated Channel (G-ACh) Parameters" will show up.
162 This page very neatly lists all the registries that are related to
163 the G-ACh. This seems to be a good way to group registries that
164 belong together on the same page.
166 Like wise, starting on the MPLS IANA main page clicking on the "TLVs"
167 [TLVs] and a page with the title "Multiprotocol Label Switching
168 (MPLS) Label Switched Paths (LSPs) Ping Parameters" will show up.
170 This page lists all the registries that are related to LSP Ping.
172 Actually there are five such pages forming a good structure for the
173 MPLS IANA registries. Those pages are:
175 o G-ACh Advertisement Protocol Application Registry
176 Listing all code points that relates to the Generic Associated
177 Channel.
179 o MPLS Multi-Topology Identifiers
180 Listing all code points that relates to MPLS Multi-Topology.
182 o Multiprotocol Label Switching Architecture (MPLS) Identifier Types
183 Listing all code points that relates to ITU-T Q.Recommendations.
185 o Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
186 Ping Parameters
187 Listing all code points that relates to the LSP Ping protocol.
189 o Special-Purpose Multiprotocol Label Switching (MPLS) Label Values
190 Listing all code points that relates to the Special Purpose
191 Labels.
193 2.3. Structure made Explicit
195 What is needed to meet the criteria in RFC 8126 [RFC8126] section
196 2.1. "... related registries (should) be grouped together to make
197 related registries easier to find", is to make the existing structure
198 visible from the main IANA webpage.
200 Section 3 "Multiprotocol Label Switching Architecture (MPLS)" in this
201 document outlines this explicit or "made visible" structure.
202 Section 3 is "clean", i.e. there is nothing but the text that should
203 show up on the main IANA web page. All comments has been deferred to
204 Section 4
206 3. Multiprotocol Label Switching Architecture (MPLS)
208 o Generic Associated Channel (G-ACh) Parameters
210 * MPLS Generalized Associated Channel (G-ACh) Types (including
211 Pseudowire Associated Channel Types)
213 * G-ACh Advertisement Protocol Application Registry
215 * G-ACh Advertisement Protocol: GAP TLV Objects (Application ID
216 0)
218 * G-ACh Advertisement Protocol: Ethernet Interface Parameters
220 * CC/CV MEP-ID TLV Registry
222 * Measurement Timestamp Type
224 * Loss/Delay Measurement Control Code: Query Codes
226 * Loss/Delay Measurement Control Code: Response Codes
228 * MPLS Loss/Delay Measurement TLV Object
230 * MPLS Fault OAM Message Type Registry
232 * MPLS Fault OAM Flag Registry
234 * MPLS Fault OAM TLV Registry
236 * MPLS PSC Request Registry
238 * MPLS PSC TLV Registry
240 * MPLS PSC Capability Flag Registry
241 * MPLS RTM TLV Registry
243 + MPLS RTM Sub-TLV Registry
245 * MPLS-TP DHC TLVs
247 * MPLS RPS Request Code Registry
249 o MPLS Multi-Topology Identifiers
251 * MPLS Multi-Topology Identifiers
253 o Multiprotocol Label Switching Architecture (MPLS) Identifier Types
255 * Information Field and Protocol Identifier in the Q.2941 Generic
256 Identifier
258 * Q.2957 User-to-user Signaling for the Internet Protocol
260 o Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
261 Ping Parameters
263 * Message Types
265 * Reply Modes
267 * Return Codes
269 * TLVs
271 + Sub-TLVs for TLV Types 1, 16, and 21
273 + Sub-TLVs for TLV Type 6
275 + Sub-TLVs for TLV Type 9
277 + Sub-TLVs for TLV Type 11
279 + Sub-TLVs for TLV Type 20
281 + Sub-TLVs for TLV Type 23
283 + Sub-TLVs for TLV Type 27
285 * Measurement Timestamp Type
287 * Loss/Delay Measurement Control Code: Query Codes
288 * Loss/Delay Measurement Control Code: Response Codes
290 * MPLS Loss/Delay Measurement TLV Object
292 * Global Flags
294 * Downstream Detailed Mapping Address Type Registry
296 * Next Hop Address Type Registry
298 * Reply Path Return Codes
300 * DS Flags
302 * Multipath Types
304 * Pad Types
306 * Interface and Label Stack and Detailed Interface and Label
307 Stack Address Types
309 * Proxy Flags
311 * MPLS OAM Function Flags
313 * Protocol in the Segment ID sub-TLV
315 * Adjacency Type in the IGP-Adjacency Segment ID
317 * Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping
318 TLV
320 * LSR Capability Flags
322 * Interface Index Flags
324 o Special-Purpose Multiprotocol Label Switching (MPLS) Label Values
326 * Special-Purpose MPLS Label Values
328 * Extended Special-Purpose MPLS Label Values
330 4. Comments on Section 3
332 In Section 3 the section header matches the top level entry for MPLS
333 code points "Multiprotocol Label Switching Architecture (MPLS)"
334 [MPLS-arch] on the main IANA web page "Protocol Registries"
335 [IANA-prot-reg].
337 The five namespace entries (G-ACh, Architecture, LSP Ping, Multi-
338 topology, and SPL are new entries to the main IANA page. The
339 registries and sub-registries should be sorted under these new
340 headers as shown in Section 3.
342 Registries for sub-TLVs (sub-registries) has not normally listed on
343 the main IANA web page for MPLS, while we see a value of having all
344 registreis listed, we believe that listing of sub-TLV registries
345 should be discussed carefully before it is done. see
347 Tentatively the following structure is proposed:
349 o Top Level Registry
350 I.e. "Multiprotocol Label Switching Architecture (MPLS)"
352 * Namespace
353 E.g. "Multiprotocol Label Switching (MPLS) Label Switched
354 Paths (LSPs) Ping Parameters"
356 + Registry
357 E.g. "TLVs"
359 - Sub-registry
360 E.g. "Sub-TLVs for TLV Types 1, 16, and 21"
362 5. Security Considerations
364 This document updates IANA registries. It also updates terminology
365 used to define, and clarifies the terminology related to, the code
366 points in the registries. The document does not change how the code-
367 points in the registries are used. This should not create any new
368 threats.
370 However, the updated terminology and the clarifications improve
371 security because it makes it more likely that implementations will be
372 consistent and harder to attack.
374 6. IANA Considerations
376 IANA is requested to update the according to this document.
378 The IANA consideration section to be detailed.
380 7. Acknowledgements
382 TBA.
384 8. References
386 8.1. Normative References
388 [G-ACh-generic]
389 "Generic Associated Channel (G-ACh) Parameters",
390 .
393 [G-ACh-prot-adv]
394 "G-ACh Advertisement Protocol Application Registry",
395 .
398 [IANA-LSP-PING]
399 "Multiprotocol Label Switching (MPLS) Label Switched Paths
400 (LSPs) Ping Parameters",
401 .
404 [IANA-prot-reg]
405 "Protocol Registries", .
407 [IANA-Sub-1-16-21]
408 "Sub-TLVs for TLV Types 1, 16, and 21",
409 .
413 [IANA-TLV-reg]
414 "TLVs", .
417 [LSP-Ping]
418 "Multiprotocol Label Switching (MPLS) Label Switched Paths
419 (LSPs) Ping Parameters",
420 .
423 [MPLS-arch]
424 "Multiprotocol Label Switching Architecture (MPLS)",
425 .
427 [MPLS-code-points]
428 "Multiprotocol Label Switching Architecture (MPLS)",
429 .
431 [Multi-Topology]
432 "MPLS Multi-Topology Identifiers",
433 .
436 [Prot-ID] "Multiprotocol Label Switching Architecture (MPLS)
437 Identifier Types", .
440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
441 Requirement Levels", BCP 14, RFC 2119,
442 DOI 10.17487/RFC2119, March 1997,
443 .
445 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
446 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
447 May 2017, .
449 [SPL-Labels]
450 "Special-Purpose Multiprotocol Label Switching (MPLS)
451 Label Values", .
454 [TLVs] "TLVs", .
457 8.2. Informative References
459 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
460 Writing an IANA Considerations Section in RFCs", BCP 26,
461 RFC 8126, DOI 10.17487/RFC8126, June 2017,
462 .
464 Author's Address
466 Loa Andersson
467 Bronze Dragon Consulting
469 Email: loa@pi.nu