Internet Engineering Task Force (IETF) E. Crabbe Request for Comments: 8281 Individual Contributor Category: Standards Track I. Minei ISSN: 2070-1721 Google, Inc. S. Sivabalan Cisco Systems, Inc. R. Varga Pantheon Technologies SRO December 2017 Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model
AbstractThe Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. 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/rfc8281.
Copyright Notice Copyright (c) 2017 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.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 5 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Operation Overview . . . . . . . . . . . . . . . . . . . 6 4. Support of PCE-Initiated LSPs . . . . . . . . . . . . . . . . 7 4.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 8 5. PCE-Initiated LSP Instantiation and Deletion . . . . . . . . 8 5.1. The LSP Initiate Request . . . . . . . . . . . . . . . . 8 5.2. The R Flag in the SRP Object . . . . . . . . . . . . . . 10 5.3. LSP Instantiation . . . . . . . . . . . . . . . . . . . . 10 5.3.1. The Create Flag . . . . . . . . . . . . . . . . . . . 12 5.3.2. The SPEAKER-ENTITY-ID TLV . . . . . . . . . . . . . . 13 5.4. LSP Deletion . . . . . . . . . . . . . . . . . . . . . . 13 6. LSP Delegation and Cleanup . . . . . . . . . . . . . . . . . 14 7. LSP State Synchronization . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 15 8.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 15 8.3. SRP object . . . . . . . . . . . . . . . . . . . . . . . 16 8.4. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 16 8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 18 9.2. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 19 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
RFC5440] describes the Path Computation Element Communication Protocol (PCEP). PCEP defines the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between PCE and PCE, enabling computation of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP) characteristics. [RFC8231] specifies a set of extensions to PCEP to enable stateful control of TE LSPs between and across PCEP sessions in compliance with [RFC4657]. It includes: o mechanisms to effect LSP State Synchronization between PCCs and PCEs o delegation of control of LSPs to PCEs o PCE control of timing and sequence of path computations within and across PCEP sessions It focuses on a model where LSPs are configured on the PCC, and control over them is delegated to the PCE. This document describes the setup, maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model, without the need for local configuration on the PCC, thus allowing for a dynamic network that is centrally controlled and deployed. RFC5440]: PCC, PCE, and PCEP Peer. This document uses the following terms defined in [RFC8051]: Stateful PCE and Delegation. This document uses the following terms defined in [RFC8231]: Redelegation Timeout Interval, State Timeout Interval, LSP State Report, and LSP Update Request. The following terms are defined in this document: PCE-initiated LSP: LSP that is instantiated as a result of a request from the PCE. The message formats in this document are specified using Routing Backus-Naur Form (RBNF) encoding as specified in [RFC5511].
RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. RFC8231] provides active control over LSPs that are locally configured on the PCC. This model relies on the Label Edge Router (LER) taking an active role in delegating locally configured LSPs to the PCE and is well suited in environments where the LSP placement is fairly static. However, in environments where the LSP placement needs to change in response to application demands, it is useful to support dynamic creation and teardown of LSPs. The ability for a PCE to trigger the creation of LSPs on demand can be seamlessly integrated into a controller-based network architecture, where intelligence in the controller can determine when and where to set up paths. A possible use case is a software-defined network, where applications request network resources and paths from the network infrastructure. For example, an application can request a path with certain constraints between two Label Switching Routers (LSRs) by contacting the PCE. The PCE can compute a path satisfying the constraints, and instruct the head end LSR to instantiate and signal it. When the path is no longer required by the application, the PCE can request its teardown. Another use case is dynamically adjusting aggregate bandwidth between two points in the network using multiple LSPs. This functionality is very similar to auto-bandwidth, but it allows for providing the desired capacity through multiple LSPs. This approach overcomes two of the limitations auto-bandwidth can experience: 1) growing the capacity between the endpoints beyond the capacity of individual links in the path and 2) achieving good bin packing through use of several small LSPs instead of a single large one. The number of LSPs varies based on the demand, and LSPs are created and deleted dynamically to satisfy the bandwidth requirements.
Another use case is demand engineering, where a PCE with visibility into both the network state and the demand matrix can anticipate and optimize how traffic is distributed across the infrastructure. Such optimizations may require creating new paths across the infrastructure. Section 4.1). A PCC or PCE sets this flag in the Open message during the PCEP initialization phase to indicate that it supports the procedures of this document. This document defines a new PCEP message, the LSP Initiate Request (PCInitiate) message, which a PCE can send to a PCC to request the initiation or deletion of an LSP. The decision when to instantiate or delete a PCE-initiated LSP is out of the scope of this document. The PCE sends a PCInitiate message to the PCC to request the initiation of an LSP. The PCC creates the LSP using the attributes communicated by the PCE and local values for any unspecified parameters. The PCC generates a Path Computation State Report (PCRpt) for the LSP, carrying a newly assigned PLSP-ID for the LSP and delegating the LSP to the PCE via the Delegate flag in the LSP object. The PCE can update the attributes of the LSP by sending subsequent Path Computation Update Request (PCUpd) messages. Subsequent PCRpt and PCUpd messages that the PCC and PCE, respectively, send for the LSP will carry the PCC-assigned PLSP-ID, which uniquely identifies the LSP. See details in Section 5.3. The PCE sends a PCInitiate message to the PCC to request the deletion of an LSP. To indicate a delete operation, this document defines the new R flag in the Stateful PCE Request Parameter (SRP) object in the PCInitiate message, as described in Section 5.2. As a result of the deletion request, the PCC removes the LSP and sends a PCRpt for the removed state. See details in Section 5.4. Figure 1 illustrates these message exchanges.
+-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ | | |<--PCInitiate-------------------| (Initiate LSP) | | |---PCRpt, PLSP_ID=1, D=1------->| (Confirm initiation) | . | | . | | | |<--PCUpd, PLSP_ID=1-------------| (Update LSP) | | |---PCRpt, PLSP_ID=1, D=1------->| (Confirm update) | . | | . | | | |<--PCInitiate, PLSP_ID=1, R=1---| (Delete LSP) | | |---PCRpt, PLSP_ID=1, R=1------->| (Confirm delete) Figure 1: PCE-Initiated LSP Life Cycle RFC8231]. A new flag, the I (LSP-INSTANTIATION-CAPABILITY) flag, is introduced to this TLV to indicate support for instantiation of PCE-initiated LSPs. A PCE can initiate LSPs only for PCCs that advertised this capability. A PCC will follow the procedures described in this document only on sessions where the PCE advertised the I flag.
RFC8231] and included here for easy reference with the addition of the new I flag. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |I|S|U| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+ Figure 2: STATEFUL-PCE-CAPABILITY TLV Format A new flag is defined to indicate the sender's support for LSP instantiation by a PCE: I (LSP-INSTANTIATION-CAPABILITY -- 1 bit): If set to 1 by a PCC, the I flag indicates that the PCC allows instantiation of an LSP by a PCE. If set to 1 by a PCE, the I flag indicates that the PCE supports instantiating LSPs. The LSP-INSTANTIATION-CAPABILITY flag must be set by both the PCC and PCE in order to enable PCE-initiated LSP instantiation.
The format of a PCInitiate message is as follows: <PCInitiate Message> ::= <Common Header> <PCE-initiated-lsp-list> Where: <Common Header> is defined in RFC 5440 <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request> [<PCE-initiated-lsp-list>] <PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>| <PCE-initiated-lsp-deletion>) <PCE-initiated-lsp-instantiation> ::= <SRP> <LSP> [<END-POINTS>] <ERO> [<attribute-list>] <PCE-initiated-lsp-deletion> ::= <SRP> <LSP> Where: <attribute-list> is defined in RFC 5440 and extended by PCEP extensions. The LSP object is defined in [RFC8231]. The END-POINTS and Explicit Route Objects (EROs) are defined in [RFC5440]. The SRP object is defined in [RFC8231]. The SRP object contains an SRP-ID-number that is unique within a PCEP session. The PCE increments the last-used SRP-ID-number before it sends each PCInitiate message. The PCC MUST echo the value of the SRP-ID-number in PCEP Error (PCErr) and PCRpt messages that it sends as a result of the PCInitiate; this allows the PCE to correlate them with the corresponding PCInitiate message.
RFC8231] and included here for easy reference with the addition of the new R flag. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRP-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: The SRP Object Format A new flag is defined to indicate a delete operation initiated by the PCE: R (LSP-REMOVE -- 1 bit): If set to 0, it indicates a request to create an LSP. If set to 1, it indicates a request to remove an LSP.
The PCE MAY include various attributes as per [RFC5440]. The PCC MUST use these values in the LSP instantiation and local values for unspecified parameters. After the LSP setup, the PCC MUST send a PCRpt to the PCE, reflecting these values. The SRP object in the PCRpt message MUST echo the value of the PCInitiate message that triggered the setup. LSPs that were instantiated as a result of a PCInitiate message MUST have the Create flag (Section 5.3.1) set in the LSP object. If the PCC receives a PCInitiate message with a non-zero PLSP-ID and the R flag in the SRP object set to zero, then it MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=8 (Non-zero PLSP-ID in the LSP Initiate Request). If the PCC receives a PCInitiate message without an ERO and the R flag in the SRP object set to zero, then it MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=9 (ERO object missing). If the PCC receives a PCInitiate message without a SYMBOLIC-PATH-NAME TLV, then it MUST send a PCErr message with Error-type=10 (Reception of an invalid object) and Error-value=8 (SYMBOLIC-PATH-NAME TLV missing). The PCE MUST NOT provide a symbolic path name that conflicts with the symbolic path name of any existing LSP in the PCC. (Existing LSPs may be either statically configured or initiated by another PCE.) If there is a conflict with the symbolic path name of an existing LSP, the PCC MUST send a PCErr message with Error-type=23 (Bad Parameter value) and Error-value=1 (SYMBOLIC-PATH-NAME in use). The only exception to this rule is for LSPs for which the State Timeout Interval timer is running (see Section 6). If the PCC determines that the LSP parameters proposed in the PCInitiate message are unacceptable, it MUST send a PCErr message with Error-type=24 (PCE instantiation error) and Error-value=1 (Unacceptable instantiation parameters). If the PCC encounters an internal error during the processing of the PCInitiate message, it MUST send a PCErr message with Error-type=24 (PCE instantiation error) and Error-value=2 (Internal error). A PCC MUST relay errors it encounters in the setup of a PCE-initiated LSP to the PCE by sending a PCErr message with Error-type=24 (PCE instantiation error) and Error-value=3 (Signaling error). The PCErr message MUST echo the SRP-ID-number of the PCInitiate message. The PCEP-ERROR object SHOULD include the RSVP_ERROR_SPEC TLV (if an RSVP ERROR_SPEC object was returned to the PCC by a downstream node).
After the LSP is set up, errors in RSVP signaling are reported in PCRpt messages, as described in [RFC8231]. On successful completion of the LSP instantiation, the PCC MUST send a PCRpt message. The LSP object message MUST contain a non-zero PLSP-ID that uniquely identifies the LSP within this PCC and MUST have the Create flag (Section 5.3.1) and Delegate flag set. The SRP object MUST contain an SRP-ID-number that echoes the value from the PCInitiate message that triggered the setup. The PCRpt MUST include the attributes that the PCC used to instantiate the LSP. A PCC SHOULD be able to place a limit on either the number of LSPs or the percentage of resources that are allocated to honor PCE-initiated LSP requests. As soon as that limit is reached, the PCC MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=6 (PCE-initiated LSP limit reached) and is free to drop any incoming PCInitiate messages without additional processing. Similarly, the PCE SHOULD be able to place a limit on either the number of PCInitiate messages pending for a particular PCC or the time it waits for a response (positive or negative) to a PCInitiate message from a PCC, and it MAY take further action (such as closing the session or removing all its LSPs) if this limit is reached. RFC8231] and included here for easy reference with the addition of the new Create (C) flag. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PLSP-ID |Flags |C| O |A|R|S|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: The LSP Object Format A new flag, the C flag, is introduced. On a PCRpt message, the C flag set to 1 indicates that this LSP was created via a PCInitiate message. The C flag MUST be set to 1 on each PCRpt message for the LSP's duration of existence. The C flag allows PCEs to be aware of which LSPs were PCE initiated (a state that would otherwise only be known by the PCC and the PCE that initiated them).
RFC8232] MAY be included in the LSP object in a PCRpt message as an optional TLV for LSPs for which the C flag is 1. The SPEAKER-ENTITY-ID TLV identifies the PCE that initiated the creation of the LSP on all PCEP sessions, a state that would otherwise only be known by the PCC and the PCE that initiated the LSP. If the TLV appears in a PCRpt for an LSP for which the C flag is 0, the LSP MUST be ignored, and the PCE MUST send a PCErr message with Error-type=23 (Bad parameter value) and Error-value=2 (Speaker identity included for an LSP that is not PCE initiated). Section 5.2). A PLSP-ID of zero removes all LSPs with the C flag set to 1 (in their LSP object) that are delegated to the PCE. If the PLSP-ID is unknown, the PCC MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=3 (Unknown PLSP-ID) [RFC8231]. If the PLSP-ID specified in the PCInitiate message is not delegated to the PCE, the PCC MUST send a PCErr message with Error-type=19 (Invalid operation) and Error-value=1 (LSP is not delegated) [RFC8231]. If the PLSP-ID specified in the PCInitiate message was not created by a PCE, the PCC MUST send a PCErr message with Error-type=19 (Invalid operation) and Error-value=9 (LSP is not PCE initiated). Following the removal of the LSP, the PCC MUST send a PCRpt as described in [RFC8231]. The SRP object in the PCRpt MUST include the SRP-ID-number from the PCInitiate message that triggered the removal. The R flag in the SRP object MUST be set.
RFC8231]. The PCC MAY attempt to redelegate an orphaned LSP by following the procedures of [RFC8231]. Alternatively, if the orphaned LSP was PCE-initiated, then a PCE MAY obtain control over it, as follows. A PCE (either the original or one of its backups) sends a PCInitiate message that includes just the SRP and LSP objects and carries the PLSP-ID of the LSP it wants to take control of. If the PCC receives a PCInitiate message with a PLSP-ID pointing to an orphaned PCE-initiated LSP, then it MUST redelegate that LSP to the PCE. Any other non-zero PLSP-ID MUST result in the generation of a PCErr message using the rules described in Section 5.4. The State Timeout Interval timer for the LSP is stopped upon the redelegation. After obtaining control of the LSP, the PCE may remove it using the procedures described in this document. The State Timeout Interval timer ensures that a PCE crash does not result in automatic and immediate disruption for the services using PCE-initiated LSPs. PCE-initiated LSPs are not removed immediately upon PCE failure. Instead, they are cleaned up on the expiration of this timer. This allows for network cleanup without manual intervention. The PCC MUST support removal of PCE-initiated LSPs as one of the behaviors applied on expiration of the State Timeout Interval timer. The behavior MUST be picked based on local policy and can result in either LSP removal or reverting to operator-defined default parameters.
Section 5.6 of [RFC8231]. During State Synchronization, a PCC reports the state of its LSPs to the PCE using PCRpt messages, setting the SYNC flag in the LSP object. For PCE-initiated LSPs, the PCC MUST also set the Create flag in the LSP object and MAY include the SPEAKER-ENTITY-ID TLV identifying the PCE that requested the LSP creation. At the end of State Synchronization, the PCE SHOULD send a PCInitiate message to initiate any missing LSPs and/or remove any LSPs that are not wanted. Under some circumstances, depending on the deployment, it might be preferable for a PCE not to send this PCInitiate immediately, or at all. For example, the PCC may be a slow device, or the operator might prefer not to disrupt active flows. RFC8231] defines the LSP object; per that RFC, IANA created a registry to manage the value of the LSP object's Flag field. IANA has allocated a new bit in the "LSP Object Flag Field" subregistry, as follows: Bit Description Reference --- ----------- ------------- 4 Create RFC 8281
RFC8126]. Each bit is tracked with the following qualities: bit number (counting from bit 0 as the most significant bit), description, and defining RFC. The following values are defined in this document: Bit Description Reference --- ----------- ------------- 31 LSP-Remove RFC 8281 RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC, IANA created a registry to manage the value of the STATEFUL-PCE-CAPABILITY TLV's Flag field. IANA has allocated a new bit in the STATEFUL-PCE- CAPABILITY TLV Flag Field registry, as follows: Bit Description Reference --- -------------------------------- ------------- 29 LSP-INSTANTIATION-CAPABILITY (I) RFC 8281
RFC8231] apply to the extensions described in this document. Additional considerations related to a malicious PCE are introduced.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [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>. [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <https://www.rfc-editor.org/info/rfc5511>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [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>. [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., and D. Dhody, "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", RFC 8232, DOI 10.17487/RFC8232, September 2017, <https://www.rfc-editor.org/info/rfc8232>. [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, <https://www.rfc-editor.org/info/rfc4657>. [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>.
[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>.