idnits 2.17.1 draft-ietf-pce-iro-update-07.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: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5440, updated by this document, for RFC5378 checks: 2005-11-29) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 21, 2016) is 2927 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 (~~), 1 warning (==), 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) April 21, 2016 5 Intended status: Standards Track 6 Expires: October 23, 2016 8 Update to Include Route Object (IRO) specification in Path Computation 9 Element communication Protocol (PCEP) 10 draft-ietf-pce-iro-update-07 12 Abstract 14 The Path Computation Element Communication Protocol (PCEP) provides 15 for communications between a Path Computation Client (PCC) and a PCE, 16 or between two PCEs. RFC 5440 defines the Include Route Object (IRO) 17 to specify network elements to be traversed in the computed path. 18 The specification did not specify if the IRO contains an ordered or 19 un-ordered list of sub-objects. During recent discussions, it was 20 determined that there was a need to define a standard representation 21 to ensure interoperability. It was also noted that there is a 22 benefit in handling of an attribute of the IRO's sub-object, the 23 Loose hop bit (L bit). 25 This document updates RFC 5440 regarding the IRO specification. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 23, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 2. Update in the IRO specification . . . . . . . . . . . . . . . 3 75 2.1. Update to RFC 5440 . . . . . . . . . . . . . . . . . . . 3 76 3. Operational Considerations . . . . . . . . . . . . . . . . . 3 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 79 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 82 7.2. Informative References . . . . . . . . . . . . . . . . . 5 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 85 1. Introduction 87 The Path Computation Element Communication Protocol (PCEP) provides 88 for communications between a Path Computation Client (PCC) and a PCE, 89 or between two PCEs. [RFC5440] defines the Include Route Object 90 (IRO) to specify network elements to be traversed in the computed 91 path. The specification did not define if the IRO is an ordered or 92 un-ordered list of sub-objects. In addition, it defined the Loose 93 hop bit (L bit) to have no meaning within an IRO. 95 [RFC5441] describes the use of an IRO to indicate the sequence of 96 domains to be traversed during inter-domain path computation. 98 During recent discussions, it was determined that there was a need to 99 define a standard representation to ensure interoperability. 101 This document updates the IRO specifications in section 7.12 of 102 [RFC5440]. 104 2. Update in the IRO specification 106 Section 7.12 of [RFC5440] describes the IRO as an optional object 107 used to specify a set of network elements to be traversed in the 108 computed path. It stated that the Loose hop bit (L bit) in the sub- 109 object has no meaning within an IRO. It did not mention if the IRO 110 contains an ordered or un-ordered list of sub-objects. 112 2.1. Update to RFC 5440 114 Section 7.12 of [RFC5440] regarding the IRO specification is updated 115 to remove the last line in the section 7.12 of [RFC5440], that states 116 : 118 "The L bit of such sub-object has no meaning within an IRO." 120 Further, the Section 7.12 of [RFC5440] is updated to add the 121 following two statements at the end of the first paragraph. 123 - The content of an IRO is an ordered list of sub-objects 124 representing a series of abstract nodes (refer to section 4.3.2 of 125 [RFC3209]). 127 - The L Bit of an IRO sub-object is set based on the loose or strict 128 hop property of the sub-object; it is set if the sub-object 129 represents a loose hop. If the bit is not set, the sub-object 130 represents a strict hop. The interpretation of the Loose bit (L bit) 131 is as per section 4.3.3.1 of [RFC3209]. 133 3. Operational Considerations 135 Because of the lack of clarity in [RFC5440], it is possible to 136 encounter implementations that always interpret the IRO sub-objects 137 as loose. When these implementations interwork with an 138 implementation conforming to this document, the following impact 139 might be seen: 141 o If a non-conforming (to this document) PCC sends an IRO to a 142 conforming (to this document) PCE, then the PCE may unexpectedly 143 fail to find a path (since the PCC may think of the IRO sub- 144 objects as loose hops, but the PCE interprets them as strict 145 hops). 147 o If a conforming PCC sends an IRO containing strict hops to a non- 148 conforming PCE, then the PCE may erroneously return a path that 149 does not comply with the requested strict hops (since the PCE 150 interprets them all as loose hops). The PCC may check the 151 returned path and find the issue or it may end up using an 152 incorrect path. 154 4. Security Considerations 156 This update in the IRO specification does not introduce any new 157 security considerations, apart from those mentioned in [RFC5440]. 158 Clarification in the supported IRO ordering or Loose hop bit handling 159 will not have any negative security impact. 161 It is worth noting that PCEP operates over TCP. An analysis of the 162 security issues for routing protocols that use TCP (including PCEP) 163 is provided in [RFC6952]. 165 5. IANA Considerations 167 This document makes no requests to IANA for action. 169 6. Acknowledgments 171 A special thanks to PCE chairs for guidance regarding this work. 173 Thanks to Francesco Fondelli for his suggestions in clarifying the L 174 bit usage. 176 Thanks to Adrian Farrel for his review and comments. 178 Thanks to Jonathan Hardwick for document shepherding and providing 179 text in Section 3. 181 Thanks to Deborah Brungard for her comments and being the responsible 182 AD. 184 Thanks to Peter Yee for Gen-ART review. 186 Thanks to Alvaro Retana for comments during the IESG review. 188 7. References 190 7.1. Normative References 192 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 193 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 194 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 195 . 197 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 198 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 199 DOI 10.17487/RFC5440, March 2009, 200 . 202 7.2. Informative References 204 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 205 "A Backward-Recursive PCE-Based Computation (BRPC) 206 Procedure to Compute Shortest Constrained Inter-Domain 207 Traffic Engineering Label Switched Paths", RFC 5441, 208 DOI 10.17487/RFC5441, April 2009, 209 . 211 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 212 BGP, LDP, PCEP, and MSDP Issues According to the Keying 213 and Authentication for Routing Protocols (KARP) Design 214 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 215 . 217 Author's Address 219 Dhruv Dhody 220 Huawei Technologies 221 Divyashree Techno Park, Whitefield 222 Bangalore, Karnataka 560066 223 India 225 EMail: dhruv.ietf@gmail.com