diff options
Diffstat (limited to 'doc/rfc/rfc8786.txt')
| -rw-r--r-- | doc/rfc/rfc8786.txt | 270 |
1 files changed, 270 insertions, 0 deletions
diff --git a/doc/rfc/rfc8786.txt b/doc/rfc/rfc8786.txt new file mode 100644 index 0000000..1ab1852 --- /dev/null +++ b/doc/rfc/rfc8786.txt @@ -0,0 +1,270 @@ + + + + +Internet Engineering Task Force (IETF) A. Farrel +Request for Comments: 8786 Old Dog Consulting +Updates: 8231 May 2020 +Category: Standards Track +ISSN: 2070-1721 + + + Updated Rules for Processing Stateful PCE Request Parameters Flags + +Abstract + + Extensions to the Path Computation Element Communication Protocol + (PCEP) to support stateful Path Computation Elements (PCEs) are + defined in RFC 8231. One of the extensions is the Stateful PCE + Request Parameters (SRP) object. That object includes a Flags field + that is a set of 32 bit flags, and RFC 8281 defines an IANA registry + for tracking assigned flags. However, RFC 8231 does not explain how + an implementation should set unassigned flags in transmitted + messages, nor how an implementation should process unassigned, + unknown, or unsupported flags in received messages. + + This document updates RFC 8231 by defining the correct behaviors. + +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/rfc8786. + +Copyright Notice + + Copyright (c) 2020 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. + +Table of Contents + + 1. Introduction + 2. Requirements Language + 3. Updated Procedures + 3.1. Advice for Specification of New Flags + 3.2. Flags Field of the SRP Object + 4. Compatibility Considerations + 5. Management Considerations + 6. Security Considerations + 7. IANA Considerations + 8. References + 8.1. Normative References + 8.2. Informative References + Acknowledgements + Author's Address + +1. Introduction + + [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 PCEs, 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 LSPs within and across PCEP sessions in compliance with + [RFC4657]. It includes mechanisms to effect Label Switched Path + (LSP) State Synchronization between PCCs and PCEs, delegation of + control over LSPs to PCEs, and PCE control of timing and sequence of + path computations within and across PCEP sessions. + + One of the extensions defined in [RFC8231] is the Stateful PCE + Request Parameters (SRP) object. That object includes a Flags field + that is a set of 32 bit flags, and RFC 8281 defines an IANA registry + for tracking assigned flags. However, RFC 8231 does not explain how + an implementation should set unassigned flags in transmitted + messages, nor how an implementation should process unassigned or + unknown flags in received messages. + + Furthermore, [RFC8231] gives no guidance to the authors of future + specifications about how to describe the interaction between flags + that have already been defined and flags being defined in the new + specifications. + + This document updates RFC 8231 by defining the correct behaviors. + +2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Updated Procedures + +3.1. Advice for Specification of New Flags + + Section 7 of [RFC8231] introduces changes to existing PCEP objects + and defines new PCEP objects and TLVs in support of stateful PCE + functionality. That text does not advise future specifications on + how to describe the interaction between flags that may be defined. + + The text in Section 7 of [RFC8231] is updated to read as follows: + + The PCEP objects defined in this document are compliant with the + PCEP object format defined in [RFC5440]. The P and I flags of the + PCEP objects defined in the current document MUST be set to 0 on + transmission and SHOULD be ignored on receipt since they are + exclusively related to path computation requests. + + The sections that follow define PCEP objects and TLVs that contain + Flags fields, and some flag values are defined. Future + specifications may define further flags, and each new + specification that defines additional flags is expected to + describe the interaction between these new flags and any existing + flags. In particular, new specifications are expected to explain + how to handle the cases when both new and pre-existing flags are + set. + +3.2. Flags Field of the SRP Object + + Section 7.2 of [RFC8231] defines the PCEP SRP object. It describes + the Flags field as: + + Flags (32 bits): None defined yet. + + This document updates that text as follows: + + Flags (32 bits): This document does not define any flags. + Unassigned flags MUST be set to zero on transmission and MUST be + ignored on receipt. Implementations that do not understand any + particular flag MUST ignore the flag. + +4. Compatibility Considerations + + While one of the main objectives of the changes made by this document + is to enable backward compatibility, there remains an issue of + compatibility between existing implementations of RFC 8231 and + implementations that are consistent with this document. + + It should be noted that common behavior for Flags fields is as + described by the updated text presented in Section 3. Thus, many + implementations, lacking guidance from RFC 8231, will still have + implemented a consistent and future-proof approach. However, for + completeness, it is worth noting how behaviors might interact between + implementations. + + SRP objects generated by an implementation of this document will set + all unknown flag bits to zero and will therefore cause no issues to + an older implementation even if it inspects those bits. Similarly, + an implementation of this document will not inspect any unknown flag + bits and will therefore be unaffected by older implementations no + matter how they set the flags. + + There will remain an issue with compatibility between implementations + and how they set the flags. An implementation of RFC 8231 might set + any of the unassigned flags, but an implementation of a future or + current specification (such as [RFC8281] or [RFC8741]) assigns + specific meanings to a flag if set. That problem cannot be fixed in + old implementations by any amount of documentation and can only be + handled for future specifications by obsoleting the Flags field and + using a new technique. Fortunately, however, most implementations + will have been constructed to set unused flags to zero, which is + consistent with the behavior described in this document, and so the + risk of bad interactions is sufficiently small that there is no need + to obsolete the existing Flags field. + +5. Management Considerations + + Implementations receiving set SRP flags that they do not recognize + MAY log this. That could be helpful for diagnosing backward + compatibility issues with future features that utilize those flags. + +6. Security Considerations + + [RFC8231] sets out security considerations for PCEP when used for + communication with a stateful PCE. This document does not change + those considerations. + + However, by defining the expected behavior of implementations, this + document may improve the stability of networks and thus reduce the + attack surface. That is, by reminding implementations to ignore + unset bits, it is less possible to attack them by randomly tweaking + bits. Furthermore, by reminding implementations to leave undefined + bits unset, the network is future-proofed against new definitions of + previously undefined bits. + +7. IANA Considerations + + IANA maintains a registry called the "Path Computation Element + Protocol (PCEP) Numbers" registry with a subregistry called "SRP + Object Flag Field". IANA has updated the reference for that + subregistry to list this document in addition to [RFC8281]. + +8. References + +8.1. Normative References + + [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>. + + [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>. + + [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 + + [RFC4657] Ash, J., Ed. and J.L. 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>. + + [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>. + + [RFC8741] Raghuram, A., Goddard, A., Karthik, J., Sivabalan, S., and + M. Negi, "Ability for a Stateful Path Computation Element + (PCE) to Request and Obtain Control of a Label Switched + Path (LSP)", RFC 8741, DOI 10.17487/RFC8741, March 2020, + <https://www.rfc-editor.org/info/rfc8741>. + +Acknowledgements + + Thanks to the authors of [RFC8741] for exposing the need for this + work. Thanks to Dhruv Dhody and Julien Meuric for discussing the + solution. Additional thanks to Hariharan Ananthakrishnan for his + Shepherd's review. Thanks to Benjamin Kaduk and Alvaro Retana for + helpful comments during IESG review. + +Author's Address + + Adrian Farrel + Old Dog Consulting + + Email: adrian@olddog.co.uk |