Allowing Experimental Error Codes in the Path Computation Element Protocol
draft-farrel-pce-experimental-errors-01

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,
              <https://www.rfc-editor.org/info/rfc5440>.

   [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,
              <https://www.rfc-editor.org/info/rfc8356>.

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, <https://datatracker.ietf.org/doc/html/
              draft-ietf-pce-pceps-tls13-04>.

   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
              Considered Useful", BCP 82, RFC 3692,
              DOI 10.17487/RFC3692, January 2004,
              <https://www.rfc-editor.org/info/rfc3692>.

   [RFC6709]  Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
              Considerations for Protocol Extensions", RFC 6709,
              DOI 10.17487/RFC6709, September 2012,
              <https://www.rfc-editor.org/info/rfc6709>.

   [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,
              <https://www.rfc-editor.org/info/rfc8126>.

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]