Network Working Group L. Andersson Internet-Draft M. Chen Updates: 4379 (if approved) Huawei Intended status: Standards Track T. Petch Expires: November 01, 2013 Engineering Networks Ltd April 30, 2013 "MPLS LSP Ping TLVs and sub-TLVs registry" draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02.txt Abstract This document addresses issues with the structure, allocation policies and clarity in the use of the "TLVs and sub-TLVs" of the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" in the "Multiprotocol Label Switching Architecture (MPLS)" name space. This document does not change any existing allocations and the new structure is backwards compatible with the existing registries. The policy for the allocation of TLVs is unchanged but future allocations of sub-TLVs will come from a single namespace, common to all TLVs of LSP Ping Parameters. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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 http://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 November 01, 2013. Andersson, et al. Expires November 01, 2013 [Page 1]
Internet-Draft MPLS LSP Ping TLVs and sub-TLVs registry April 2013 Copyright Notice Copyright (c) 2013 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 (http://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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Current situation . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Current situation - model . . . . . . . . . . . . . . . . 3 2.2. Allocation policies and Scope . . . . . . . . . . . . . . 4 2.3. A closer look at the model . . . . . . . . . . . . . . . 5 3. New registry structure . . . . . . . . . . . . . . . . . . . 6 3.1. If we'd done it from start . . . . . . . . . . . . . . . 7 3.2. TLV Registry and allocation procedures . . . . . . . . . 8 3.3. Sub-TLV registries and allocation policies . . . . . . . 9 3.3.1. Sub-TLV registry for all TLVs . . . . . . . . . . . . 10 3.3.2. Sub TLV registry for TLV Type 9 . . . . . . . . . . . 12 3.3.3. Sub TLV registry for TLV Type 11 . . . . . . . . . . 13 3.3.4. Sub TLV registry for TLV Type 20 . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 7.2. Informative references . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction This document revises the allocation policies in the use of the TLVs and sub-TLVs of the MPLS LSP Ping Parameters, as defined in [RFC4379]. This document does not change any existing allocations and the new structure is backwards compatible with the existing registries. Andersson, et al. Expires November 01, 2013 [Page 2]
Internet-Draft MPLS LSP Ping TLVs and sub-TLVs registry April 2013 The policy for the allocation of TLVs is unchanged but future allocations of sub-TLVs will come from a single namespace, common to all TLVs of MPLS LSP Ping Parameters. The allocation of existing sub-TLVs is unaltered, so that the meaning of, e.g., sub-TLV sub-Type 1 is dependent on the TLV under which it appears. No future allocations will be made with a sub-Type of less than 32. Future allocations will be made from a single namespace starting at 32; a sub-TLV defined in this way may appear as part of any current or future TLV. The document that specifies such an allocation should state which TLVs the sub-TLV may appear under and indicate any other future use which seems appropriate or inappropriate. 2. Current situation Today all TLVs and sub-TLVs are found in a single table, and the allocation policies are the same for all TLVs and sub-TLVs. The table below illustrates how the registry is set up. Initially this might have been a good idea, but over time, with an increasing number of TLVs, and with some sub-TLVs shared across TLVs, it has become increasingly difficult to understand how the allocation policies interact. 2.1. Current situation - model The table below illustrates how the registry is set up and the allocation policies work currently. We have chosen not to just copy the current registry here, but instead build a model that shows how the allocation policies work. --Note to RFC Editor; the various RFC aaaa to RFC zzzz are really meant to be like that in the finished document; we are not asking you to replace them with anything:-) Current TLV and sub-TLV registry (model) Type Sub-type Value field Reference +------+----------+---------------------------+----------------+ 1 | | TLV # 1 | RFC xxxx (1) 1 | 1 | sub-TLV # 1 | RFC xxxx (2) 1 | 2 | sub-TLV # 2 | RFC yyyy (3) 1 | 3 | sub-TLV # 3 | RFC yyyy (4) 2 | | TLV # 2 | RFC xxxx (5) 3 | | TLV # 3 | RFC zzzz (6) 3 | 1 | sub-TLV # 1 | RFC zzzz (7) Andersson, et al. Expires November 01, 2013 [Page 3]
Internet-Draft MPLS LSP Ping TLVs and sub-TLVs registry April 2013 3 | 2 | sub-TLV # 2 | RFC zzzz (8) 3 | 3 | sub-TLV # 3 | RFC aaaa (9) 4 | | TLV # 4 | RFC bbbb (10) 4 | 1-16383 | as specified for type 1 | RFC bbbb (11) 5 | | TLV # 5 | RFC cccc (12) 5 | 1-65535 | as specified for type 1 | RFC cccc (13) Note: The row number column to the right is added here to discuss what is on the different rows. 2.2. Allocation policies and Scope TLV and sub-TLV registration procedures Range | Registration Procedures| Notes -------------+------------------------+------------------------------ 0-16383 | Standards Action | This range is for mandatory | | TLVs or for optional TLVs | | that require an error message | | if not recognized. -------------+------------------------+------------------------------ 16384-31743 | Specification Required | Experimental RFC needed -------------+------------------------+------------------------------ 31744-32767 | Vendor Private Use | MUST NOT be allocated -------------+------------------------+------------------------------ 32768-49161 | Standards Action | This range is for optional | | TLVs that can be silently | | dropped if not recognized. -------------+------------------------+------------------------------ 49162-64511 | Specification Required | Experimental RFC needed -------------+------------------------+------------------------------ 64512-65535 | Vendor Private Use | MUST NOT be allocated -------------+------------------------+------------------------------ The IANA registry does not give enough information to correctly allocate TLVs and sub-TLVs, instead careful reading of [RFC4379] is necessary. [RFC4379] says: The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the range 0-16383 and 32768-49161 are made via Standards Action as defined in Section 5; assignments in the range 16384-31743 and 49162-64511 are made via "Specification Required" as defined above; Andersson, et al. Expires November 01, 2013 [Page 4]
Internet-Draft MPLS LSP Ping TLVs and sub-TLVs registry April 2013 values in the range 31744-32767 and 64512-65535 are for Vendor Private Use, and MUST NOT be allocated. [RFC4379] also says that the sub-TLVs are scoped by the TLVs, i.e. a sub-TLV defined for one TLV is valid for that TLV only. Later the practice to re-define (a block of) sub-TLVs defined for one TLV for another TLV was introduced. 2.3. A closer look at the model The list below contains what we see as the results of the most common allocation requests for this registry. 1. Row 1 says that IANA has allocated a TLV as requested in RFCxxxx. This TLV is type 1. RFCxxxx is the document that defines the registry and sets up the allocation policies. 2. Row 2 says that IANA has allocated a sub-TLV for TLV type 1, "sub-TLV #1", the source for this allocation is the same that defined the registry and allocated the TLV Type 1 (RFCxxxx). 3. Row 3 says that IANA has allocated a second sub-TLV (sub-TLV #2) for TLV type 1, the source for this allocation is RFCyyyy. - 4. Row 4 says that IANA has allocated a third sub-TLV (sub-TLV #3) for TLV type 1, the source for this allocation is RFCyyyy. - 5. Row 5 says that IANA has allocated a new TLV (TLV type 2), the source for this allocation is RFCxxxx, the same RFC that defined the registry. TLV type 2 has no sub-TLVs yet defined. 6. Row 6 says that IANA has allocated a new TLV (TLV type 3), the source for this allocation is RFCzzzz. - 7. Row 7 says that IANA has allocated a sub-TLV (sub-TLV # 1) for TLV type 3, the source for this allocation is RFCzzzz. Andersson, et al. Expires November 01, 2013 [Page 5]
Internet-Draft MPLS LSP Ping TLVs and sub-TLVs registry April 2013 This means that we have one sub-TLV # 1 for TLV type 1, and another sub-TLV # 1 for TLV type 3. In itself this is not a problem, the sub-TLVs are scoped by the TLVs. 8. Row 8 says that IANA has allocated a sub-TLV (sub-TLV # 2) for TLV type 3, the source for this allocation is RFCzzzz. - 9. Row 9 says that IANA has allocated a sub-TLV (sub-TLV # 2) for TLV type 3, the source for this allocation is RFCaaaa. - 10. Row 10 says that IANA has allocated a new TLV (TLV type 4), the source for this allocation is RFCbbbb. - 11. Row 11 says that IANA has been instructed not to allocate any sub-TLVs from the range 1-16383, but that the sub-TLVs for TLV type 4, shall use the same sub-TLVs that have been specified for TLV type 1 in this range. This implies that other ranges for TLV type 4 are open for allocation for "TLV type 4 specific sub-TLVs". This is specified in RFCbbbb. 12. Row 12 says that IANA has allocated a new TLV (TLV type 5), the source for this allocation is RFCcccc. - 13. Row 13 says that IANA has been instructed not to allocate any sub-TLVs from the entire range (1-65535), but that the sub-TLVs for TLV type 5, shall use the same sub-TLVs that have been specified for TLV type 1. This is specified in RFCcccc. Close reading of the allocation rules would likely show that disallowing the assignment of vendor-specific sub-TLVs is moot. 3. New registry structure Andersson, et al. Expires November 01, 2013 [Page 6]
Internet-Draft MPLS LSP Ping TLVs and sub-TLVs registry April 2013 3.1. If we'd done it from start The name space of sub-TLVs is very large, 65 535 potential TLVs times 65 535 sub-TLVs per TLV, gives a maximum of 4 294 836 335 sub- TLVs. There seems no reason why that number of sub-TLVs should be needed; rather, 65 535 sub-TLVs shared among all TLVs would seem to have been more than sufficient. If the IANA registries had been set up with one registry for TLVs and another for sub-TLVs, that would have resulted in registries and allocation policies much easier to understand and comprehend. In practice, the same sub-TLV number appears more than once under different TLVs with a different meaning on each occasion. Thus sub- TLV 1 appears under TLV Type 1 as LDP IPv4 Prefix, under TLV Type 11 as IPv4 Egress Address P2MP Responder and under TLV Type 20 as Multipath data. At the same time, TLVs Types 16 and 21 reuse sub-TLV 1 with the same meaning as for TLV Type 1. Thus it is now impossible to create a single registry for sub-TLVs which encompasses all existing sub-TLVs. At the same time, such a registry would simplify future registration and use, allowing, for example, a sub-TLV to be defined for an IPv6 address that would then be used wherever such an address is required. Hence, the future policy for the registration of sub-TLVs is to have a single registry regardless of which TLV the sub-TLV appears under. This registry follows the same pattern as the existing registries, namely of 0-16383 | Standards Action | Mandatory (sub)TLVs -------------+------------------------+-------------------------- 16384-31743 | Specification Required | Mandatory Experimental | | RFC needed -------------+------------------------+-------------------------- 31744-32767 | Vendor Private Use | MUST NOT be allocated -------------+------------------------+-------------------------- 32768-49161 | Standards Action | Optional (sub)TLVs -------------+------------------------+-------------------------- 49162-64511 | Specification Required | Optional Experimental | | RFC needed -------------+------------------------+-------------------------- 64512-65535 | Vendor Private Use | MUST NOT be allocated -------------+------------------------+-------------------------- excepting that the range 0 to 31 is now reserved and MUST NOT be assigned lest there is an overlap with existing definitions. The choice of 32 is somewhat greater than the greatest, existing, defined Andersson, et al. Expires November 01, 2013 [Page 7]
Internet-Draft MPLS LSP Ping TLVs and sub-TLVs registry April 2013 sub-TLV, 25 for TLV Type 1, and is chosen to be a more user-friendly, easier to remember, number than, say, 26 or 29. The examples in TLV Registry and allocation procedures (Section 3.2) and Sub-TLV registries and allocation policies (Section 3.3) are the actual allocations in the IANA registry as they are found at the time of writing of this document (January 2013). 3.2. TLV Registry and allocation procedures TLV registration procedures Range | Registration Procedures| Notes -------------+------------------------+------------------------------ 0-16383 | Standards Action | This range is for mandatory | | TLVs or for optional TLVs | | that require an error message | | if not recognized. -------------+------------------------+------------------------------ 16384-31743 | Specification Required | Experimental RFC needed | | This range is for mandatory | | TLVs or for optional TLVs | | that require an error message | | if not recognized. -------------+------------------------+------------------------------ 31744-32767 | Vendor Private Use | MUST NOT be allocated -------------+------------------------+------------------------------ 32768-49161 | Standards Action | This range is for optional | | TLVs that can be silently | | discarded if not recognized. -------------+------------------------+------------------------------ 49162-64511 | Specification Required | Experimental RFC needed | | This range is for optional | | TLVs that can be silently | | discarded if not recognized. -------------+------------------------+------------------------------ 64512-65535 | Vendor Private Use | MUST NOT be allocated -------------+------------------------+------------------------------ LSP Ping TLV Registry Type | Value Field | Reference --------------+------------------------------+--------------------- 1 | Target FEC Stack | [RFC4379] --------------+------------------------------+--------------------- 2 | Downstream Mapping | [RFC4379] | (DEPRECATED) | [RFC6424] Andersson, et al. Expires November 01, 2013 [Page 8]
Internet-Draft MPLS LSP Ping TLVs and sub-TLVs registry April 2013 --------------+------------------------------+--------------------- 3 | Pad | [RFC4379] --------------+------------------------------+--------------------- 4 | Not Assigned | [RFC4379] --------------+------------------------------+--------------------- 5 | Vendor Enterprise Number | [RFC4379] --------------+------------------------------+--------------------- 6 | Not Assigned | [RFC4379] --------------+------------------------------+--------------------- 7 | Interface and Label Stack | [RFC4379] --------------+------------------------------+--------------------- 8 | Not Assigned | [RFC4379] --------------+------------------------------+--------------------- 9 | Errored TLVs | [RFC4379] --------------+------------------------------+--------------------- 10 | Reply TOS Byte | [RFC4379] --------------+------------------------------+--------------------- 11 | P2MP Responder Identifier | [RFC6425] --------------+------------------------------+--------------------- 12 | Echo Jitter | [RFC6425] --------------+------------------------------+--------------------- 13 | Source ID | [RFC6426] --------------+------------------------------+--------------------- 14 | Destination ID | [RFC6426] --------------+------------------------------+--------------------- 15 | BFD Discriminator | [RFC5884] --------------+------------------------------+--------------------- 16 | Reverse-path Target FEC Stack| [RFC6426] --------------+------------------------------+--------------------- 17-19 | Unassigned | --------------+------------------------------+--------------------- 20 | Downstream Detailed Mapping | [RFC6424] --------------+------------------------------+--------------------- 22-31743 | Unassigned | --------------+------------------------------+--------------------- 31744-32767 | Reserved for Vendor | [RFC4379] | private use | --------------+------------------------------+--------------------- 32768-64511 | Unassigned | --------------+------------------------------+--------------------- 64512-65535 | Reserved for Vendor | [RFC4379] | private use | --------------+------------------------------+--------------------- 3.3. Sub-TLV registries and allocation policies Andersson, et al. Expires November 01, 2013 [Page 9]
Internet-Draft MPLS LSP Ping TLVs and sub-TLVs registry April 2013 3.3.1. Sub-TLV registry for all TLVs Registration procedures for all sub-TLVs Range | Registration Procedures| Notes ------------+------------------------+------------------------------ 0-31 | Reserved | Existing allocations in this | | range are unaltered. | | No future allocations are | | to be made from this range. ------------+------------------------+------------------------------ 32-16383 | Standards Action | This range is for mandatory | | sub-TLVs or for optional | | sub-TLVs that require an | | error message if not | | recognized. ------------+------------------------+------------------------------ 16384-31743 | Specification Required | Experimental RFC needed | | This range is for mandatory | | sub-TLVs or for optional | | sub-TLVs that require an | | error message if not | | recognized. ------------+------------------------+------------------------------ 31744-32767 | Vendor Private Use | MUST NOT be allocated ------------+------------------------+------------------------------ 32768-49161 | Standards Action | This range is for optional | | sub-TLVs that can be silently | | discarded if not recognized. ------------+------------------------+------------------------------ 49162-64511 | Specification Required | Experimental RFC needed | | This range is for optional | | sub-TLVs that can be silently | | discarded if not recognized. ------------+------------------------+------------------------------ 64512-65535 | Vendor Private Use | MUST NOT be allocated ------------+------------------------+------------------------------ Type 1 TLV sub-TLVs Sub-TLVs for TLV Type 1 Sub-TLV | Value Field | Reference -----------+-------------------------------+-------------------- 0 | Reserved - do not assign | This document -----------+-------------------------------+-------------------- Andersson, et al. Expires November 01, 2013 [Page 10]
Internet-Draft MPLS LSP Ping TLVs and sub-TLVs registry April 2013 1 | LDP IPv4 prefix | [RFC4379] -----------+-------------------------------+-------------------- 2 | LDP IPv6 prefix | [RFC4379] -----------+-------------------------------+-------------------- 3 | RSVP IPv4 LSP | [RFC4379] -----------+-------------------------------+-------------------- 4 | RSVP IPv6 LSP | [RFC4379] -----------+-------------------------------+-------------------- 5 | Not Assigned | [RFC4379] -----------+-------------------------------+-------------------- 6 | VPN IPv4 prefix | [RFC4379] -----------+-------------------------------+-------------------- 7 | VPN IPv6 prefix | [RFC4379] -----------+-------------------------------+-------------------- 8 | L2 VPN endpoint | [RFC4379] -----------+-------------------------------+-------------------- 9 | "FEC 128" Pseudowire - IPv4 | [RFC4379] | (DEPRECATED) | [RFC6829] -----------+-------------------------------+-------------------- 10 | "FEC 128" Pseudowire - IPv4 | [RFC4379] | | [RFC6829] -----------+-------------------------------+-------------------- 11 | "FEC 129" Pseudowire - IPv4 | [RFC4379] | | [RFC6829] -----------+-------------------------------+-------------------- 12 | BGP labeled IPv4 prefix | [RFC4379] -----------+-------------------------------+-------------------- 13 | BGP labeled IPv6 prefix | [RFC4379] -----------+-------------------------------+-------------------- 14 | Generic IPv4 prefix | [RFC4379] -----------+-------------------------------+-------------------- 15 | Generic IPv6 prefix | [RFC4379] -----------+-------------------------------+-------------------- 16 | Nil FEC | [RFC4379] -----------+-------------------------------+-------------------- 17 | RSVP P2MP IPv4 Session | [RFC6425] -----------+-------------------------------+-------------------- 18 | RSVP P2MP IPv6 Session | [RFC6425] -----------+-------------------------------+-------------------- 19 | Multicast P2MP LDP FEC Stack | [RFC6425] -----------+-------------------------------+-------------------- 20 | Multicast MP2MP LDP FEC Stack | [RFC6425] -----------+-------------------------------+-------------------- 21 | Unassigned | -----------+-------------------------------+-------------------- 22 | Static LSP | [RFC6426] -----------+-------------------------------+-------------------- 23 | Static Pseudowire | [RFC6426] Andersson, et al. Expires November 01, 2013 [Page 11]
Internet-Draft MPLS LSP Ping TLVs and sub-TLVs registry April 2013 -----------+-------------------------------+-------------------- 24 | "FEC 128" Pseudowire - IPv6 | [RFC6829] -----------+-------------------------------+-------------------- 25 | "FEC 129" Pseudowire - IPv6 | [RFC6829] -----------+-------------------------------+-------------------- 3.3.2. Sub TLV registry for TLV Type 9 TLV Type 9 has a very different allocation policy to all other TLVs; any value carried in the Value field of the TLV is a copy of a TLV that has not been understood or recognized. It is even doubtful that "All values" technically is a sub-TLV, but both the IANA registry and [RFC4379] says it is. Equally, it is unclear whether or not TLV Type 9 should be used to report a sub-TLV that has not been recognised and if it is, how that sub-TLV should appear in the Type 9 TLV. More work on this is needed but that falls outside the scope of this document. Registration procedures TLV type 9 sub-TLVs Range | Registration Procedures | Notes -----------+--------------------------+---------------------------- 0-65635 | Reserved MUST NOT be | Any value carried in the | assigned | value field of TLV type 9 | | means that a TLV has not | | been understood. -----------+--------------------------+------------------------------ Type 9 TLV sub-TLVs Sub-TLVs for TLV Type 9 Sub-TLV | Value Field | Reference -----------+-------------------------------+-------------------- All values | TLV that is not understood | [RFC4379] -----------+-------------------------------+-------------------- Andersson, et al. Expires November 01, 2013 [Page 12]
Internet-Draft MPLS LSP Ping TLVs and sub-TLVs registry April 2013 3.3.3. Sub TLV registry for TLV Type 11 Registration procedures TLV type 11 sub-TLVs (as specified by RFC6425) Range | Registration Procedures| Notes -------------+------------------------+------------------------------ 0-16383 | Standards Action | This range is for mandatory | | TLVs or for optional TLVs | | that require an error message | | if not recognized. -------------+------------------------+------------------------------ 16384-31743 | Specification Required | Experimental RFC needed -------------+------------------------+------------------------------ 31744-32767 | Vendor Private Use | MUST NOT be allocated -------------+------------------------+------------------------------ 32768-49161 | Standards Action | This range is for optional | | TLVs that can be silently | | dropped if not recognized. -------------+------------------------+------------------------------ 49162-64511 | Specification Required | Experimental RFC needed -------------+------------------------+------------------------------ 64512-65535 | Vendor Private Use | MUST NOT be allocated -------------+------------------------+------------------------------ Type 11 TLV sub-TLVs sub-TLV Value Field Reference -----------+-------------------------------+------------------- 0 | Reserved not to be assigned | This document -----------+-------------------------------+------------------- 1 | IPv4 Egress Address P2MP | [RFC6425] | Responder | -----------+-------------------------------+------------------- 2 | IPv6 Egress Address P2MP | [RFC6425] | Responder | -----------+-------------------------------+------------------- 3 | IPv4 Node Address P2MP | [RFC6425] | Responder | -----------+-------------------------------+------------------- 4 | IPv6 Node Address P2MP | [RFC6425] | Responder | Andersson, et al. Expires November 01, 2013 [Page 13]
Internet-Draft MPLS LSP Ping TLVs and sub-TLVs registry April 2013 -----------+-------------------------------+------------------- 3.3.4. Sub TLV registry for TLV Type 20 Registration procedures TLV type 20 sub-TLVs (as specified by RFC6424) Range | Registration Procedures| Notes -------------+------------------------+------------------------------ 0-16383 | Standards Action | This range is for mandatory | | TLVs or for optional TLVs | | that require an error message | | if not recognized. -------------+------------------------+------------------------------ 16384-31743 | Specification Required | Experimental RFC needed -------------+------------------------+------------------------------ 31744-32767 | Vendor Private Use | MUST NOT be allocated -------------+------------------------+------------------------------ 32768-49161 | Standards Action | This range is for optional | | TLVs that can be silently | | dropped if not recognized. -------------+------------------------+------------------------------ 49162-64511 | Specification Required | Experimental RFC needed -------------+------------------------+------------------------------ 64512-65535 | Vendor Private Use | MUST NOT be allocated -------------+------------------------+------------------------------ Type 20 TLV sub-TLVs sub-TLV Value Field Reference -----------+-------------------------------+------------------- 1 | Multipath data | [RFC6424] -----------+-------------------------------+------------------- 2 | Label stack | [RFC6424] -----------+-------------------------------+------------------- 3 | FEC stack change | [RFC6424] -----------+-------------------------------+------------------- Andersson, et al. Expires November 01, 2013 [Page 14]
Internet-Draft MPLS LSP Ping TLVs and sub-TLVs registry April 2013 4. Security Considerations This document amends the policy for the registration of sub-TLVs of MPLS LSP Ping. As such, it does not introduce any additional security considerations over and above those included with the specification of the sub-TLVs themselves. 5. IANA considerations This document revises the allocation policies in the use of the TLVs and sub-TLVs of the MPLS LSP Ping Parameters, as previously defined in [RFC4379]. The allocation policy for TLVs is unaltered from RFC4379 but the IANA registry should be updated to refer to this document, lest users of this information do not appreciate that the policies for sub-TLVs, as specified in [RFC4379], no longer apply; that is, users are directed here first, so that they have the current, overall procedures. The allocation policy for sub-TLVs is that all sub-TLVS now come from a common pool so that a sub-TLV sub-Type number is now unique within all of MPLS LSP Ping Parameters. The lowest value for allocation of any sub-TLV sub-Type is 32, so as to avoid overlap with any sub-TLV Type currently defined or under consideration. The registration procedure is as specified in Sub-TLV registry for all TLVs (Section 3.3.1), namely Range | Registration Procedures| Notes ------------+------------------------+------------------------------ 0-31 | Reserved | Existing allocations in this | | range are unaltered. | | No future allocations are | | to be made from this range. ------------+------------------------+------------------------------ 32-16383 | Standards Action | This range is for mandatory | | sub-TLVs or for optional | | sub-TLVs that require an | | error message if not | | recognized. ------------+------------------------+------------------------------ 16384-31743 | Specification Required | Experimental RFC needed | | This range is for mandatory | | sub-TLVs or for optional Andersson, et al. Expires November 01, 2013 [Page 15]
Internet-Draft MPLS LSP Ping TLVs and sub-TLVs registry April 2013 | | sub-TLVs that require an | | error message if not | | recognized. ------------+------------------------+------------------------------ 31744-32767 | Vendor Private Use | MUST NOT be allocated ------------+------------------------+------------------------------ 32768-49161 | Standards Action | This range is for optional | | sub-TLVs that can be silently | | discarded if not recognized. ------------+------------------------+------------------------------ 49162-64511 | Specification Required | Experimental RFC needed | | This range is for optional | | sub-TLVs that can be silently | | discarded if not recognized. ------------+------------------------+------------------------------ 64512-65535 | Vendor Private Use | MUST NOT be allocated ------------+------------------------+------------------------------ 6. Acknowledgments TBD 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 7.2. Informative references [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels", RFC 6424, November 2011. [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, November 2011. Andersson, et al. Expires November 01, 2013 [Page 16]
Internet-Draft MPLS LSP Ping TLVs and sub-TLVs registry April 2013 [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011. [RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6", RFC 6829, January 2013. Authors' Addresses Loa Andersson Huawei Email: loa@mail01.huawei.com Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com Tom Petch Engineering Networks Ltd Email: tomSecurity@network-engineer.co.uk Andersson, et al. Expires November 01, 2013 [Page 17]
