idnits 2.17.1 draft-kompella-mpls-reserved-labels-01.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 document seems to lack a Security Considerations section. -- The draft header indicates that this document updates RFC3032, 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 RFC3032, updated by this document, for RFC5378 checks: 1997-11-20) -- 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 (September 28, 2012) is 4227 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella 3 Internet-Draft Contrail Systems 4 Updates: 3032 (if approved) September 28, 2012 5 Intended status: Standards Track 6 Expires: April 1, 2013 8 Allocating and Retiring MPLS Reserved Labels 9 draft-kompella-mpls-reserved-labels-01 11 Abstract 13 There are a limited number of reserved labels defined for Multi- 14 Protocol Label Switching. Thus one must be cautious in the 15 allocation of new reserved labels, yet at the same time allow forward 16 progress when a new reserved label is called for. This memo suggests 17 some procedures to follow in the allocation and retirement of 18 reserved labels. 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 http://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 April 1, 2013. 37 Copyright Notice 39 Copyright (c) 2012 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Conventions used . . . . . . . . . . . . . . . . . . . . . 3 56 2. Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Normative References . . . . . . . . . . . . . . . . . . . . . 7 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 1. Introduction 64 [RFC3032] defined four reserved label values for Multi-Protocol Label 65 Switching (MPLS), namely, 0 to 3, and set aside values 4 through 15 66 for future use. These labels have special significance in both the 67 control and data plane. Since then, two further values have been 68 allocated, leaving ten unassigned values from the original space of 69 sixteen. 71 While the allocation of two out of the remaining twelve reserved 72 label values in the space of about 12 years is not in itself a cause 73 for concern, the scarcity of reserved labels is. Furthermore, many 74 of the reserved labels require special processing by forwarding 75 hardware, changes to which are often expensive, and sometimes 76 impossible. Thus, documenting a newly allocated reserved label value 77 is important. 79 This memo outlines some of the issues in allocating and retiring 80 reserved label values, and will eventually suggest mechanisms to 81 address these. Furthermore, this memo proposes a means of extending 82 the space of reserved labels. 84 1.1. Conventions used 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 2. Questions 92 1. How should reserved labels be allocated? The current IANA number 93 space for "MPLS Label Values" has the allocation policy of "IETF 94 Consensus". Would "Expert Review" be better? Should the name of 95 this space be changed to reflect its use? Should there be Early 96 Allocation? Experimental Use? Private Use? 98 2. What documentation is required for reserved labels allocated 99 henceforth? 101 3. Should a reserved label ever be retired? What criteria are 102 relevant here? What procedures and time frames are appropriate? 104 4. The reserved label value of 3 is only used in signaling, never in 105 the data plane. Could it (and should it) be used in the data 106 plane? If so, how? 108 5. What is a feasible mechanism to extend the space of reserved 109 labels, should this become necessary? 111 3. Proposal 113 To answer question 5 from the previous section, the following 114 proposal is made: set aside label value 15 (the "extension" label) 115 for the purpose of extending the space of reserved labels. An 116 extension label 15 MUST be followed by another label L (and thus MUST 117 have the bottom-of-stack bit clear). L MUST be interpreted as an 118 "extended reserved label". Furthermore, the interpretation and 119 special processing of such labels MUST be documented, and they MUST 120 be registered with IANA (policies TBD). 122 A further question to be settled in this regard is whether a "plain" 123 reserved label retains its meaning if it follows the extension label. 124 That is, does a label value of 0 mean "Explicit IPv4 NULL" whether or 125 not it is preceded by an extension label? The suggestion here is 126 "yes" for the currently allocated reserved labels (i.e., 0-3, 7, 13, 127 and 14). The documentation accompanying a newly allocated reserved 128 label MUST say whether or not it retains its meaning if preceded by 129 the extension label. 131 4. IANA Considerations 133 There is already an IANA registry for MPLS label values. This memo 134 may eventually suggest: 136 1. a change in the name of the registry to "Reserved MPLS Label 137 Values 139 2. some changes to the procedures for allocating values 141 3. a new registry for "Extended Reserved MPLS Label Values". 143 5. Normative References 145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 146 Requirement Levels", BCP 14, RFC 2119, March 1997. 148 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 149 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 150 Encoding", RFC 3032, January 2001. 152 Author's Address 154 Kireeti Kompella 155 Contrail Systems 156 2350 Mission College Blvd. 157 Santa Clara, CA 95054 158 US 160 Email: kireeti.kompella@gmail.com