Network Working Group L. Andersson Internet-Draft Huawei Updates: 4379 (if approved) July 15, 2013 Intended status: Standards Track Expires: January 16, 2014 Updates to RFC 4379 IANA section draft-andersson-mpls-lsp-ping-upd-00 Abstract The MultiProtocol Label Switching (MPLS) protcol for detecting Label Switched Path failures (LSP Ping), as defined in RFC 4379 and several extensions, are widely deployed and very popular. The IANA sectiion of RFC4379 lack in clarity and need to be updated. 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 January 16, 2014. 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 Andersson Expires January 16, 2014 [Page 1] Internet-Draft LSP Ping IANA section Updates July 2013 (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. Update of the RCF 4379 IANA section . . . . . . . . . . . . . 2 2.1. Error codes for unrecognized TLV and sub-TLV types . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 6. Normative References . . . . . . . . . . . . . . . . . . . . 3 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction This document updates the IANA section of RFC 4379 [RFC4379] for LSP Ping Parameters. 2. Update of the RCF 4379 IANA section The first 3 paragraphs of sub-section 7.2. "TLVs" in the IANA section of RFC 4379 is considered unclear and is therefore now replaced by the following text: The IANA has created and will maintain a registry for the Type field of top-level TLVs and per-TLV registries for any TLVs which have associated sub-TLVs. Note the meaning of a sub-TLV is scoped by the TLV. The number spaces for the sub-TLVs of various TLVs are independent. However, it is under some conditions allowable for a new TLV to re- use sub-TLVs of another TLV. In this case where all sub-TLVs are re- used and no unique sub-TLVs are defined for the TLV re-uses the sub- TLVs no actual sub-TLV registry is created for the new TLV. Rather an entry is made where the registry would have appeared with a note saying "Uses the sub-TLVs registered under TLV x", where x is the other TLV. Note that the implication here is that all future sub- TLVs of the other TLV apply, as well as those currently defined. The valid range for TLV registry is 0-65535 and this is also default for each of the sub-TLV registries. For all these registries, assignments in the range 0-16383 and 32768-49161 are made via Andersson Expires January 16, 2014 [Page 2] Internet-Draft LSP Ping IANA section Updates July 2013 Standards Action as defined in [IANA]; assignments in the range 16384-31743 and 49162-64511 are made via "Specification Required" as defined above; values in the range 31744-32767 and 64512-65535 are for Vendor Private Use, and MUST NOT be allocated. However, a new TLV type might specify the allocation policies for its own sub-TLVs. 2.1. Error codes for unrecognized TLV and sub-TLV types For TLV and sub-TLV types that uses the default allocation ranges defined above the rules for when error messages defined below applies. TLVs that defines there own sub-TLV ranges, does also need to define their own rules for when error messages are returned. TLV and sub-TLV types less than 32768 (i.e., with the high-order bit equal to 0) are mandatory TLVs that MUST either be supported by an implementation or result in the return code of 2 ("One or more of the TLVs was not understood") being sent in the echo response. TLV and sub-TLV types greater than or equal to 32768 (i.e., with the high-order bit equal to 1) are optional TLVs that SHOULD be ignored if the implementation does not understand or support them. If a TLV or sub-TLV has a Type that falls in the range for Vendor Private Use, the Length MUST be at least 4, and the first four octets MUST be that vendor's SMI Private Enterprise Number, in network octet order. The rest of the Value field is private to the vendor. 3. IANA Considerations There are no requests for IANA actions in this document. 4. Security Considerations This document is about updating the IANA section of RFC 4379 and does not add any new security issues as compared to the the original RFC 4379. 5. Acknowledgements 6. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Andersson Expires January 16, 2014 [Page 3] Internet-Draft LSP Ping IANA section Updates July 2013 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. Author's Address Loa Andersson Huawei Email: loa@mail01.huawei.com Andersson Expires January 16, 2014 [Page 4]