idnits 2.17.1 draft-farrel-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 (August 16, 2019) is 1709 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: A later version (-11) exists of draft-ietf-pce-lsp-control-request-07 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) August 16, 2019 5 Intended status: Standards Track 6 Expires: February 17, 2020 8 Updated Rules for Processing Stateful PCE Request Parameters Flags 9 draft-farrel-pce-stateful-flags-01 11 Abstract 13 Extensions to the Path Computation Element communications 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 February 17, 2020. 42 Copyright Notice 44 Copyright (c) 2019 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 4. Compatibility Considerations . . . . . . . . . . . . . . . . 3 63 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 4 64 6. Management Considerations . . . . . . . . . . . . . . . . . . 4 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 70 10.2. Informative References . . . . . . . . . . . . . . . . . 5 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 [RFC5440] describes the Path Computation Element Communication 76 Protocol (PCEP). PCEP defines the communication between a Path 77 Computation Client (PCC) and a Path Computation Element (PCE), or 78 between PCEs, enabling computation of Multiprotocol Label Switching 79 (MPLS) for Traffic Engineering Label Switched Path (TE LSP) 80 characteristics. 82 [RFC8231] specifies a set of extensions to PCEP to enable stateful 83 control of LSPs within and across PCEP sessions in compliance with 84 [RFC4657]. It includes mechanisms to effect Label Switched Path 85 (LSP) State Synchronization between PCCs and PCEs, delegation of 86 control over LSPs to PCEs, and PCE control of timing and sequence of 87 path computations within and across PCEP sessions. 89 One of the extensions defined in [RFC8231] is the Stateful PCE 90 Request Parameters (SRP) object. That object includes a Flags field 91 that is a set of 32 bit flags, and RFC 8281 defines an IANA registry 92 for tracking assigned flags. However, RFC 8231 does not explain how 93 an implementation should set unassigned flags in transmitted 94 messages, nor how an implementation should process unassigned or 95 unknown flags in received messages. 97 This document updates RFC 8231 by defining the correct behaviors. 99 2. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 3. Updated Procedures 109 Section 7.2 of [RFC8231] defines the PCEP SRP object. It describes 110 the flags field as: 112 Flags (32 bits): None defined yet. 114 This document updates that text as follows: 116 Flags (32 bits): This document does not define any flags. 117 Unassigned flags MUST be set to zero on transmission and MUST be 118 ignored on receipt. Implementations that do not understand any 119 particular flag MUST ignore the flag. 121 4. Compatibility Considerations 123 While one of the main objectives of the changes made by this document 124 is to enable backward compatibility, there remains an issue of 125 compatibility between existing implementations of RFC 8231 and 126 implementations that are consistent with this document. 128 It should be noted that common behavior for flags fields is as 129 described by the updated text presented in Section 3 so many 130 implementations, lacking guidance from RFC 8231, will still have 131 implemented a consistent and future-proof approach. However, for 132 completeness it is worth noting how behaviors might interact between 133 implementations. 135 SRP objects generated by an implementation of this document will set 136 all unknown flag bits to zero and will therefore cause no issues to 137 an older implementation even if it inspects those bits. Similarly, 138 an implementation of this document will not inspect any unknown flag 139 bits and so will be unaffected by older implementations no matter how 140 they set the flags. 142 There will remain an issue with compatibility between implementations 143 of RFC 8231 that might set any of the unassigned flags, and current 144 (such as [RFC8281]) and future (such as 146 [I-D.ietf-pce-lsp-control-request]) specifications. That problem 147 cannot be fixed in old implementations by any amount of 148 documentation, and can only be handled for future specifications by 149 obsoleting the Flags field and using a new technique. Fortunately, 150 however, most implementations will have been constructed to set 151 unused flags to zero which is consistent with the behavior described 152 in this document. 154 5. Implementation Status 156 [NOTE TO RFC EDITOR: Please remove this section before publication as 157 an RFC.] 159 While this document describes changes to [RFC8231] that are important 160 for implementation, and while the document gives advice to 161 implementations, there is nothing specific in this document to 162 implement. 164 A private and unscientific poll of implementers of RFC 8231 conducted 165 by the author suggests that existing implementations already abide by 166 the modification set out in this document. 168 6. Management Considerations 170 Implementations receiving set SRP flags that they do not recognize 171 MAY log the fact. That could be helpful for diagnosing backward 172 compatibility issues with future features that utilize those flags. 174 7. Security Considerations 176 [RFC8231] sets out security considerations for PCEP when used for 177 communication with a stateful PCE. This document does not change 178 those considerations. 180 However, by defining the expected behavior of implementations, this 181 document may improve the stability of networks and so reduce the 182 attack surface. 184 8. IANA Considerations 186 This document makes no requests for IANA action. 188 9. Acknowledgements 190 Thanks to the authors of [I-D.ietf-pce-lsp-control-request] for 191 exposing the need for this work. Thanks to Dhruv Dhody and Julien 192 Meuric for discussing the solution. 194 10. References 196 10.1. Normative References 198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 199 Requirement Levels", BCP 14, RFC 2119, 200 DOI 10.17487/RFC2119, March 1997, 201 . 203 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 204 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 205 May 2017, . 207 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 208 Computation Element Communication Protocol (PCEP) 209 Extensions for Stateful PCE", RFC 8231, 210 DOI 10.17487/RFC8231, September 2017, 211 . 213 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 214 Computation Element Communication Protocol (PCEP) 215 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 216 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 217 . 219 10.2. Informative References 221 [I-D.ietf-pce-lsp-control-request] 222 Raghuram, A., Goddard, A., Karthik, J., Sivabalan, S., and 223 M. Negi, "Ability for a Stateful Path Computation Element 224 (PCE) to request and obtain control of a Label Switched 225 Path (LSP)", draft-ietf-pce-lsp-control-request-07 (work 226 in progress), August 2019. 228 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 229 Element (PCE) Communication Protocol Generic 230 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 231 2006, . 233 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 234 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 235 DOI 10.17487/RFC5440, March 2009, 236 . 238 Author's Address 240 Adrian Farrel 241 Old Dog Consulting 243 Email: adrian@olddog.co.uk