PCE Working Group A. Farrel Internet-Draft Old Dog Consulting Updates: 5540 (if approved) H. Zheng Intended status: Standards Track Huawei Technologies Expires: 16 October 2024 14 April 2024 Allowing Experimental Error Codes in the Path Computation Element Protocol draft-farrel-pce-experimental-errors-01 Abstract Experimental RFCs are often considered beneficial approaches to developing new protocol features. To that end, sub-ranges of code point registries are often designated as for experimental use. IANA assigns values to the Path Computation Element Communication Protocol (PCEP) parameters (messages, objects, TLVs). According to RFC 5440 as updated by RFC 8356, the allocation policies for the registries for PCEP messages, objects, and TLV types are IETF Review with some sub-ranges of these registries being assigned for Experimental Use. However, the registry of PCEP Error-Types and Error-values has only the IETF Review assignment policy meaning that experimentation is somewhat limited. This document updates RFC 5440 by designating a range of PCEP Error- Types for Experimental Use. 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 https://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 16 October 2024. Farrel & Zheng Expires 16 October 2024 [Page 1] Internet-Draft PCEP Experimental Error Codes April 2024 Copyright Notice Copyright (c) 2024 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Consideration of RFC 8356 . . . . . . . . . . . . . . . . 3 2. Experimental Error-Types . . . . . . . . . . . . . . . . . . 3 3. Advice on Experimentation . . . . . . . . . . . . . . . . . . 4 4. Handling of Unknown Experimentation . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. Manageability Considerations . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The Path Computation Element Communication Protocol (PCEP) [RFC5440] provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests or autonomously. The computed paths are used when provisioning connectivity through Traffic Engineered networks. In Section 9 of [RFC5440], IANA assigns values to the PCEP parameters. The allocation policy for each of these parameters specified in RFC 5440 is IETF Review [RFC8126]. In consideration of the benefits of making experiments with PCEP and the utility of experimental codepoints [RFC3692], codepoint ranges for PCEP messages, objects, and TLV types for Experimental Use [RFC8126] are designated in [RFC8356]. Farrel & Zheng Expires 16 October 2024 [Page 2] Internet-Draft PCEP Experimental Error Codes April 2024 However, protocol experiments may also need to return protocol error messages indicating experiment-specific error cases. It will often be the case that previously assigned error codes (in the PCEP-ERROR Object Error Types and Values sub-registry) can be used to indicate the error cases within an experiment, but there may also be cases where new, experimental error codes are needed. In order to run experiments, it is important that the codepoint values used in the experiments do not collide with existing codepoints or any future allocations. This document updates [RFC5440] by changing the allocation policy for the registry of PCEP Error-Types to mark some of the codepoints as assigned for Experimental Use. As stated in [RFC3692], experiments using these codepoints are not intended to be used in general deployments, and due care must be taken to ensure that two experiments using the same codepoints are not run in the same environment. 1.1. Consideration of RFC 8356 It is worth noting that [RFC8356] deliberately chose to make experimental codepoints available only in the PCEP message, objects, and TLV types registries. Appendix A of that document gives a brief explanation of why that decision was taken stating that, "The justification for this decision is that, if an experiment finds that it wants to use a new codepoint in another PCEP sub-registry, it can implement the same function using a new experimental object or TLV instead." While it is true that an experimental implementation could assign an experimental PCEP object and designate it the "experimental errors object", using it to carry arbitrary contents including experimental error codes, such an approach would cause unnecessary divergence in the code. The allowance of experimental Error-Types is considered a better approach that will more easily enable migration of successful experiments on to the Standards Track. 2. Experimental Error-Types This document allows for the designation of four PCEP Error-Type codepoints (252-255) for Experimental Use. Section 5 provides the IANA considerations for this designation. Section 3 gives advice about how to construct an experiment using these codepoints. Farrel & Zheng Expires 16 October 2024 [Page 3] Internet-Draft PCEP Experimental Error Codes April 2024 3. Advice on Experimentation An experiment that wishes to return experimental error codes should use one of the experimental Error-Type values as defined in this document. The experiment should agree, between all participating parties, which Error-Type to use and which Error-values to use within that Error-Type. The experiment will describe what the meanings of those Error-Type / Error-value pairs are. Those Error-Type and Error-values should not be recorded in any public (especially any IETF) documentation. Textual or symbolic names for the Error-Types and Error-values may be used to help keep the documentation clear. If multiple experiments are taking place at the same time using the same implementations, care must be taken to keep the sets of Error- Type / Error-value distinct. Note that there is no scope for experimental Error-values within existing non-experimental Error-Types. This reduces the complexity of the registry and of implementation. Experiments should place all experimental Error-values under the chosen experimental Error-Types. If, at some future time, the experiment is declared a success and moved to IETF work targeting publication with IETF consensus, each pair of Error-Type / Error-value will need to be assigned by IANA from the registry. In some cases, this will involve assigning a new Error-Type with its subtended Error-values. In other case, use may be made of an existing Error-Type with new subtended Error-values being assigned. The resulting change to code in an implementation is as simple as changing the numeric values of the Error-Types and Error-values. 4. Handling of Unknown Experimentation A PCEP implementation that receives an experimental Error-Type in a PCEP message and does not recognise the Error-Type (i.e., is not part of the experiment) will treat the error as it would treat any other unknown Error-Type (such as from a new protocol extension). An implementation that is notified of a PCEP error will normally close the PCEP session (see [RFC5440]). In general, PCEP implementations are not required to take specific action based on Error-Types, but may log the errors for diagnostic purposes. An implementation that is part of an experiment may receive an experimental Error-Type, but not recognise the Error-value. This could happen because of any of: * A faulty implementation. Farrel & Zheng Expires 16 October 2024 [Page 4] Internet-Draft PCEP Experimental Error Codes April 2024 * Two implementations not being synchronised with respect to which Error-values to use in the experiment. * More than one experiment being run at the same time. As with unknown Error-Types, an implementation receiving an unknown Error-value is not expected to do more than log the received error, and may close the PCEP session. 5. IANA Considerations IANA maintains a registry called "Path Computation Element Protocol (PCEP) Numbers" with a sub-registry named "PCEP-ERROR Object Error Types and Values". IANA is requested to change the assignment policy for this sub-registry to read: * Error-Types - 0-251 : IETF Review - 252-255 : Experimental Use * Error-value - For all IETF Review Error-Types : IETF Review - For all Experimental Use Error-Types : Experimental Use Additionally, IANA is requested to make an entry in the table as follows: Error-Type | Meaning | Error-value | Reference -----------+--------------------+------------------------+----------- 252-255 | Experimental Use | 0-255 Experimental Use | [this.I-D] | Not to be assigned | Not to be assigned | 6. Security Considerations This document does not introduce any new security considerations to the existing protocol. Refer to [RFC5440] and [I-D.ietf-pce-pceps-tls13] for further details of the specific security measures applicable to PCEP. [RFC3692] asserts that the existence of experimental codepoints introduces no new security considerations. However, implementations accepting experimental error codepoints need to take care in how they Farrel & Zheng Expires 16 October 2024 [Page 5] Internet-Draft PCEP Experimental Error Codes April 2024 parse and process them in case they come, accidentally, from another experiment. Further, an implementation accepting experimental codepoints needs to consider the security aspects of the experimental extensions. [RFC6709] provides various design considerations for protocol extensions (including those designated as experimental). 7. Manageability Considerations The main manageability impacts of this work are as follows: * Implementations participating in any experiment should be made such that the Error-Type and Error-value numbers can be easily changed. This will enable quick modification if there are any collisions with other experiments. * All implementations that receive and report Error-Types and Error- values (including protocol analysers) should report numeric values and state "unknown" if they do not know a specific interpretation of an error. This is not a new requirement or behavior, but is called out here as it is important for this case. 8. Acknowledgements Thanks to Dhruv Dhody for discussions that led to the creation of this document. 9. References 9.1. Normative References [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC8356] Dhody, D., King, D., and A. Farrel, "Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP)", RFC 8356, DOI 10.17487/RFC8356, March 2018, . 9.2. Informative References Farrel & Zheng Expires 16 October 2024 [Page 6] Internet-Draft PCEP Experimental Error Codes April 2024 [I-D.ietf-pce-pceps-tls13] Dhody, D., Turner, S., and R. Housley, "Updates for PCEPS: TLS Connection Establishment Restrictions", Work in Progress, Internet-Draft, draft-ietf-pce-pceps-tls13-04, 9 January 2024, . [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, . [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, DOI 10.17487/RFC6709, September 2012, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Authors' Addresses Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Haomian Zheng Huawei Technologies Email: zhenghaomian@huawei.com Farrel & Zheng Expires 16 October 2024 [Page 7]