diff options
Diffstat (limited to 'doc/rfc/rfc8356.txt')
| -rw-r--r-- | doc/rfc/rfc8356.txt | 395 |
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc8356.txt b/doc/rfc/rfc8356.txt new file mode 100644 index 0000000..dfefece --- /dev/null +++ b/doc/rfc/rfc8356.txt @@ -0,0 +1,395 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Dhody +Request for Comments: 8356 Huawei Technologies +Updates: 5440 D. King +Category: Standards Track Lancaster University +ISSN: 2070-1721 A. Farrel + Juniper Networks + March 2018 + + + Experimental Codepoint Allocation for + the Path Computation Element Communication Protocol (PCEP) + +Abstract + + IANA assigns values to the Path Computation Element Communication + Protocol (PCEP) parameters (messages, objects, TLVs). IANA + established a top-level registry to contain all PCEP codepoints and + sub-registries. This top-level registry contains sub-registries for + PCEP message, object, and TLV types. The allocation policy for each + of these sub-registries is IETF Review. + + This document updates RFC 5440 by changing the allocation policies + for these three registries to mark some of the codepoints as assigned + for Experimental Use. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8356. + + + + + + + + + + + + + +Dhody, et al. Standards Track [Page 1] + +RFC 8356 Experimental Codepoints for PECP March 2018 + + +Copyright Notice + + Copyright (c) 2018 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 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. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Experimental PCEP Messages . . . . . . . . . . . . . . . . . 3 + 3. Experimental PCEP Objects . . . . . . . . . . . . . . . . . . 4 + 4. Experimental PCEP TLVs . . . . . . . . . . . . . . . . . . . 4 + 5. Handling of Unknown Experimentation . . . . . . . . . . . . . 4 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 + 6.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 4 + 6.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 5 + 6.3. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 + 8.2. Informative References . . . . . . . . . . . . . . . . . 6 + Appendix A. Other PCEP Registries . . . . . . . . . . . . . . . 7 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 + + + + + + +Dhody, et al. Standards Track [Page 2] + +RFC 8356 Experimental Codepoints for PECP March 2018 + + +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. + + Further, in order to support use cases described in [RFC8051], + [RFC8231] specifies a set of extensions to PCEP to enable stateful + control of MPLS-TE and GMPLS LSPs via PCEP. [RFC8281] describes the + setup, maintenance, and teardown of PCE-initiated LSPs under the + stateful PCE model. + + In Section 9 of [RFC5440], IANA assigns values to the PCEP protocol + parameters (messages, objects, TLVs). IANA established a top-level + registry to contain all PCEP codepoints and sub-registries. This + top-level registry contains sub-registries for PCEP message, object + and TLV types. The allocation policy for each of these sub- + registries is IETF Review [RFC8126]. Also, early allocation + [RFC7120] provides some latitude for allocation of these codepoints + but is reserved for features that are considered appropriately + stable. + + Recently, there have been rapid advancements in PCE technology, which + has created an enhanced need to experiment with PCEP. It is often + necessary to use some sort of number or constant in order to actually + test or experiment with the new function, even when testing in a + closed environment. In order to run experiments, it is important + that the value not collide with existing codepoints or any future + allocations. + + This document updates [RFC5440] by changing the allocation policies + for these three registries 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. See [RFC3692] + for further discussion of the use of experimental codepoints (also + referred to as "experimental and testing numbers"). + +2. Experimental PCEP Messages + + PCEP message types are in the range 0 to 255. This document sets + aside message types 252-255 for experimentation as described in + Section 6.1. + + + + + + +Dhody, et al. Standards Track [Page 3] + +RFC 8356 Experimental Codepoints for PECP March 2018 + + +3. Experimental PCEP Objects + + PCEP objects are identified by values in the range 0 to 255. This + document sets aside object identifiers 248-255 for experimentation as + described in Section 6.2. + +4. Experimental PCEP TLVs + + PCEP TLV type codes are in the range 0 to 65535. This document sets + aside object identifiers 65504-65535 for experimentation as described + in Section 6.2. + +5. Handling of Unknown Experimentation + + A PCEP implementation that receives an experimental PCEP message that + it does not recognize reacts by sending a PCErr message with + Error-Type=2 (capability not supported) per Section 6.9 of [RFC5440]. + + If a PCEP speaker does not understand or support an experimental + object, then the way it handles this situation depends on the message + type. For example, a PCE handles an unknown object in the Path + Computation Request (PCReq) message according to the rules of + [RFC5440]. Message-specific behavior may be specified (e.g., + [RFC8231] defines rules for a PCC to handle an unknown object in a + Path Computation LSP Update Request (PCUpd) message). + + As per Section 7.1 of [RFC5440], an unknown experimental PCEP TLV + would be ignored. + +6. IANA Considerations + + IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" + registry at <http://www.iana.org/assignments/pcep>. + +6.1. PCEP Messages + + Within the PCEP Numbers registry, IANA maintains the "PCEP Messages" + sub-registry. + + IANA has changed the registration procedure for this registry to read + as follows: + + 0-251 IETF Review + 252-255 Experimental Use + + IANA has also marked the values 252-255 in the registry accordingly. + + + + + +Dhody, et al. Standards Track [Page 4] + +RFC 8356 Experimental Codepoints for PECP March 2018 + + +6.2. PCEP Objects + + Within the PCEP Numbers registry, IANA maintains the "PCEP Objects" + sub-registry. + + IANA has changed the registration procedure for this registry to read + as follows: + + 0-247 IETF Review + 248-255 Experimental Use + + IANA has also marked the values 248-255 in the registry accordingly, + and Object-Types 0-15 have been marked for Experimental Use. + +6.3. PCEP TLVs + + Within the PCEP Numbers registry, IANA maintains the "PCEP TLV Type + Indicators" sub-registry. + + IANA has changed the registration procedure for this registry to read + as follows: + + 0-65503 IETF Review + 65504-65535 Experimental Use + + IANA has also marked the values 65504-65535 in the registry + accordingly. + +7. Security Considerations + + This document does not introduce any new security considerations to + the existing protocol. Refer to [RFC5440] for further details of the + specific security measures. + + [RFC3692] asserts that the existence of experimental codepoints + introduce no new security considerations. However, implementations + accepting experimental codepoints need to take care in how they parse + and process the messages, objects, and TLVs 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). + + + + + + + + +Dhody, et al. Standards Track [Page 5] + +RFC 8356 Experimental Codepoints for PECP March 2018 + + +8. References + +8.1. Normative References + + [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>. + + [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>. + + [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>. + + [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path + Computation Element Communication Protocol (PCEP) + Extensions for Stateful PCE", RFC 8231, + DOI 10.17487/RFC8231, September 2017, + <https://www.rfc-editor.org/info/rfc8231>. + + [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path + Computation Element Communication Protocol (PCEP) + Extensions for PCE-Initiated LSP Setup in a Stateful PCE + Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, + <https://www.rfc-editor.org/info/rfc8281>. + +8.2. Informative References + + [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>. + + [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code + Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January + 2014, <https://www.rfc-editor.org/info/rfc7120>. + + [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a + Stateful Path Computation Element (PCE)", RFC 8051, + DOI 10.17487/RFC8051, January 2017, + <https://www.rfc-editor.org/info/rfc8051>. + + + + + +Dhody, et al. Standards Track [Page 6] + +RFC 8356 Experimental Codepoints for PECP March 2018 + + +Appendix A. Other PCEP Registries + + Based on feedback from the PCE WG, it was decided to allocate an + Experimental codepoint range only in the message, object, and TLV + sub-registries. 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. + +Acknowledgments + + The authors would like to thank Ramon Casellas, Jeff Tantsura, Julien + Meuric, Lou Berger, Michael Shroff, and Andrew Dolganow for their + feedback and suggestions. + + We would like to thank Jonathan Hardwick for shepherding this + document and providing comments with text suggestions. + + Thanks to Brian Carpenter for the GENART review. Thanks to Ben + Niven-Jenkins and Scott Bradner for RTGDIR and OPSDIR reviews + respectively. + +Authors' Addresses + + Dhruv Dhody + Huawei Technologies + Divyashree Techno Park, Whitefield + Bangalore, Karnataka 560066 + India + + EMail: dhruv.ietf@gmail.com + + + Daniel King + Lancaster University + United Kingdom + + EMail: d.king@lancaster.ac.uk + + + Adrian Farrel + Juniper Networks + United Kingdom + + EMail: afarrel@juniper.net + + + + + + +Dhody, et al. Standards Track [Page 7] + |