idnits 2.17.00 (12 Aug 2021) /tmp/idnits35338/draft-ietf-pce-stateful-flags-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document updates RFC8281, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 23, 2020) is 842 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-pce-lsp-control-request has been published as RFC 8741 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group A. Farrel 3 Internet-Draft Old Dog Consulting 4 Updates: 8231 (if approved) January 23, 2020 5 Intended status: Standards Track 6 Expires: July 26, 2020 8 Updated Rules for Processing Stateful PCE Request Parameters Flags 9 draft-ietf-pce-stateful-flags-01 11 Abstract 13 Extensions to the Path Computation Element Communication Protocol 14 (PCEP) to support stateful Path Computation Elements (PCEs) are 15 defined in RFC 8231. One of the extensions is the Stateful PCE 16 Request Parameters (SRP) object. That object includes a Flags field 17 that is a set of 32 bit flags, and RFC 8281 defines an IANA registry 18 for tracking assigned flags. However, RFC 8231 does not explain how 19 an implementation should set unassigned flags in transmitted 20 messages, nor how an implementation should process unassigned, 21 unknown, or unsupported flags in received messages. 23 This document updates RFC 8231 by defining the correct behaviors. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 26, 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Updated Procedures . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Advice for Specification of New Flags . . . . . . . . . . 3 63 3.2. Flags Field of the SRP Object . . . . . . . . . . . . . . 4 64 4. Compatibility Considerations . . . . . . . . . . . . . . . . 4 65 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 66 6. Management Considerations . . . . . . . . . . . . . . . . . . 5 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 10.2. Informative References . . . . . . . . . . . . . . . . . 6 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 [RFC5440] describes the Path Computation Element Communication 78 Protocol (PCEP). PCEP defines the communication between a Path 79 Computation Client (PCC) and a Path Computation Element (PCE), or 80 between PCEs, enabling computation of Multiprotocol Label Switching 81 (MPLS) for Traffic Engineering Label Switched Path (TE LSP) 82 characteristics. 84 [RFC8231] specifies a set of extensions to PCEP to enable stateful 85 control of LSPs within and across PCEP sessions in compliance with 86 [RFC4657]. It includes mechanisms to effect Label Switched Path 87 (LSP) State Synchronization between PCCs and PCEs, delegation of 88 control over LSPs to PCEs, and PCE control of timing and sequence of 89 path computations within and across PCEP sessions. 91 One of the extensions defined in [RFC8231] is the Stateful PCE 92 Request Parameters (SRP) object. That object includes a Flags field 93 that is a set of 32 bit flags, and RFC 8281 defines an IANA registry 94 for tracking assigned flags. However, RFC 8231 does not explain how 95 an implementation should set unassigned flags in transmitted 96 messages, nor how an implementation should process unassigned or 97 unknown flags in received messages. 99 Furthermore, [RFC8231] gives no guidance to the authors of future 100 specifications about how to describe the interaction between flags 101 that have already been defined and flags being defined in the new 102 specifications. 104 This document updates RFC 8231 by defining the correct behaviors. 106 2. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 3. Updated Procedures 116 3.1. Advice for Specification of New Flags 118 Section 7 of [RFC8231] introduces changes to existing PCEP objects 119 and the definition of new PCEP objects and TLVs in support of 120 stateful PCE functionality. That text does not advise future 121 specifications how to describe the interaction between flags that may 122 be defined. 124 The text in Section 7 is updated to read as follows: 126 The PCEP objects defined in this document are compliant with the 127 PCEP object format defined in [RFC5440]. The P and I flags of the 128 PCEP objects defined in the current document MUST be set to 0 on 129 transmission and SHOULD be ignored on receipt since they are 130 exclusively related to path computation requests. 132 The sections that follow define PCEP objects and TLVs that contain 133 flags fields, and some flag values are defined. Future 134 specifications may define further flags, and each new 135 specification that defines additional flags is expected to 136 describe the interaction between these new flags and any existing 137 flags. In particular, new specifications are expected to explain 138 how to handle the cases when both new and pre-existing flags are 139 set. 141 3.2. Flags Field of the SRP Object 143 Section 7.2 of [RFC8231] defines the PCEP SRP object. It describes 144 the flags field as: 146 Flags (32 bits): None defined yet. 148 This document updates that text as follows: 150 Flags (32 bits): This document does not define any flags. 151 Unassigned flags MUST be set to zero on transmission and MUST be 152 ignored on receipt. Implementations that do not understand any 153 particular flag MUST ignore the flag. 155 4. Compatibility Considerations 157 While one of the main objectives of the changes made by this document 158 is to enable backward compatibility, there remains an issue of 159 compatibility between existing implementations of RFC 8231 and 160 implementations that are consistent with this document. 162 It should be noted that common behavior for flags fields is as 163 described by the updated text presented in Section 3. Thus, many 164 implementations, lacking guidance from RFC 8231, will still have 165 implemented a consistent and future-proof approach. However, for 166 completeness it is worth noting how behaviors might interact between 167 implementations. 169 SRP objects generated by an implementation of this document will set 170 all unknown flag bits to zero and will therefore cause no issues to 171 an older implementation even if it inspects those bits. Similarly, 172 an implementation of this document will not inspect any unknown flag 173 bits and will therefore be unaffected by older implementations no 174 matter how they set the flags. 176 There will remain an issue with compatibility between implementations 177 of RFC 8231 that might set any of the unassigned flags, and current 178 (such as [RFC8281]) and future (such as 179 [I-D.ietf-pce-lsp-control-request]) specifications that assign 180 specific meanings to flags if set. That problem cannot be fixed in 181 old implementations by any amount of documentation, and can only be 182 handled for future specifications by obsoleting the Flags field and 183 using a new technique. Fortunately, however, most implementations 184 will have been constructed to set unused flags to zero which is 185 consistent with the behavior described in this document and so the 186 risk of bad interactions is sufficiently small that there is no need 187 to obsolete the existing Flags field. 189 5. Implementation Status 191 [NOTE TO RFC EDITOR: Please remove this section before publication as 192 an RFC.] 194 While this document describes changes to [RFC8231] that are important 195 for implementation, and while the document gives advice to 196 implementations, there is nothing specific in this document to 197 implement. 199 A private and unscientific poll of implementers of RFC 8231 conducted 200 by the author suggests that existing implementations already abide by 201 the modification set out in this document. 203 6. Management Considerations 205 Implementations receiving set SRP flags that they do not recognize 206 MAY log this. That could be helpful for diagnosing backward 207 compatibility issues with future features that utilize those flags. 209 7. Security Considerations 211 [RFC8231] sets out security considerations for PCEP when used for 212 communication with a stateful PCE. This document does not change 213 those considerations. 215 However, by defining the expected behavior of implementations, this 216 document may improve the stability of networks and thus reduce the 217 attack surface. That is, by reminding implementations to ignore 218 unset bits, it is less possible to attack them by randomly tweaking 219 bits. Furthermore, by reminding implementations to leave undefined 220 bits unset, the network is future-proofed against new definitions of 221 previously undefined bits. 223 8. IANA Considerations 225 IANA maintains a registry called the "Path Computation Element 226 Protocol (PCEP) Numbers" registry with a subregistry called " SRP 227 Object Flag Field". IANA is requested to update the Reference in 228 that subregistry to include a reference to this document in addition 229 to [RFC8281]. 231 9. Acknowledgements 233 Thanks to the authors of [I-D.ietf-pce-lsp-control-request] for 234 exposing the need for this work. Thanks to Dhruv Dhody and Julien 235 Meuric for discussing the solution. Additional thanks to Hariharan 236 Ananthakrishnan for his Shepherd's review. Thanks to Benjamin Kaduk 237 and Alvaro Retana for helpful comments during IESG review. 239 10. References 241 10.1. Normative References 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, 245 DOI 10.17487/RFC2119, March 1997, 246 . 248 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 249 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 250 May 2017, . 252 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 253 Computation Element Communication Protocol (PCEP) 254 Extensions for Stateful PCE", RFC 8231, 255 DOI 10.17487/RFC8231, September 2017, 256 . 258 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 259 Computation Element Communication Protocol (PCEP) 260 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 261 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 262 . 264 10.2. Informative References 266 [I-D.ietf-pce-lsp-control-request] 267 Raghuram, A., Goddard, A., Karthik, J., Sivabalan, S., and 268 M. Negi, "Ability for a Stateful Path Computation Element 269 (PCE) to request and obtain control of a Label Switched 270 Path (LSP)", draft-ietf-pce-lsp-control-request-11 (work 271 in progress), October 2019. 273 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 274 Element (PCE) Communication Protocol Generic 275 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 276 2006, . 278 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 279 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 280 DOI 10.17487/RFC5440, March 2009, 281 . 283 Author's Address 285 Adrian Farrel 286 Old Dog Consulting 288 Email: adrian@olddog.co.uk