idnits 2.17.1 draft-dhody-pce-pcep-exp-codepoints-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2017) is 2558 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 informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track D. King 5 Expires: September 28, 2017 Lancaster University 6 March 27, 2017 8 Experimental Codepoint Allocation for Path Computation Element 9 communication Protocol (PCEP) 10 draft-dhody-pce-pcep-exp-codepoints-03 12 Abstract 14 IANA assigns values to the Path Computation Element (PCE) 15 communication Protocol (PCEP) parameters (messages, objects, TLVs). 16 IANA established a new top-level registry to contain all PCEP 17 codepoints and sub-registries. The allocation policy for each new 18 registry is by IETF Consensus. 20 This document seeks to mark some codepoints for experimental usage of 21 PCEP. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 28, 2017. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 5. Handling of unknown experimentation . . . . . . . . . . . . . 3 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 69 6.1. New PCEP Messages . . . . . . . . . . . . . . . . . . . . 4 70 6.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . 4 71 6.3. New PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . 4 72 7. Allocation Policy . . . . . . . . . . . . . . . . . . . . . . 5 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 77 10.2. Informative References . . . . . . . . . . . . . . . . . 5 78 Appendix A. Other Codepoints . . . . . . . . . . . . . . . . . . 6 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 81 1. Introduction 83 The Path Computation Element communication Protocol (PCEP) provides 84 mechanisms for Path Computation Elements (PCEs) to perform path 85 computations in response to Path Computation Clients (PCCs) requests. 87 In section 9 of [RFC5440], IANA assigns values to the PCEP protocol 88 parameters (messages, objects, TLVs). IANA established a new top- 89 level registry to contain all PCEP codepoints and sub-registries. 90 The allocation policy for each new registry is by IETF Consensus as 91 described in [RFC5226]. Specifically, new assignments are made via 92 RFCs approved by the IESG. Typically, the IESG will seek input on 93 prospective assignments from appropriate persons (e.g., a relevant 94 Working Group if one exists). Early allocation [RFC7120] provides 95 some latitude for allocation of these code points, but is reserved 96 for features that are considered appropriately stable. 98 With some recent advancement, there is an enhanced need to experiment 99 with PCEP. It is often necessary to use some sort of number or 100 constant in order to actually test or experiment with the new 101 function, even when testing in a closed environment. In order to run 102 experiment, it is important that the value won't collide not only 103 with existing codepoints but any future allocation. 105 This document thus set apart some codepoints in PCEP registry and 106 subregistries for experimental usage. 108 2. PCEP Messages 110 Some codepoints are requested to be set aside for experimentation 111 with new PCEP messages. The suggested range is 246-255. 113 3. PCEP Objects 115 Some codepoints are requested to be set aside for experimentation 116 with new PCEP objects. The suggested range is 224-255. 118 4. PCEP TLVs 120 Some codepoints are requested to be set aside for experimentation 121 with new PCEP TLVs. The suggested range is 65280-65535. 123 5. Handling of unknown experimentation 125 A PCEP implementation that receives an experimental PCEP message, 126 that it does not recognize, would react as per section 6.9 of 127 [RFC5440] by sending a PCErr message with Error-value=2 (capability 128 not supported). 130 A PCE that does not recognize an experimental PCEP object, MUST 131 reject the entire PCEP message and MUST send a PCE error message with 132 Error- Type="Unknown Object" or "Not supported object", defined as 133 per [RFC5440]. 135 As per section 7.1 of [RFC5440], unknown experimental PCEP TLV would 136 be ignored. 138 6. IANA Considerations 140 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 141 at . 143 6.1. New PCEP Messages 145 Within this registry IANA maintains a sub-registry for PCEP Messages 146 (see PCEP Messages at ). 148 Upon approval of this document, IANA is requested to make the 149 following allocations: 151 +---------+-------------+-------------------+ 152 | Type | Description | Allocation Policy | 153 +---------+-------------+-------------------+ 154 | 246-255 | Unassigned | Experimental Use | 155 +---------+-------------+-------------------+ 157 6.2. New PCEP Objects 159 Within this registry IANA maintains a sub-registry for PCEP Objects 160 (see PCEP Objects at ). 162 Upon approval of this document, IANA is requested to make the 163 following allocations: 165 +---------+-------------+-------------------+ 166 | Type | Description | Allocation Policy | 167 +---------+-------------+-------------------+ 168 | 224-255 | Unassigned | Experimental Use | 169 +---------+-------------+-------------------+ 171 6.3. New PCEP TLVs 173 Within this registry IANA maintains a sub-registry for PCEP TLVs (see 174 PCEP TLV Type Indicators at ). 176 Upon approval of this document, IANA is requested to make the 177 following allocations: 179 +------------+-------------+-------------------+ 180 | Type | Description | Allocation Policy | 181 +------------+-------------+-------------------+ 182 |65280-65535 | Unassigned | Experimental Use | 183 +------------+-------------+-------------------+ 185 7. Allocation Policy 187 The allocation policy for the IANA request in Section 6 is 188 "Experimental". As per [RFC5226], IANA does not record specific 189 assignments for any particular use for this policy. 191 As the experiment/standard progress and an early IANA allocation or 192 RFC publication happens, the IANA defined codepoints are used and 193 experimental code points are freed up. 195 8. Security Considerations 197 This document does not introduce any new security considerations to 198 the existing protocol. Refer to [RFC5440] for further details of the 199 specific security measures. 201 9. Acknowledgments 203 The authors would like to thank Ramon Casellas, Jeff Tantsura, Adrian 204 Farrel, Jonathan Hardwick, Julien Mueric, Lou Berger, Michael Shroff, 205 and Andrew Dolganow for their feedback and suggestions. 207 10. References 209 10.1. Normative References 211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 212 Requirement Levels", BCP 14, RFC 2119, 213 DOI 10.17487/RFC2119, March 1997, 214 . 216 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 217 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 218 DOI 10.17487/RFC5440, March 2009, 219 . 221 10.2. Informative References 223 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 224 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 225 DOI 10.17487/RFC5226, May 2008, 226 . 228 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 229 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 230 2014, . 232 Appendix A. Other Codepoints 234 Based on the feedback from the WG, it was decided to focus only on 235 the essentials in the scope of this documents. For others, 236 Experiments can use a new experimental TLV/Object instead. 238 Authors' Addresses 240 Dhruv Dhody 241 Huawei Technologies 242 Divyashree Techno Park, Whitefield 243 Bangalore, Karnataka 560066 244 India 246 EMail: dhruv.ietf@gmail.com 248 Daniel King 249 Lancaster University 250 UK 252 EMail: d.king@lancaster.ac.uk