idnits 2.17.1 draft-andersson-mpls-lsp-ping-upd-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4379, but the abstract doesn't seem to directly say this. It does mention RFC4379 though, so this could be OK. 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 (July 15, 2013) is 3938 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) == Missing Reference: 'IANA' is mentioned on line 97, but not defined ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Andersson 3 Internet-Draft Huawei 4 Updates: 4379 (if approved) July 15, 2013 5 Intended status: Standards Track 6 Expires: January 16, 2014 8 Updates to RFC 4379 IANA section 9 draft-andersson-mpls-lsp-ping-upd-00 11 Abstract 13 The MultiProtocol Label Switching (MPLS) protcol for detecting Label 14 Switched Path failures (LSP Ping), as defined in RFC 4379 and several 15 extensions, are widely deployed and very popular. 17 The IANA sectiion of RFC4379 lack in clarity and need to be updated. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 16, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Update of the RCF 4379 IANA section . . . . . . . . . . . . . 2 61 2.1. Error codes for unrecognized TLV and sub-TLV types . . . 3 62 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 64 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 65 6. Normative References . . . . . . . . . . . . . . . . . . . . 3 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1. Introduction 70 This document updates the IANA section of RFC 4379 [RFC4379] for LSP 71 Ping Parameters. 73 2. Update of the RCF 4379 IANA section 75 The first 3 paragraphs of sub-section 7.2. "TLVs" in the IANA 76 section of RFC 4379 is considered unclear and is therefore now 77 replaced by the following text: 79 The IANA has created and will maintain a registry for the Type field 80 of top-level TLVs and per-TLV registries for any TLVs which have 81 associated sub-TLVs. Note the meaning of a sub-TLV is scoped by the 82 TLV. The number spaces for the sub-TLVs of various TLVs are 83 independent. 85 However, it is under some conditions allowable for a new TLV to re- 86 use sub-TLVs of another TLV. In this case where all sub-TLVs are re- 87 used and no unique sub-TLVs are defined for the TLV re-uses the sub- 88 TLVs no actual sub-TLV registry is created for the new TLV. Rather 89 an entry is made where the registry would have appeared with a note 90 saying "Uses the sub-TLVs registered under TLV x", where x is the 91 other TLV. Note that the implication here is that all future sub- 92 TLVs of the other TLV apply, as well as those currently defined. 94 The valid range for TLV registry is 0-65535 and this is also default 95 for each of the sub-TLV registries. For all these registries, 96 assignments in the range 0-16383 and 32768-49161 are made via 97 Standards Action as defined in [IANA]; assignments in the range 98 16384-31743 and 49162-64511 are made via "Specification Required" as 99 defined above; values in the range 31744-32767 and 64512-65535 are 100 for Vendor Private Use, and MUST NOT be allocated. 102 However, a new TLV type might specify the allocation policies for its 103 own sub-TLVs. 105 2.1. Error codes for unrecognized TLV and sub-TLV types 107 For TLV and sub-TLV types that uses the default allocation ranges 108 defined above the rules for when error messages defined below 109 applies. TLVs that defines there own sub-TLV ranges, does also need 110 to define their own rules for when error messages are returned. 112 TLV and sub-TLV types less than 32768 (i.e., with the high-order bit 113 equal to 0) are mandatory TLVs that MUST either be supported by an 114 implementation or result in the return code of 2 ("One or more of the 115 TLVs was not understood") being sent in the echo response. 117 TLV and sub-TLV types greater than or equal to 32768 (i.e., with the 118 high-order bit equal to 1) are optional TLVs that SHOULD be ignored 119 if the implementation does not understand or support them. 121 If a TLV or sub-TLV has a Type that falls in the range for Vendor 122 Private Use, the Length MUST be at least 4, and the first four octets 123 MUST be that vendor's SMI Private Enterprise Number, in network octet 124 order. The rest of the Value field is private to the vendor. 126 3. IANA Considerations 128 There are no requests for IANA actions in this document. 130 4. Security Considerations 132 This document is about updating the IANA section of RFC 4379 and does 133 not add any new security issues as compared to the the original RFC 134 4379. 136 5. Acknowledgements 138 6. Normative References 140 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 141 Requirement Levels", BCP 14, RFC 2119, March 1997. 143 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 144 Label Switched (MPLS) Data Plane Failures", RFC 4379, 145 February 2006. 147 Author's Address 149 Loa Andersson 150 Huawei 152 Email: loa@mail01.huawei.com