idnits 2.17.1 draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4379, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4379, updated by this document, for RFC5378 checks: 2002-03-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 30, 2013) is 4013 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) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 6424 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 6829 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Andersson 3 Internet-Draft M. Chen 4 Updates: 4379 (if approved) Huawei 5 Intended status: Standards Track T. Petch 6 Expires: November 01, 2013 Engineering Networks Ltd 7 April 30, 2013 9 "MPLS LSP Ping TLVs and sub-TLVs registry" 10 draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02.txt 12 Abstract 14 This document addresses issues with the structure, allocation 15 policies and clarity in the use of the "TLVs and sub-TLVs" of the 16 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 17 Ping Parameters" in the "Multiprotocol Label Switching Architecture 18 (MPLS)" name space. 20 This document does not change any existing allocations and the new 21 structure is backwards compatible with the existing registries. 23 The policy for the allocation of TLVs is unchanged but future 24 allocations of sub-TLVs will come from a single namespace, common to 25 all TLVs of LSP Ping Parameters. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 01, 2013. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Current situation . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Current situation - model . . . . . . . . . . . . . . . . 3 70 2.2. Allocation policies and Scope . . . . . . . . . . . . . . 4 71 2.3. A closer look at the model . . . . . . . . . . . . . . . 5 72 3. New registry structure . . . . . . . . . . . . . . . . . . . 6 73 3.1. If we'd done it from start . . . . . . . . . . . . . . . 7 74 3.2. TLV Registry and allocation procedures . . . . . . . . . 8 75 3.3. Sub-TLV registries and allocation policies . . . . . . . 9 76 3.3.1. Sub-TLV registry for all TLVs . . . . . . . . . . . . 10 77 3.3.2. Sub TLV registry for TLV Type 9 . . . . . . . . . . . 12 78 3.3.3. Sub TLV registry for TLV Type 11 . . . . . . . . . . 13 79 3.3.4. Sub TLV registry for TLV Type 20 . . . . . . . . . . 14 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 82 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 85 7.2. Informative references . . . . . . . . . . . . . . . . . 16 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 88 1. Introduction 90 This document revises the allocation policies in the use of the TLVs 91 and sub-TLVs of the MPLS LSP Ping Parameters, as defined in 92 [RFC4379]. 94 This document does not change any existing allocations and the new 95 structure is backwards compatible with the existing registries. 97 The policy for the allocation of TLVs is unchanged but future 98 allocations of sub-TLVs will come from a single namespace, common to 99 all TLVs of MPLS LSP Ping Parameters. 101 The allocation of existing sub-TLVs is unaltered, so that the meaning 102 of, e.g., sub-TLV sub-Type 1 is dependent on the TLV under which it 103 appears. No future allocations will be made with a sub-Type of less 104 than 32. Future allocations will be made from a single namespace 105 starting at 32; a sub-TLV defined in this way may appear as part of 106 any current or future TLV. The document that specifies such an 107 allocation should state which TLVs the sub-TLV may appear under and 108 indicate any other future use which seems appropriate or 109 inappropriate. 111 2. Current situation 113 Today all TLVs and sub-TLVs are found in a single table, and the 114 allocation policies are the same for all TLVs and sub-TLVs. The 115 table below illustrates how the registry is set up. 117 Initially this might have been a good idea, but over time, with an 118 increasing number of TLVs, and with some sub-TLVs shared across TLVs, 119 it has become increasingly difficult to understand how the allocation 120 policies interact. 122 2.1. Current situation - model 124 The table below illustrates how the registry is set up and the 125 allocation policies work currently. We have chosen not to just copy 126 the current registry here, but instead build a model that shows how 127 the allocation policies work. 129 --Note to RFC Editor; the various RFC aaaa to RFC zzzz are really 130 meant to be like that in the finished document; we are not asking you 131 to replace them with anything:-) 133 Current TLV and sub-TLV registry (model) 135 Type Sub-type Value field Reference 136 +------+----------+---------------------------+----------------+ 137 1 | | TLV # 1 | RFC xxxx (1) 138 1 | 1 | sub-TLV # 1 | RFC xxxx (2) 139 1 | 2 | sub-TLV # 2 | RFC yyyy (3) 140 1 | 3 | sub-TLV # 3 | RFC yyyy (4) 141 2 | | TLV # 2 | RFC xxxx (5) 142 3 | | TLV # 3 | RFC zzzz (6) 143 3 | 1 | sub-TLV # 1 | RFC zzzz (7) 144 3 | 2 | sub-TLV # 2 | RFC zzzz (8) 145 3 | 3 | sub-TLV # 3 | RFC aaaa (9) 146 4 | | TLV # 4 | RFC bbbb (10) 147 4 | 1-16383 | as specified for type 1 | RFC bbbb (11) 148 5 | | TLV # 5 | RFC cccc (12) 149 5 | 1-65535 | as specified for type 1 | RFC cccc (13) 151 Note: The row number column to the right is added here to discuss 152 what is on the different rows. 154 2.2. Allocation policies and Scope 156 TLV and sub-TLV registration procedures 158 Range | Registration Procedures| Notes 159 -------------+------------------------+------------------------------ 160 0-16383 | Standards Action | This range is for mandatory 161 | | TLVs or for optional TLVs 162 | | that require an error message 163 | | if not recognized. 164 -------------+------------------------+------------------------------ 165 16384-31743 | Specification Required | Experimental RFC needed 166 -------------+------------------------+------------------------------ 167 31744-32767 | Vendor Private Use | MUST NOT be allocated 168 -------------+------------------------+------------------------------ 169 32768-49161 | Standards Action | This range is for optional 170 | | TLVs that can be silently 171 | | dropped if not recognized. 172 -------------+------------------------+------------------------------ 173 49162-64511 | Specification Required | Experimental RFC needed 174 -------------+------------------------+------------------------------ 175 64512-65535 | Vendor Private Use | MUST NOT be allocated 176 -------------+------------------------+------------------------------ 178 The IANA registry does not give enough information to correctly 179 allocate TLVs and sub-TLVs, instead careful reading of [RFC4379] is 180 necessary. 182 [RFC4379] says: 184 The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the 185 range 0-16383 and 32768-49161 are made via Standards Action as 186 defined in Section 5; assignments in the range 16384-31743 and 187 49162-64511 are made via "Specification Required" as defined above; 188 values in the range 31744-32767 and 64512-65535 are for Vendor 189 Private Use, and MUST NOT be allocated. 191 [RFC4379] also says that the sub-TLVs are scoped by the TLVs, i.e. a 192 sub-TLV defined for one TLV is valid for that TLV only. Later the 193 practice to re-define (a block of) sub-TLVs defined for one TLV for 194 another TLV was introduced. 196 2.3. A closer look at the model 198 The list below contains what we see as the results of the most common 199 allocation requests for this registry. 201 1. Row 1 says that IANA has allocated a TLV as requested in 202 RFCxxxx. This TLV is type 1. 204 RFCxxxx is the document that defines the registry and sets up 205 the allocation policies. 207 2. Row 2 says that IANA has allocated a sub-TLV for TLV type 1, 208 "sub-TLV #1", the source for this allocation is the same that 209 defined the registry and allocated the TLV Type 1 (RFCxxxx). 211 3. Row 3 says that IANA has allocated a second sub-TLV (sub-TLV #2) 212 for TLV type 1, the source for this allocation is RFCyyyy. 214 - 216 4. Row 4 says that IANA has allocated a third sub-TLV (sub-TLV #3) 217 for TLV type 1, the source for this allocation is RFCyyyy. 219 - 221 5. Row 5 says that IANA has allocated a new TLV (TLV type 2), the 222 source for this allocation is RFCxxxx, the same RFC that defined 223 the registry. 225 TLV type 2 has no sub-TLVs yet defined. 227 6. Row 6 says that IANA has allocated a new TLV (TLV type 3), the 228 source for this allocation is RFCzzzz. 230 - 232 7. Row 7 says that IANA has allocated a sub-TLV (sub-TLV # 1) for 233 TLV type 3, the source for this allocation is RFCzzzz. 235 This means that we have one sub-TLV # 1 for TLV type 1, and 236 another sub-TLV # 1 for TLV type 3. In itself this is not a 237 problem, the sub-TLVs are scoped by the TLVs. 239 8. Row 8 says that IANA has allocated a sub-TLV (sub-TLV # 2) for 240 TLV type 3, the source for this allocation is RFCzzzz. 242 - 244 9. Row 9 says that IANA has allocated a sub-TLV (sub-TLV # 2) for 245 TLV type 3, the source for this allocation is RFCaaaa. 247 - 249 10. Row 10 says that IANA has allocated a new TLV (TLV type 4), the 250 source for this allocation is RFCbbbb. 252 - 254 11. Row 11 says that IANA has been instructed not to allocate any 255 sub-TLVs from the range 1-16383, but that the sub-TLVs for TLV 256 type 4, shall use the same sub-TLVs that have been specified for 257 TLV type 1 in this range. 259 This implies that other ranges for TLV type 4 are open for 260 allocation for "TLV type 4 specific sub-TLVs". This is 261 specified in RFCbbbb. 263 12. Row 12 says that IANA has allocated a new TLV (TLV type 5), the 264 source for this allocation is RFCcccc. 266 - 268 13. Row 13 says that IANA has been instructed not to allocate any 269 sub-TLVs from the entire range (1-65535), but that the sub-TLVs 270 for TLV type 5, shall use the same sub-TLVs that have been 271 specified for TLV type 1. This is specified in RFCcccc. 273 Close reading of the allocation rules would likely show that 274 disallowing the assignment of vendor-specific sub-TLVs is moot. 276 3. New registry structure 277 3.1. If we'd done it from start 279 The name space of sub-TLVs is very large, 65 535 potential TLVs times 280 65 535 sub-TLVs per TLV, gives a maximum of 4 294 836 335 sub- TLVs. 282 There seems no reason why that number of sub-TLVs should be needed; 283 rather, 65 535 sub-TLVs shared among all TLVs would seem to have been 284 more than sufficient. If the IANA registries had been set up with 285 one registry for TLVs and another for sub-TLVs, that would have 286 resulted in registries and allocation policies much easier to 287 understand and comprehend. 289 In practice, the same sub-TLV number appears more than once under 290 different TLVs with a different meaning on each occasion. Thus sub- 291 TLV 1 appears under TLV Type 1 as LDP IPv4 Prefix, under TLV Type 11 292 as IPv4 Egress Address P2MP Responder and under TLV Type 20 as 293 Multipath data. At the same time, TLVs Types 16 and 21 reuse sub-TLV 294 1 with the same meaning as for TLV Type 1. 296 Thus it is now impossible to create a single registry for sub-TLVs 297 which encompasses all existing sub-TLVs. At the same time, such a 298 registry would simplify future registration and use, allowing, for 299 example, a sub-TLV to be defined for an IPv6 address that would then 300 be used wherever such an address is required. Hence, the future 301 policy for the registration of sub-TLVs is to have a single registry 302 regardless of which TLV the sub-TLV appears under. This registry 303 follows the same pattern as the existing registries, namely of 305 0-16383 | Standards Action | Mandatory (sub)TLVs 306 -------------+------------------------+-------------------------- 307 16384-31743 | Specification Required | Mandatory Experimental 308 | | RFC needed 309 -------------+------------------------+-------------------------- 310 31744-32767 | Vendor Private Use | MUST NOT be allocated 311 -------------+------------------------+-------------------------- 312 32768-49161 | Standards Action | Optional (sub)TLVs 313 -------------+------------------------+-------------------------- 314 49162-64511 | Specification Required | Optional Experimental 315 | | RFC needed 316 -------------+------------------------+-------------------------- 317 64512-65535 | Vendor Private Use | MUST NOT be allocated 318 -------------+------------------------+-------------------------- 320 excepting that the range 0 to 31 is now reserved and MUST NOT be 321 assigned lest there is an overlap with existing definitions. The 322 choice of 32 is somewhat greater than the greatest, existing, defined 323 sub-TLV, 25 for TLV Type 1, and is chosen to be a more user-friendly, 324 easier to remember, number than, say, 26 or 29. 326 The examples in TLV Registry and allocation procedures (Section 3.2) 327 and Sub-TLV registries and allocation policies (Section 3.3) are the 328 actual allocations in the IANA registry as they are found at the time 329 of writing of this document (January 2013). 331 3.2. TLV Registry and allocation procedures 333 TLV registration procedures 335 Range | Registration Procedures| Notes 336 -------------+------------------------+------------------------------ 337 0-16383 | Standards Action | This range is for mandatory 338 | | TLVs or for optional TLVs 339 | | that require an error message 340 | | if not recognized. 341 -------------+------------------------+------------------------------ 342 16384-31743 | Specification Required | Experimental RFC needed 343 | | This range is for mandatory 344 | | TLVs or for optional TLVs 345 | | that require an error message 346 | | if not recognized. 347 -------------+------------------------+------------------------------ 348 31744-32767 | Vendor Private Use | MUST NOT be allocated 349 -------------+------------------------+------------------------------ 350 32768-49161 | Standards Action | This range is for optional 351 | | TLVs that can be silently 352 | | discarded if not recognized. 353 -------------+------------------------+------------------------------ 354 49162-64511 | Specification Required | Experimental RFC needed 355 | | This range is for optional 356 | | TLVs that can be silently 357 | | discarded if not recognized. 358 -------------+------------------------+------------------------------ 359 64512-65535 | Vendor Private Use | MUST NOT be allocated 360 -------------+------------------------+------------------------------ 362 LSP Ping TLV Registry 364 Type | Value Field | Reference 365 --------------+------------------------------+--------------------- 366 1 | Target FEC Stack | [RFC4379] 367 --------------+------------------------------+--------------------- 368 2 | Downstream Mapping | [RFC4379] 369 | (DEPRECATED) | [RFC6424] 371 --------------+------------------------------+--------------------- 372 3 | Pad | [RFC4379] 373 --------------+------------------------------+--------------------- 374 4 | Not Assigned | [RFC4379] 375 --------------+------------------------------+--------------------- 376 5 | Vendor Enterprise Number | [RFC4379] 377 --------------+------------------------------+--------------------- 378 6 | Not Assigned | [RFC4379] 379 --------------+------------------------------+--------------------- 380 7 | Interface and Label Stack | [RFC4379] 381 --------------+------------------------------+--------------------- 382 8 | Not Assigned | [RFC4379] 383 --------------+------------------------------+--------------------- 384 9 | Errored TLVs | [RFC4379] 385 --------------+------------------------------+--------------------- 386 10 | Reply TOS Byte | [RFC4379] 387 --------------+------------------------------+--------------------- 388 11 | P2MP Responder Identifier | [RFC6425] 389 --------------+------------------------------+--------------------- 390 12 | Echo Jitter | [RFC6425] 391 --------------+------------------------------+--------------------- 392 13 | Source ID | [RFC6426] 393 --------------+------------------------------+--------------------- 394 14 | Destination ID | [RFC6426] 395 --------------+------------------------------+--------------------- 396 15 | BFD Discriminator | [RFC5884] 397 --------------+------------------------------+--------------------- 398 16 | Reverse-path Target FEC Stack| [RFC6426] 399 --------------+------------------------------+--------------------- 400 17-19 | Unassigned | 401 --------------+------------------------------+--------------------- 402 20 | Downstream Detailed Mapping | [RFC6424] 403 --------------+------------------------------+--------------------- 404 22-31743 | Unassigned | 405 --------------+------------------------------+--------------------- 406 31744-32767 | Reserved for Vendor | [RFC4379] 407 | private use | 408 --------------+------------------------------+--------------------- 409 32768-64511 | Unassigned | 410 --------------+------------------------------+--------------------- 411 64512-65535 | Reserved for Vendor | [RFC4379] 412 | private use | 413 --------------+------------------------------+--------------------- 415 3.3. Sub-TLV registries and allocation policies 416 3.3.1. Sub-TLV registry for all TLVs 418 Registration procedures for all sub-TLVs 420 Range | Registration Procedures| Notes 421 ------------+------------------------+------------------------------ 422 0-31 | Reserved | Existing allocations in this 423 | | range are unaltered. 424 | | No future allocations are 425 | | to be made from this range. 426 ------------+------------------------+------------------------------ 427 32-16383 | Standards Action | This range is for mandatory 428 | | sub-TLVs or for optional 429 | | sub-TLVs that require an 430 | | error message if not 431 | | recognized. 432 ------------+------------------------+------------------------------ 433 16384-31743 | Specification Required | Experimental RFC needed 434 | | This range is for mandatory 435 | | sub-TLVs or for optional 436 | | sub-TLVs that require an 437 | | error message if not 438 | | recognized. 439 ------------+------------------------+------------------------------ 440 31744-32767 | Vendor Private Use | MUST NOT be allocated 441 ------------+------------------------+------------------------------ 442 32768-49161 | Standards Action | This range is for optional 443 | | sub-TLVs that can be silently 444 | | discarded if not recognized. 445 ------------+------------------------+------------------------------ 446 49162-64511 | Specification Required | Experimental RFC needed 447 | | This range is for optional 448 | | sub-TLVs that can be silently 449 | | discarded if not recognized. 450 ------------+------------------------+------------------------------ 451 64512-65535 | Vendor Private Use | MUST NOT be allocated 452 ------------+------------------------+------------------------------ 454 Type 1 TLV sub-TLVs 456 Sub-TLVs for TLV Type 1 458 Sub-TLV | Value Field | Reference 459 -----------+-------------------------------+-------------------- 460 0 | Reserved - do not assign | This document 461 -----------+-------------------------------+-------------------- 462 1 | LDP IPv4 prefix | [RFC4379] 463 -----------+-------------------------------+-------------------- 464 2 | LDP IPv6 prefix | [RFC4379] 465 -----------+-------------------------------+-------------------- 466 3 | RSVP IPv4 LSP | [RFC4379] 467 -----------+-------------------------------+-------------------- 468 4 | RSVP IPv6 LSP | [RFC4379] 469 -----------+-------------------------------+-------------------- 470 5 | Not Assigned | [RFC4379] 471 -----------+-------------------------------+-------------------- 472 6 | VPN IPv4 prefix | [RFC4379] 473 -----------+-------------------------------+-------------------- 474 7 | VPN IPv6 prefix | [RFC4379] 475 -----------+-------------------------------+-------------------- 476 8 | L2 VPN endpoint | [RFC4379] 477 -----------+-------------------------------+-------------------- 478 9 | "FEC 128" Pseudowire - IPv4 | [RFC4379] 479 | (DEPRECATED) | [RFC6829] 480 -----------+-------------------------------+-------------------- 481 10 | "FEC 128" Pseudowire - IPv4 | [RFC4379] 482 | | [RFC6829] 483 -----------+-------------------------------+-------------------- 484 11 | "FEC 129" Pseudowire - IPv4 | [RFC4379] 485 | | [RFC6829] 486 -----------+-------------------------------+-------------------- 487 12 | BGP labeled IPv4 prefix | [RFC4379] 488 -----------+-------------------------------+-------------------- 489 13 | BGP labeled IPv6 prefix | [RFC4379] 490 -----------+-------------------------------+-------------------- 491 14 | Generic IPv4 prefix | [RFC4379] 492 -----------+-------------------------------+-------------------- 493 15 | Generic IPv6 prefix | [RFC4379] 494 -----------+-------------------------------+-------------------- 495 16 | Nil FEC | [RFC4379] 496 -----------+-------------------------------+-------------------- 497 17 | RSVP P2MP IPv4 Session | [RFC6425] 498 -----------+-------------------------------+-------------------- 499 18 | RSVP P2MP IPv6 Session | [RFC6425] 500 -----------+-------------------------------+-------------------- 501 19 | Multicast P2MP LDP FEC Stack | [RFC6425] 502 -----------+-------------------------------+-------------------- 503 20 | Multicast MP2MP LDP FEC Stack | [RFC6425] 504 -----------+-------------------------------+-------------------- 505 21 | Unassigned | 506 -----------+-------------------------------+-------------------- 507 22 | Static LSP | [RFC6426] 508 -----------+-------------------------------+-------------------- 509 23 | Static Pseudowire | [RFC6426] 510 -----------+-------------------------------+-------------------- 511 24 | "FEC 128" Pseudowire - IPv6 | [RFC6829] 512 -----------+-------------------------------+-------------------- 513 25 | "FEC 129" Pseudowire - IPv6 | [RFC6829] 514 -----------+-------------------------------+-------------------- 516 3.3.2. Sub TLV registry for TLV Type 9 518 TLV Type 9 has a very different allocation policy to all other TLVs; 519 any value carried in the Value field of the TLV is a copy of a TLV 520 that has not been understood or recognized. It is even doubtful that 521 "All values" technically is a sub-TLV, but both the IANA registry and 522 [RFC4379] says it is. Equally, it is unclear whether or not TLV Type 523 9 should be used to report a sub-TLV that has not been recognised and 524 if it is, how that sub-TLV should appear in the Type 9 TLV. More 525 work on this is needed but that falls outside the scope of this 526 document. 528 Registration procedures TLV type 9 sub-TLVs 530 Range | Registration Procedures | Notes 531 -----------+--------------------------+---------------------------- 532 0-65635 | Reserved MUST NOT be | Any value carried in the 533 | assigned | value field of TLV type 9 534 | | means that a TLV has not 535 | | been understood. 536 -----------+--------------------------+------------------------------ 538 Type 9 TLV sub-TLVs 540 Sub-TLVs for TLV Type 9 542 Sub-TLV | Value Field | Reference 543 -----------+-------------------------------+-------------------- 544 All values | TLV that is not understood | [RFC4379] 545 -----------+-------------------------------+-------------------- 547 3.3.3. Sub TLV registry for TLV Type 11 549 Registration procedures TLV type 11 sub-TLVs 550 (as specified by RFC6425) 552 Range | Registration Procedures| Notes 553 -------------+------------------------+------------------------------ 554 0-16383 | Standards Action | This range is for mandatory 555 | | TLVs or for optional TLVs 556 | | that require an error message 557 | | if not recognized. 558 -------------+------------------------+------------------------------ 559 16384-31743 | Specification Required | Experimental RFC needed 560 -------------+------------------------+------------------------------ 561 31744-32767 | Vendor Private Use | MUST NOT be allocated 562 -------------+------------------------+------------------------------ 563 32768-49161 | Standards Action | This range is for optional 564 | | TLVs that can be silently 565 | | dropped if not recognized. 566 -------------+------------------------+------------------------------ 567 49162-64511 | Specification Required | Experimental RFC needed 568 -------------+------------------------+------------------------------ 569 64512-65535 | Vendor Private Use | MUST NOT be allocated 570 -------------+------------------------+------------------------------ 572 Type 11 TLV sub-TLVs 574 sub-TLV Value Field Reference 575 -----------+-------------------------------+------------------- 576 0 | Reserved not to be assigned | This document 577 -----------+-------------------------------+------------------- 578 1 | IPv4 Egress Address P2MP | [RFC6425] 579 | Responder | 580 -----------+-------------------------------+------------------- 581 2 | IPv6 Egress Address P2MP | [RFC6425] 582 | Responder | 583 -----------+-------------------------------+------------------- 584 3 | IPv4 Node Address P2MP | [RFC6425] 585 | Responder | 586 -----------+-------------------------------+------------------- 587 4 | IPv6 Node Address P2MP | [RFC6425] 588 | Responder | 590 -----------+-------------------------------+------------------- 592 3.3.4. Sub TLV registry for TLV Type 20 594 Registration procedures TLV type 20 sub-TLVs 595 (as specified by RFC6424) 597 Range | Registration Procedures| Notes 598 -------------+------------------------+------------------------------ 599 0-16383 | Standards Action | This range is for mandatory 600 | | TLVs or for optional TLVs 601 | | that require an error message 602 | | if not recognized. 603 -------------+------------------------+------------------------------ 604 16384-31743 | Specification Required | Experimental RFC needed 605 -------------+------------------------+------------------------------ 606 31744-32767 | Vendor Private Use | MUST NOT be allocated 607 -------------+------------------------+------------------------------ 608 32768-49161 | Standards Action | This range is for optional 609 | | TLVs that can be silently 610 | | dropped if not recognized. 611 -------------+------------------------+------------------------------ 612 49162-64511 | Specification Required | Experimental RFC needed 613 -------------+------------------------+------------------------------ 614 64512-65535 | Vendor Private Use | MUST NOT be allocated 615 -------------+------------------------+------------------------------ 617 Type 20 TLV sub-TLVs 619 sub-TLV Value Field Reference 620 -----------+-------------------------------+------------------- 621 1 | Multipath data | [RFC6424] 622 -----------+-------------------------------+------------------- 623 2 | Label stack | [RFC6424] 624 -----------+-------------------------------+------------------- 625 3 | FEC stack change | [RFC6424] 626 -----------+-------------------------------+------------------- 628 4. Security Considerations 630 This document amends the policy for the registration of sub-TLVs of 631 MPLS LSP Ping. As such, it does not introduce any additional 632 security considerations over and above those included with the 633 specification of the sub-TLVs themselves. 635 5. IANA considerations 637 This document revises the allocation policies in the use of the TLVs 638 and sub-TLVs of the MPLS LSP Ping Parameters, as previously defined 639 in [RFC4379]. 641 The allocation policy for TLVs is unaltered from RFC4379 but the IANA 642 registry should be updated to refer to this document, lest users of 643 this information do not appreciate that the policies for sub-TLVs, as 644 specified in [RFC4379], no longer apply; that is, users are directed 645 here first, so that they have the current, overall procedures. 647 The allocation policy for sub-TLVs is that all sub-TLVS now come from 648 a common pool so that a sub-TLV sub-Type number is now unique within 649 all of MPLS LSP Ping Parameters. 651 The lowest value for allocation of any sub-TLV sub-Type is 32, so as 652 to avoid overlap with any sub-TLV Type currently defined or under 653 consideration. 655 The registration procedure is as specified in Sub-TLV registry for 656 all TLVs (Section 3.3.1), namely 658 Range | Registration Procedures| Notes 659 ------------+------------------------+------------------------------ 660 0-31 | Reserved | Existing allocations in this 661 | | range are unaltered. 662 | | No future allocations are 663 | | to be made from this range. 664 ------------+------------------------+------------------------------ 665 32-16383 | Standards Action | This range is for mandatory 666 | | sub-TLVs or for optional 667 | | sub-TLVs that require an 668 | | error message if not 669 | | recognized. 670 ------------+------------------------+------------------------------ 671 16384-31743 | Specification Required | Experimental RFC needed 672 | | This range is for mandatory 673 | | sub-TLVs or for optional 674 | | sub-TLVs that require an 675 | | error message if not 676 | | recognized. 677 ------------+------------------------+------------------------------ 678 31744-32767 | Vendor Private Use | MUST NOT be allocated 679 ------------+------------------------+------------------------------ 680 32768-49161 | Standards Action | This range is for optional 681 | | sub-TLVs that can be silently 682 | | discarded if not recognized. 683 ------------+------------------------+------------------------------ 684 49162-64511 | Specification Required | Experimental RFC needed 685 | | This range is for optional 686 | | sub-TLVs that can be silently 687 | | discarded if not recognized. 688 ------------+------------------------+------------------------------ 689 64512-65535 | Vendor Private Use | MUST NOT be allocated 690 ------------+------------------------+------------------------------ 692 6. Acknowledgments 694 TBD 696 7. References 698 7.1. Normative References 700 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 701 Requirement Levels", BCP 14, RFC 2119, March 1997. 703 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 704 Label Switched (MPLS) Data Plane Failures", RFC 4379, 705 February 2006. 707 7.2. Informative references 709 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 710 "Bidirectional Forwarding Detection (BFD) for MPLS Label 711 Switched Paths (LSPs)", RFC 5884, June 2010. 713 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 714 Performing Label Switched Path Ping (LSP Ping) over MPLS 715 Tunnels", RFC 6424, November 2011. 717 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 718 S., and T. Nadeau, "Detecting Data-Plane Failures in 719 Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 720 6425, November 2011. 722 [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS 723 On-Demand Connectivity Verification and Route Tracing", 724 RFC 6426, November 2011. 726 [RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label 727 Switched Path (LSP) Ping for Pseudowire Forwarding 728 Equivalence Classes (FECs) Advertised over IPv6", RFC 729 6829, January 2013. 731 Authors' Addresses 733 Loa Andersson 734 Huawei 736 Email: loa@mail01.huawei.com 738 Mach(Guoyi) Chen 739 Huawei 741 Email: mach.chen@huawei.com 743 Tom Petch 744 Engineering Networks Ltd 746 Email: tomSecurity@network-engineer.co.uk