idnits 2.17.1 draft-dhody-pce-iro-survey-02.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 -- The document date (December 26, 2014) is 3409 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-pce-pcep-domain-sequence-06 == Outdated reference: A later version (-02) exists of draft-dhody-pce-iro-update-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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 Intended status: Informational December 26, 2014 5 Expires: June 29, 2015 7 Informal Survey into Include Route Object (IRO) Implementations in Path 8 Computation Element communication Protocol (PCEP) 9 draft-dhody-pce-iro-survey-02 11 Abstract 13 During discussions of a document to provide a standard representation 14 and encoding of Domain-Sequence within the Path Computation Element 15 (PCE) communication Protocol (PCEP) for communications between a Path 16 Computation Client (PCC) and a PCE, or between two PCEs. It was 17 determined that there was a need for clarification with respect to 18 the ordered nature of the Include Route Object (IRO). 20 Since there was a proposal to have a new IRO type with ordering, as 21 well as handling of Loose bit (L-Bit), it felt necessary to conduct a 22 survey of the existing and planned implementations. 24 This document summarizes the survey questions and captures the 25 results. Some conclusions are also presented. 27 This survey was informal and conducted via email. Responses were 28 collected and anonymized by the PCE working group chairs. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on June 29, 2015. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Survey Details . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. Survey Preamble . . . . . . . . . . . . . . . . . . . . . 3 67 2.2. Survey Questions . . . . . . . . . . . . . . . . . . . . 3 68 3. Respondents . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5.1. Proposed Action . . . . . . . . . . . . . . . . . . . . . 7 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 9.2. Informative References . . . . . . . . . . . . . . . . . 8 78 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 10 80 1. Introduction 82 The Path Computation Element Communication Protocol (PCEP) provides 83 mechanisms for Path Computation Elements (PCEs) to perform path 84 computations in response to Path Computation Clients (PCCs) requests. 86 [RFC5440] defines the Include Route Object (IRO) to specify that the 87 computed path must traverse a set of specified network elements. The 88 specification did not mention if IRO is an ordered or un-ordered list 89 of sub-objects. It mentioned that the L bit (loose) has no meaning 90 within an IRO. 92 [RFC5441] suggested the use of IRO to indicate the sequence of 93 domains to be traversed during inter-domain path computation. 95 During discussion of [I-D.ietf-pce-pcep-domain-sequence] it was 96 proposed to have a new IRO type with ordered nature, as well as 97 handling of L bit. 99 In order to discover the current state of affairs amongst 100 implementations a survey of the existing and planned implementations 101 was conducted. This survey was informal and conducted via email. 102 Responses were collected and anonymized by the PCE working group 103 chair. 105 This document summarizes the survey questions and captures the 106 results. Some conclusions are also presented. 108 2. Survey Details 110 2.1. Survey Preamble 112 The survey was introduced with the following text. 114 Hi PCE WG. 116 To address the issues associated with draft-ietf-pce-pcep-domain- 117 sequence and "Include Route Object" in PCEP, Dhruv has proposed to 118 start a small survey. If implementers agree that we need to clarify 119 this, they would be much welcome to answer the attached questions. 121 Dhruv will process the results, but to improve confidentiality, 122 answers may be sent privately to the chairs. 124 Thanks, 126 JP & Julien, on behalf of Dhruv 128 2.2. Survey Questions 130 The following survey questions were asked, the survey questionnaire 131 is listed verbatim below. 133 During discussion of draft-ietf-pce-pcep-domain-sequence-05, 134 it has been noted that RFC 5440 does not define whether the 135 sub-objects in the IRO are ordered or unordered. 137 We would like to do an informal and *confidential* survey 138 of current implementations, to help clarify this 139 situation. 141 1. IRO Encoding 142 a. Does your implementation construct IRO? 144 b. If your answer to part (a) is Yes, does your 145 implementation construct the IRO as an ordered list 146 always, sometimes or never? 148 c. If your answer to part (b) is Sometimes, what criteria 149 do you use to decide if the IRO is an ordered or 150 unordered list? 152 d. If your answer to part (b) is Always or Sometimes, does 153 your implementation construct the IRO as a sequence of 154 strict hops or as a sequence of loose hops? 156 2. IRO Decoding 158 a. Does your implementation decode IRO? 160 b. If your answer to part (a) is Yes, does your 161 implementation interpret the decoded IRO as an ordered 162 list always, sometimes or never? 164 c. If your answer to part (b) is Sometimes, what criteria do 165 you use to decide if the IRO is an ordered or unordered 166 list? 168 d. If your answer to part (b) is Always or Sometimes, does 169 your implementation interpret the IRO as a sequence of 170 strict hops or as a sequence of loose hops? 172 3. Impact 174 a. Will there be an impact to your implementation if RFC 5440 175 is updated to state that the IRO is an ordered list? 177 b. Will there be an impact to your implementation if RFC 5440 178 is updated to state that the IRO is an unordered list? 180 c. If RFC 5440 is updated to state that the IRO is an 181 ordered list, will there be an impact to your 182 implementation if RFC 5440 is also updated to allow IRO 183 sub-objects to use the loose bit (L-bit)? 185 4. Respondents 187 a. Are you a Vendor/Research Lab/Software House/Other (please 188 specify)? 190 b. If your answer to part (a) is Vendor, is the 191 implementation for a shipping product, product under 192 development or a prototype? 194 3. Respondents 196 Total 9 responses were received from vendors, software houses, and 197 research labs. Vendors made responses for their current shipping 198 products as well as products that they currently have under 199 development. 201 o Total Number of Respondents: 9 203 * Vendors: 4 205 + Shipping Product: 1 207 + Product Under Development: 1 209 + Prototype: 1 211 + Unknown: 1 213 * Software House: 1 215 * Research Labs: 2 217 + Operator's Research Facility: 1 219 * Open Source: 1 221 + Shipped Release: 1 223 * Others (or Unknown): 1 225 4. Results 226 +----+---------------------------------------------+----------------+ 227 | | Questions | Response | 228 +----+---------------------------------------------+----------------+ 229 | 1a | Does your implementation construct IRO? | yes (9) | 230 | | | | 231 | 1b | Does your implementation construct the IRO | always (8), | 232 | | as an ordered list always, sometimes or | never (1) | 233 | | never? | | 234 | | | | 235 | 1c | What criteria do you use to decide if the | none (9) | 236 | | IRO is an ordered or unordered list? | | 237 | | | | 238 | 1d | Does your implementation construct the IRO | strict (5), | 239 | | as a sequence of strict hops or as a | loose (2), | 240 | | sequence of loose hops? | both (2) | 241 +----+---------------------------------------------+----------------+ 243 Table 1: IRO Encoding 245 Regarding IRO encodings, most implementations construct IRO in an 246 ordered fashion and consider it to be an ordered list. More than 247 half of implementation under survey consider the IRO sub-objects as 248 strict hops, others consider loose or support both. 250 +----+--------------------------------------------+-----------------+ 251 | | Questions | Response | 252 +----+--------------------------------------------+-----------------+ 253 | 2a | Does your implementation decode IRO? | yes (9) | 254 | | | | 255 | 2b | Does your implementation interpret the | always (7), | 256 | | decoded IRO as an ordered list always, | sometimes (1), | 257 | | sometimes or never? | never (1) | 258 | | | | 259 | 2c | What criteria do you use to decide if the | none (9) | 260 | | IRO is an ordered or unordered list? | | 261 | | | | 262 | 2d | Does your implementation interpret the IRO | strict (5), | 263 | | as a sequence of strict hops or as a | loose (2), both | 264 | | sequence of loose hops? | (2) | 265 +----+--------------------------------------------+-----------------+ 267 Table 2: IRO Decoding 269 Regarding IRO decoding, most implementations interpret IRO as an 270 ordered list. More than half of implementation under survey consider 271 the IRO sub-objects as strict hops, others consider loose or support 272 both. 274 +----+----------------------------------------------+---------------+ 275 | | Questions | Response | 276 +----+----------------------------------------------+---------------+ 277 | 3a | Will there be an impact to your | none (9) | 278 | | implementation if [RFC5440] is updated to | | 279 | | state that the IRO is an ordered list? | | 280 | | | | 281 | 3b | Will there be an impact to your | yes (5), no | 282 | | implementation if [RFC5440] is updated to | (4) | 283 | | state that the IRO is an unordered list? | | 284 | | | | 285 | 3c | will there be an impact to your | none (5), | 286 | | implementation if [RFC5440] is also updated | yes(1), yes- | 287 | | to allow IRO sub-objects to use the loose | but-small (3) | 288 | | bit (L-bit)? | | 289 +----+----------------------------------------------+---------------+ 291 Table 3: Impact 293 It is interesting to note that most implementation that responded to 294 the survey finds that there is no impact to their existing or under- 295 development implementation if [RFC5440] is updated to state that the 296 IRO as an ordered list. Further most implementations find that 297 support for loose bit (L-bit) for IRO has minimal or no impact on 298 their implementation. 300 5. Conclusions 302 The results shown in this survey seems to suggest that most 303 implementations would be fine with updating [RFC5440] to specify IRO 304 as an ordered list with no impact on the shipping or under- 305 development products. It is also the conclusion of this survey to 306 suggest that it would be helpful to update [RFC5440] to enable 307 support for loose bit (L-bit) such that both strict and loose hops 308 could be supported in the IRO. 310 5.1. Proposed Action 312 The proposed action is as follows: 314 o Update [RFC5440] to specify IRO as an ordered list. 316 o Update [RFC5440] to specify support for loose bit (L-bit) for IRO. 318 o Remove the new IRO option from draft-ietf-pce-pcep-domain- 319 sequence-05. 321 An update to IRO specification are proposed in 322 [I-D.dhody-pce-iro-update]. 324 6. Security Considerations 326 This survey defines no protocols or procedures and so includes no 327 security-related protocol changes. Clarification in the supported 328 IRO ordering or loose bit handling will not have any negative 329 security impact. The survey responses in this document were 330 collected by email and that email was not authenticated, although 331 responses were sent to the respondents that might have triggered 332 alarms if the responses were spoofed. Spoofed or malicious responses 333 could represent an attack on the IETF process and so this survey 334 should be treated with some caution where there is reason to suspect 335 such an attack. Further, this survey was compiled and anonymized by 336 the working group chairs. 338 7. IANA Considerations 340 This informational document makes no requests to IANA for action. 342 8. Acknowledgments 344 A special thanks to author of [I-D.farrel-ccamp-ero-survey], this 345 document borrow some of the structure and text from it. 347 9. References 349 9.1. Normative References 351 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 352 (PCE) Communication Protocol (PCEP)", RFC 5440, March 353 2009. 355 9.2. Informative References 357 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 358 Backward-Recursive PCE-Based Computation (BRPC) Procedure 359 to Compute Shortest Constrained Inter-Domain Traffic 360 Engineering Label Switched Paths", RFC 5441, April 2009. 362 [I-D.ietf-pce-pcep-domain-sequence] 363 Dhody, D., Palle, U., and R. Casellas, "Standard 364 Representation Of Domain-Sequence", draft-ietf-pce-pcep- 365 domain-sequence-06 (work in progress), October 2014. 367 [I-D.farrel-ccamp-ero-survey] 368 Farrel, A., "Informal Survey into Explicit Route Object 369 Implementations in Generalized Multiprotocol Labels 370 Switching Signaling Implementations", draft-farrel-ccamp- 371 ero-survey-00 (work in progress), May 2006. 373 [I-D.dhody-pce-iro-update] 374 Dhody, D., "Update to Include Route Object (IRO) 375 specification in Path Computation Element communication 376 Protocol (PCEP)", draft-dhody-pce-iro-update-01 (work in 377 progress), October 2014. 379 Appendix A. Contributor Addresses 381 Julien Meuric 382 Orange 383 France 385 EMail: julien.meuric@orange.com 387 Jonathan Hardwick 388 Metaswitch 389 100 Church Street 390 Enfield EN2 6BQ 391 UK 393 EMail: jonathan.hardwick@metaswitch.com 395 Author's Address 397 Dhruv Dhody 398 Huawei Technologies 399 Leela Palace 400 Bangalore, Karnataka 560008 401 India 403 EMail: dhruv.ietf@gmail.com