idnits 2.17.00 (12 Aug 2021) /tmp/idnits26920/draft-dhody-pce-pcep-object-order-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- (Using the creation date from RFC5440, updated by this document, for RFC5378 checks: 2005-11-29) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (5 March 2022) is 70 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft Huawei Technologies 4 Updates: 5440 (if approved) 5 March 2022 5 Intended status: Standards Track 6 Expires: 6 September 2022 8 Updated Rules for PCEP Object Ordering 9 draft-dhody-pce-pcep-object-order-01 11 Abstract 13 The Path Computation Element Communication Protocol (PCEP) defines 14 the mechanisms for the communication between a Path Computation 15 Client (PCC) and a Path Computation Element (PCE), or among PCEs. 16 Such interactions include include path computation requests and path 17 computation replies defined in RFC 5440. As per RFC 5440, these 18 message are required to follow strict object ordering. 20 This document updates RFC 5440 by relaxing the strict object ordering 21 requirement in the PCEP messages. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 6 September 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Update to RFC 5440 . . . . . . . . . . . . . . . . . . . . . 3 60 5. Compatibility Considerations . . . . . . . . . . . . . . . . 3 61 6. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 4 62 7. Management Considerations . . . . . . . . . . . . . . . . . . 4 63 8. Other Efforts . . . . . . . . . . . . . . . . . . . . . . . . 4 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 11.1. Normative References . . . . . . . . . . . . . . . . . . 4 68 11.2. Informative References . . . . . . . . . . . . . . . . . 5 69 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 5 70 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 6 71 Appendix C. When Order Matters . . . . . . . . . . . . . . . . . 6 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 [RFC5440] describes the Path Computation Element Communication 77 Protocol (PCEP). PCEP defines the communication between a Path 78 Computation Client (PCC) and a Path Computation Element (PCE), or 79 between PCEs, enabling computation of Multiprotocol Label Switching 80 (MPLS) for Traffic Engineering Label Switched Path (TE LSP) 81 characteristics. 83 [RFC5440] defines several PCEP messages. For each PCEP message type, 84 rules are defined that specify the set of objects that the message 85 can carry using [RFC5511]. Further, [RFC5440] states that the object 86 ordering is mandatory. This causes confusion when multiple 87 extensions add new objects in the PCEP messages and the respective 88 order of these new objects is not specified (see [EID6627]). 90 This document updates [RFC5440] to relax the strict object ordering 91 requirement. 93 2. Conventions 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in 98 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 3. Motivation 103 The mandatory object ordering requirement in [RFC5440] is shown to 104 result in exponential complexity in terms of what each new PCEP 105 extension needs to cope with in terms of reconciling all previously- 106 published RFCs, and all concurrently work in progress internet 107 drafts. This requirement does not lend itself for extensibility of 108 PCEP. 110 4. Update to RFC 5440 112 Section 6 of [RFC5440] states: 114 An implementation MUST form the PCEP 115 messages using the object ordering specified in this document. 117 This text is updated to read as follows: 119 An implementation SHOULD form the PCEP 120 messages using the object ordering specified in this and 121 subsequent documents when an ordering can be unambiguously 122 determined; an implementation MUST be prepared to receive 123 a PCEP message with objects in any order. 125 This update does not aim to take away the object ordering completely. 126 It is expected that the PCEP speaker will follow the object order as 127 specified unless there are valid reasons to ignore. It is also 128 expected that the receiver is able to unambiguously understand the 129 object meaning irrespective of the order. 131 5. Compatibility Considerations 133 While one of the main objectives of the changes made by this document 134 is to enable backward compatibility between PCEP extensions, there 135 remains an issue of compatibility between existing implementations of 136 [RFC5440] and implementations that are consistent with this document. 138 It should be noted that common behavior for checking object ordering 139 in received PCEP messages is as described by the updated text 140 presented in Section 4. Thus, many implementations, will still have 141 implemented a consistent and future-proof approach. However, for 142 completeness, it is worth noting how behaviors might interact between 143 implementations. 145 The messages generated by an implementation of this document when 146 received by a legacy implementation with a strict interpretation of 147 object ordering MAY lead to error handling. It is interesting to 148 note that the [RFC5440] does not define an Error-Type and Error-value 149 corresponding to this error condition. 151 6. Open Questions 153 * Should a new flag or a TLV in Open Message be added to exchange 154 this capability? Not sure if this is strictly needed. 156 7. Management Considerations 158 Implementations receiving set objects that they consider out of order 159 MAY log this. That could be helpful for diagnosing backward 160 compatibility issues. 162 8. Other Efforts 164 In the past there have been effort to consolidate and update the RBNF 165 such as in [I-D.cmfg-pce-pcep-grammar]. This document document 166 relaxes the object ordering only, it does not take on the various 167 other issues or the need to consolidate the RBNF for all PCEP 168 extensions. There have been proposal to consolidate the RBNF for the 169 PCEP message in a single place in GitHub and use modern data modeling 170 tools to represent PCEP extensions. They might be taken up in 171 parallel. 173 9. Security Considerations 175 This document does not raise any security issues. 177 10. IANA Considerations 179 This document does not require any IANA actions. 181 11. References 183 11.1. Normative References 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, 187 DOI 10.17487/RFC2119, March 1997, 188 . 190 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 191 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 192 DOI 10.17487/RFC5440, March 2009, 193 . 195 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 196 Used to Form Encoding Rules in Various Routing Protocol 197 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 198 2009, . 200 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 201 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 202 May 2017, . 204 11.2. Informative References 206 [EID6627] "Errata ID: 6627", n.d., 207 . 209 [I-D.cmfg-pce-pcep-grammar] 210 Casellas, R., Margaria, C., Farrel, A., Dios, O. G. D., 211 Dhody, D., and X. Zhang, "Current issues with existing 212 RBNF notation for PCEP messages and extensions", Work in 213 Progress, Internet-Draft, draft-cmfg-pce-pcep-grammar-02, 214 10 January 2014, . 217 [RFC5455] Sivabalan, S., Ed., Parker, J., Boutros, S., and K. 218 Kumaki, "Diffserv-Aware Class-Type Object for the Path 219 Computation Element Communication Protocol", RFC 5455, 220 DOI 10.17487/RFC5455, March 2009, 221 . 223 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 224 Computation Element Communication Protocol (PCEP) 225 Extensions for Stateful PCE", RFC 8231, 226 DOI 10.17487/RFC8231, September 2017, 227 . 229 Appendix A. Acknowledgments 231 Thanks to John Scudder for the motivation behind this document. 232 Thanks to Oscar Gonzalez de Dios and Cyril Margaria for raising 233 errata on this topic. Thanks to the author of 234 [I-D.cmfg-pce-pcep-grammar] for highlighting the issue. 236 Appendix B. Examples 238 As described in [EID6627], for the PCReq message, the CLASSTYPE 239 object is encoded after the END-POINTS object in [RFC5455]. Where as 240 in [RFC8231], the LSP object is encoded just after the END-POINTS 241 object. So it is not known which of the below order is expected. 243 ...[][]... 245 or 247 ...[][]... 249 This update require the receiver to be able to except both of these. 251 Appendix C. When Order Matters 253 There are cases where the ordering between objects is important. For 254 instance PCRpt message [RFC8231] includes with some attributes 255 say BANDWIDTH can be part of both and 256 . 258 Where: 259 ::= 260 [] 261 263 An important factor to distinguish between the actual and intended 264 attribute list is the presence of RRO (i.e. ) and the 265 order of objects in the PCRpt message. 267 If the RRO is present, any attributes encoded before it, are to be 268 considered as part of and those after it, as 269 part of . 271 If the RRO is absent, all attributes are part of . 274 Thus the approach taken by this document is to say that ordering is 275 relaxed in cases where there is no ambiguity. 277 Author's Address 279 Dhruv Dhody 280 Huawei Technologies 281 Divyashree Techno Park, Whitefield 282 Bangalore 560066 283 India 284 Email: dhruv.ietf@gmail.com