idnits 2.17.1 draft-ietf-pce-iro-update-06.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (March 14, 2016) is 2963 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 (~~), 2 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) March 14, 2016 5 Intended status: Standards Track 6 Expires: September 15, 2016 8 Update to Include Route Object (IRO) specification in Path Computation 9 Element communication Protocol (PCEP) 10 draft-ietf-pce-iro-update-06 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. 23 An informal survey was conducted to determine the state of current 24 and planned implementations with respect to IRO ordering and the 25 handling of an attribute of the IRO's sub-object, the Loose hop bit 26 (L bit). 28 This document updates RFC 5440 regarding the IRO specification, based 29 on the survey conclusion and recommendation. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 15, 2016. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 This document may contain material from IETF Documents or IETF 64 Contributions published or made publicly available before November 65 10, 2008. The person(s) controlling the copyright in some of this 66 material may not have granted the IETF Trust the right to allow 67 modifications of such material outside the IETF Standards Process. 68 Without obtaining an adequate license from the person(s) controlling 69 the copyright in such materials, this document may not be modified 70 outside the IETF Standards Process, and derivative works of it may 71 not be created outside the IETF Standards Process, except to format 72 it for publication as an RFC or to translate it into languages other 73 than English. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 78 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 79 2. Update in IRO specification . . . . . . . . . . . . . . . . . 3 80 2.1. Update to RFC 5440 . . . . . . . . . . . . . . . . . . . 4 81 3. Other Considerations . . . . . . . . . . . . . . . . . . . . 4 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 84 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 86 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 87 7.2. Informative References . . . . . . . . . . . . . . . . . 6 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 90 1. Introduction 92 The Path Computation Element Communication Protocol (PCEP) provides 93 for communications between a Path Computation Client (PCC) and a PCE, 94 or between two PCEs. [RFC5440] defines the Include Route Object 95 (IRO) to specify network elements to be traversed in the computed 96 path. The specification did not define if the IRO is an ordered or 97 un-ordered list of sub-objects. In addition, it defined the Loose 98 hop bit (L bit) to have no meaning within an IRO. 100 [RFC5441] describes the use of IRO to indicate the sequence of 101 domains to be traversed during inter-domain path computation. 103 During recent discussions, it was determined that there was a need to 104 define a standard representation to ensure interoperability. In 105 order to understand the current usage amongst implementations, a 106 survey of existing and planned implementations was conducted. This 107 survey was informal and conducted via email. Responses were 108 collected and anonymized by the PCE working group chair. 110 This document updates the IRO specifications in section 7.12 of 111 [RFC5440] as per the conclusion of the survey. 113 1.1. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 2. Update in IRO specification 121 Section 7.12 of [RFC5440] describes the IRO as an optional object 122 used to specify a set of network elements to be traversed in the 123 computed path. It stated that the Loose hop bit (L bit) in the sub- 124 object has no meaning within an IRO. It did not mention if the IRO 125 contains an ordered or un-ordered list of sub-objects. 127 A survey of the existing and planned implementations was conducted in 128 order to understand the current state of usage amongst 129 implementations. 131 The survey found that most implementations construct or interpret the 132 IRO in an ordered fashion and consider it to be an ordered list. 133 More than half of implementations interpreted the IRO sub-objects as 134 strict hops, others interpreted as loose or supported both 135 interpretation. The results shown in this survey found that most 136 implementations support updating [RFC5440] to specify the IRO as an 137 ordered list and supported the use of the Loose hop bit (L bit) such 138 that both strict and loose hops could be supported in the IRO. 140 2.1. Update to RFC 5440 142 Section 7.12 of [RFC5440] regarding the IRO specification is updated 143 to remove the last line in the section 7.12 of [RFC5440], that states 145 - 'The L bit of such sub-object has no meaning within an IRO.' 147 Further, the Section 7.12 of [RFC5440] is updated to add the 148 following two statements - 150 - The content of IRO is an ordered list of sub-objects representing a 151 series of abstract nodes. An abstract node could be a simple 152 abstract node comprising one node or a group of nodes, for example an 153 AS (comprising of multiple hops within the AS) (refer section 4.3.2 154 of [RFC3209]). 156 - The L Bit of IRO sub-object is set based on the loose or strict hop 157 property of the sub-object, it is set if the sub-object represents a 158 loose hop. If the bit is not set, the sub-object represents a strict 159 hop. The interpretation of Loose bit (L bit) is as per section 160 4.3.3.1 of [RFC3209]. 162 3. Other Considerations 164 Based on the survey, it should be noted that most implementations 165 already support this update in the IRO specification. The other 166 implementations are expected to make an update to the IRO procedures 167 based on this document. 169 During the survey, it was also noted that a minority of the 170 implementations, interpreted the IRO sub-objects as loose. When 171 these implementations interwork with an implementation conforming to 172 this document, the following impact might be seen - 174 o If a non-conforming (to this document) PCC sends an IRO, to a 175 conforming (to this document) PCE, then the PCE may unexpectedly 176 fail to find a path (since the PCC may think of IRO sub-objects as 177 loose hops, but the PCE interprets them as strict hops). 179 o If a conforming PCC sends an IRO containing strict hops to a non- 180 conforming PCE, then the PCE may erroneously return a path that 181 does not comply with the requested strict hops (since the PCE 182 interprets them all as loose hops). The PCC may check the 183 returned path and find the issue or it may end up using an 184 incorrect path. 186 Thus it is RECOMMENDED that network operators ensure that all PCEP 187 speakers in their network conform to this document if they intend to 188 use IRO. 190 4. Security Considerations 192 This update in IRO specification does not introduce any new security 193 considerations, apart from those mentioned in [RFC5440]. 194 Clarification in the supported IRO ordering or Loose hop bit handling 195 will not have any negative security impact. 197 It is worth noting that PCEP operates over TCP. An analysis of the 198 security issues for routing protocols that use TCP (including PCEP) 199 is provided in [RFC6952]. 201 5. IANA Considerations 203 This document makes no requests to IANA for action. 205 6. Acknowledgments 207 A special thanks to PCE chairs for guidance regarding this work. 209 Thanks to Francesco Fondelli for his suggestions in clarifying the L 210 bit usage. 212 Thanks to Adrian Farrel for his review and comments. 214 Thanks to Jonathan Hardwick for document shepherding and providing 215 text in Section 3. 217 Thanks to Deborah Brungard for her comments and being the responsible 218 AD. 220 7. References 222 7.1. Normative References 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, 226 DOI 10.17487/RFC2119, March 1997, 227 . 229 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 230 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 231 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 232 . 234 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 235 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 236 DOI 10.17487/RFC5440, March 2009, 237 . 239 7.2. Informative References 241 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 242 "A Backward-Recursive PCE-Based Computation (BRPC) 243 Procedure to Compute Shortest Constrained Inter-Domain 244 Traffic Engineering Label Switched Paths", RFC 5441, 245 DOI 10.17487/RFC5441, April 2009, 246 . 248 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 249 BGP, LDP, PCEP, and MSDP Issues According to the Keying 250 and Authentication for Routing Protocols (KARP) Design 251 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 252 . 254 Author's Address 256 Dhruv Dhody 257 Huawei Technologies 258 Divyashree Techno Park, Whitefield 259 Bangalore, Karnataka 560066 260 India 262 EMail: dhruv.ietf@gmail.com