idnits 2.17.1 draft-farrel-pce-stateful-flags-00.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 (June 24, 2019) is 1767 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-05 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) June 24, 2019 5 Intended status: Standards Track 6 Expires: December 26, 2019 8 Updated Rules for Processing Stateful PCE Request Parameters Flags 9 draft-farrel-pce-stateful-flags-00 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 December 26, 2019. 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. Compatibliity Considerations . . . . . . . . . . . . . . . . 3 63 5. Management Considerations . . . . . . . . . . . . . . . . . . 4 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 69 9.2. Informative References . . . . . . . . . . . . . . . . . 5 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 72 1. Introduction 74 [RFC5440] describes the Path Computation Element Communication 75 Protocol (PCEP). PCEP defines the communication between a Path 76 Computation Client (PCC) and a Path Computation Element (PCE), or 77 between PCEs, enabling computation of Multiprotocol Label Switching 78 (MPLS) for Traffic Engineering Label Switched Path (TE LSP) 79 characteristics. 81 [RFC8231] specifies a set of extensions to PCEP to enable stateful 82 control of LSPs within and across PCEP sessions in compliance with 83 [RFC4657]. It includes mechanisms to effect Label Switched Path 84 (LSP) State Synchronization between PCCs and PCEs, delegation of 85 control over LSPs to PCEs, and PCE control of timing and sequence of 86 path computations within and across PCEP sessions. 88 One of the extensions defined in [RFC8231] is the Stateful PCE 89 Request Parameters (SRP) object. That object includes a Flags field 90 that is a set of 32 bit flags, and RFC 8281 defines an IANA registry 91 for tracking assigned flags. However, RFC 8231 does not explain how 92 an implementation should set unassigned flags in transmitted 93 messages, nor how an implementation should process unassigned or 94 unknown flags in received messages. 96 This document updates RFC 8231 by defining the correct behaviors. 98 2. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 3. Updated Procedures 108 Section 7.2 of [RFC8231] defines the PCEP SRP object. It describes 109 the flags field as: 111 Flags (32 bits): None defined yet. 113 This document updates that text as follows: 115 Flags (32 bits): This document does not define any flags. 116 Unassigned flags MUST be set to zero on transmission and MUST be 117 ignored on receipt. Implementations that do not understand any 118 particular flag MUST ignore the flag. 120 4. Compatibliity Considerations 122 While one of the main objectives of the changes made by this document 123 is to enable backward compatibility, there remains an issue of 124 compatiblity between existing implementations of RFC 8231 and 125 implementations that are consistent with this document. 127 SRP objects generated by an implementation of this document will set 128 all unknown flag bits to zero and will therefore cause no issues to 129 an older implementation even if it inspects those bits. Similarly, 130 an implementation of this document will not inspect any unknow flag 131 bits and so will be unaffected by older implementations no matter how 132 they set the flags. 134 There will remain an issue with compatibility between implementations 135 of RFC 8231 that might set any of the unassigned flags, and current 136 (such as [RFC8281]) and future (such as 137 [I-D.ietf-pce-lsp-control-request]) specifications. That problem 138 cannot be fixed in old implementations by any amount of 139 documentation, and can only be handled for future specifications by 140 obsoleting the Flags field and using a new technique. Fortunatley, 141 however, most implementations will have been constructed to set 142 unused flags to zero which is consistent with the behavior described 143 in this document. 145 5. Management Considerations 147 Implementations receiving set SRP flags that they do not recognize 148 MAY log the fact. That could be helpful for diagnosing backward 149 compatiblity issues with future features that utilise those flags. 151 6. Security Considerations 153 [RFC8231] sets out security considerations for PCEP when used for 154 communication with a stateful PCE. This document does not change 155 those considerations. 157 However, by defining the expected behavior of implementations, this 158 document may improve the stability of networks and so reduce the 159 attack surface. 161 7. IANA Considerations 163 This document makes no requests for IANA action. 165 8. Acknowledgements 167 Thanks to the authors of [I-D.ietf-pce-lsp-control-request] for 168 exposing the need for this work. Thanks to Dhruv Dhody and Julien 169 Meuric for discussing the solution. 171 9. References 173 9.1. Normative References 175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 176 Requirement Levels", BCP 14, RFC 2119, 177 DOI 10.17487/RFC2119, March 1997, 178 . 180 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 181 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 182 May 2017, . 184 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 185 Computation Element Communication Protocol (PCEP) 186 Extensions for Stateful PCE", RFC 8231, 187 DOI 10.17487/RFC8231, September 2017, 188 . 190 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 191 Computation Element Communication Protocol (PCEP) 192 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 193 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 194 . 196 9.2. Informative References 198 [I-D.ietf-pce-lsp-control-request] 199 Raghuram, A., Goddard, A., Karthik, J., Sivabalan, S., and 200 M. Negi, "Ability for a stateful Path Computation Element 201 (PCE) to request and obtain control of a Label Switched 202 Path (LSP)", draft-ietf-pce-lsp-control-request-05 (work 203 in progress), June 2019. 205 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 206 Element (PCE) Communication Protocol Generic 207 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 208 2006, . 210 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 211 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 212 DOI 10.17487/RFC5440, March 2009, 213 . 215 Author's Address 217 Adrian Farrel 218 Old Dog Consulting 220 Email: adrian@olddog.co.uk