idnits 2.17.1 draft-ietf-pim-rfc4601-update-survey-report-03.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 (September 18, 2013) is 3835 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2117 (Obsoleted by RFC 2362) -- Obsolete informational reference (is this intentional?): RFC 2362 (Obsoleted by RFC 4601, RFC 5059) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Zheng 3 Internet-Draft Huawei Technologies 4 Intended status: Informational Z. Zhang 5 Expires: March 22, 2014 Juniper Networks 6 R. Parekh 7 Cisco Systems 8 September 18, 2013 10 Survey Report on PIM-SM Implementations and Deployments 11 draft-ietf-pim-rfc4601-update-survey-report-03.txt 13 Abstract 15 This document provides supporting documentation to advance the 16 Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol from 17 IETF Proposed Standard to Internet Standard. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 22, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Overview of PIM-SM . . . . . . . . . . . . . . . . . . . . 3 55 1.2. [RFC2026] and [RFC6410] Requirements . . . . . . . . . . . 3 57 2. Survey on Implementations and Deployments . . . . . . . . . . 4 58 2.1. Methodology . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Operator Responses . . . . . . . . . . . . . . . . . . . . 4 60 2.2.1. Description of PIM-SM deployments . . . . . . . . . . 4 61 2.2.2. PIM-SM deployment with other multicast technologies . 4 62 2.2.3. PIM-SM RPs and RP Discovery mechanisms . . . . . . . . 4 63 2.3. Vendor Responses . . . . . . . . . . . . . . . . . . . . . 5 64 2.3.1. [RFC4601] and [RFC2362] implementations . . . . . . . 5 65 2.3.2. Lack of (*,*,RP) and PMBR implementations . . . . . . 5 66 2.3.3. Implementations of other features of RFC4601 . . . . . 5 67 2.4. Key Findings . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 77 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 79 Appendix A. Questionnaire . . . . . . . . . . . . . . . . . . . . 11 80 A.1. PIM Survey for Operators . . . . . . . . . . . . . . . . . 11 81 A.2. PIM Survey for Implementors . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Motivation 87 1.1. Overview of PIM-SM 89 Protocol Independent Multicast - Sparse Mode (PIM-SM) was first 90 published as [RFC2117] in 1997 and then again as [RFC2362] in 1998. 91 The protocol was classified as Experimental in both of these 92 documents. The protocol specification was then rewritten in whole 93 and advanced to Proposed Standard as [RFC4601] in 2006. Considering 94 its multiple independent implementations developed and sufficient 95 successful operational experience gained, the PIM WG decided to 96 advance the PIM-SM protocol to Internet Standard and the survey and 97 this document are part of the work. 99 1.2. [RFC2026] and [RFC6410] Requirements 101 [RFC2026] defines the stages in the standardization process, the 102 requirements for moving a document between stages and the types of 103 documents used during this process. Section 4.1.2 of [RFC2026] 104 states that: "The requirement for at least two independent and 105 interoperable implementations applies to all of the options and 106 features of the specification. In cases in which one or more options 107 or features have not been demonstrated in at least two interoperable 108 implementations, the specification may advance to the Draft Standard 109 level only if those options or features are removed." 111 [RFC6410] updates the Internet Engineering Task Force (IETF) 112 Standards Process defined in [RFC2026]. Primarily, it reduces the 113 Standards Process from three Standards Track maturity levels to two. 114 The second maturity level is a combination of Draft Standard and 115 Standard as specified in [RFC2026]. Section 2.2 of [RFC6410] states 116 that: "(1) There are at least two independent interoperating 117 implementations with widespread deployment and successful operational 118 experience. (3) There are no unused features in the specification 119 that greatly increase implementation complexity." 121 Optional features that do not meet the aforesaid criteria have been 122 identified by the PIM Working Group and will be removed. This 123 document intends to provide supporting documentation to advance the 124 PIM-SM protocol from IETF Proposed Standard to Internet Standard. 126 2. Survey on Implementations and Deployments 128 2.1. Methodology 130 A questionnaire was issued by the PIM WG co-chairs and announced 131 widely to the vendors and operational community to obtain information 132 on PIM-SM implementations and deployments. The Survey concluded on 133 22nd Oct 2012. The responses are kept confidential and only combined 134 results are published here, while responders chose whether their 135 affiliations are confidential. The raw questionnaire is shown in 136 Appendix A, and a compilation of the responses is included in the 137 following section. 139 2.2. Operator Responses 141 Nine operators responded to the survey. They are SWITCH, National 142 Research Council Canada, South Dakota School of Mines and Technology, 143 Motorola Solutions and five anonymous operators. 145 2.2.1. Description of PIM-SM deployments 147 Since 1998, PIM-SM has been deployed for a wide variety of 148 applications: Campus, Enterprise, Research and WAN networks, 149 Broadband ISP and Digital TV. There are five deployments based on 150 [RFC4601] implementations and two on [RFC2362] implementations. 151 PIM-SM for IPv6 has been deployed by three operators. Out of the 152 nine operators, six have deployed PIM-SM implementations from 153 multiple vendors. 155 Operators reported minor inter-operability issues and these were 156 addressed by the vendors. There was no major inter-operability 157 concern reported by the operators. 159 2.2.2. PIM-SM deployment with other multicast technologies 161 Except for one deployment of PIM-SM with Multicast OSPF (MOSPF), all 162 other operators have deployed PIM-SM exclusively. No operators 163 acknowledged deployments of either (*,*,RP) or PIM Multicast Border 164 Route (PMBR) for inter-connection between PIM-SM and other multicast 165 domains. 167 2.2.3. PIM-SM RPs and RP Discovery mechanisms 169 The number of PIM-SM RPs deployed by operators range from a few (up 170 to sixteen) to a massively scaled number (four hundred). Both static 171 configuration and Bootstrap Router (BSR) have been deployed as RP 172 discovery mechanisms. 174 Anycast-RP has been deployed for RP redundancy. Two operators have 175 deployed Anycast-RP using MSDP [RFC3446]. Three operators have 176 deployed Anycast-RP using both MSDP [RFC3446] and PIM [RFC4610] for 177 different scenarios. The best common practice seems to be to use 178 static-RP configuration with Anycast-RP for redundancy. 180 2.3. Vendor Responses 182 Eight vendors reported PIM-SM implementations. They are XORP, Huawei 183 Technologies, Cisco Systems, Motorola Solutions, Juniper Networks and 184 three other anonymous vendors. 186 2.3.1. [RFC4601] and [RFC2362] implementations 188 Four vendors reported PIM-SM implementations based on [RFC4601] and 189 two reported PIM-SM implementations based on [RFC2362]. Two other 190 reported implementations are hybrid. 192 Minor inter-operability issues have been addressed by the vendors 193 over the years and no concern was reported by any vendor. 195 2.3.2. Lack of (*,*,RP) and PMBR implementations 197 Most vendors have not implemented (*,*,RP) state as specified in 198 [RFC4601] either due to lack of deployment requirements or due to 199 security concerns. Similarly, most vendors have also not implemented 200 PMBR due to lack of deployment requirements or because it was 201 considered to be too complex and non-scalable. 203 Only one vendor, XORP, reported (*,*,RP) and PMBR implementation and 204 they were implemented just because these were part of the [RFC4601] 205 specification. 207 2.3.3. Implementations of other features of RFC4601 209 Most vendors have implemented all of the following from [RFC4601] 210 specifications: 212 o SSM 214 o Join suppression 216 o Explicit tracking 218 o Register mechanism 220 o SPT switchover at last-hop router 221 o Assert mechanism 223 o Hashing of group to RP mappings 225 Some vendors do not implement explicit tracking and SSM. 227 2.4. Key Findings 229 PIM-SM has been widely implemented and deployed for different 230 applications. The protocol is sufficiently well specified in 231 [RFC4601] resulting in inter-operable implementation deployed by 232 operators. 234 There are no deployments and only one known implementation of 235 (*,*,RP) and PMBR as specified in [RFC4601]. Hence, it is necessary 236 to remove these features from the specification as required by 237 [RFC2026] and [RFC6410]. 239 3. Security Considerations 241 The PIM WG is aware of at least three (and believes there are more) 242 PIM-SM implementations that support the use of IPsec to protect PIM 243 messages. For at least one of them, IPsec is not part of the PIM 244 implementation itself - one just configures IPsec with SPDs where 245 interface, the ALL_PIM_ROUTERS multicast address, etc., can be used 246 as selectors, according to [RFC5796]. 248 4. IANA Considerations 250 This document makes no request of the IANA. 252 5. Acknowledgements 254 The authors would like to thanks Tim Chown and Bill Atwood who had 255 helped to collect and anonymize the responses as the neutral third- 256 party. Special thanks are also given to Alexander Gall, William F 257 Maton Sotomayor, Steve Bauer, Sonum Mathur, Pavlin Radoslavov, Shuxue 258 Fan, Sameer Gulrajani and to the anonymous responders. 260 6. References 262 6.1. Normative References 264 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 265 3", BCP 9, RFC 2026, October 1996. 267 [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the 268 Standards Track to Two Maturity Levels", BCP 9, RFC 6410, 269 October 2011. 271 6.2. Informative References 273 [RFC2117] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, 274 S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. 275 Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): 276 Protocol Specification", RFC 2117, June 1997. 278 [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, 279 S., Handley, M., and V. Jacobson, "Protocol Independent 280 Multicast-Sparse Mode (PIM-SM): Protocol Specification", 281 RFC 2362, June 1998. 283 [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast 284 Rendevous Point (RP) mechanism using Protocol Independent 285 Multicast (PIM) and Multicast Source Discovery Protocol 286 (MSDP)", RFC 3446, January 2003. 288 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 289 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 290 Protocol Specification (Revised)", RFC 4601, August 2006. 292 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 293 Independent Multicast (PIM)", RFC 4610, August 2006. 295 [RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and 296 Confidentiality in Protocol Independent Multicast Sparse 297 Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010. 299 Appendix A. Questionnaire 301 A.1. PIM Survey for Operators 303 Introduction: 305 PIM-SM was first published as RFC2117 in 1997 and then again as 306 RFC2362 in 1998. The protocol was classified as Experimental in both 307 of these documents. The PIM-SM protocol specification was then 308 rewritten in whole and advanced to Proposed Standard as RFC4601 in 309 2006. Considering the multiple independent implementations developed 310 and the successful operational experience gained, the IETF has 311 decided to advance the PIM-SM routing protocol to Draft Standard. 312 This survey intends to provide supporting documentation to advance 313 the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing 314 protocol from IETF Proposed Standard to Draft Standard. (Due to 315 RFC6410, now the intention is to progress it to Internet Standard. 316 Draft Standard is no longer used.) 318 This survey is issued on behalf of the IETF PIM Working Group. 320 The responses will be collected by a neutral third-party and kept 321 strictly confidential if requested in the response; only the final 322 combined results will be published. Tim Chown and Bill Atwood have 323 agreed to anonymize the response to this Questionnaire. They have a 324 long experience with multicast but have no direct financial interest 325 in this matter, nor ties to any of the vendors involved. Tim is 326 working at University of Southampton, UK, and he has been active in 327 the IETF for many years, including the mboned working group, and he 328 is a co-chair of the 6renum working group. Bill is at Concordia 329 University, Montreal, Canada, and he has been an active participant 330 in the IETF pim working group for over ten years, especially in the 331 area of security. 333 Please send questionnaire responses addressed to them both. The 334 addresses are tjc@ecs.soton.ac.uk and william.atwood@concordia.ca. 335 Please include the string "RFC4601 bis Questionnaire" in the subject 336 field. 338 Before answering the questions, please complete the following 339 background information. 341 Name of the Respondent: 343 Affiliation/Organization: 345 Contact Email: 347 Provide description of PIM deployment: 349 Do you wish to keep the information provided confidential: 351 Questions: 353 1 Have you deployed PIM-SM in your network? 355 2 How long have you had PIM-SM deployed in your network? Do you know 356 if your deployment is based on the most recent RFC4601? 358 3 Have you deployed PIM-SM for IPv6 in your network? 360 4 Are you using equipment with different (multi-vendor) PIM-SM 361 implementations for your deployment? 363 5 Have you encountered any inter-operability or backward- 364 compatibility issues amongst differing implementations? If yes, what 365 are your concerns about these issues? 367 6 Have you deployed both dense mode and sparse mode in your network? 368 If yes, do you route between these modes using features such as 369 *,*,RP or PMBR? 371 7 To what extent have you deployed PIM functionality, like BSR, SSM, 372 and Explicit Tracking? 374 8 Which RP mapping mechanism do you use: Static, AutoRP, or BSR? 376 9 How many RPs have you deployed in your network? 378 10 If you use Anycast-RP, is it Anycast-RP using MSDP (RFC 3446) or 379 Anycast-RP using PIM (RFC4610)? 381 11 Do you have any other comments on PIM-SM deployment in your 382 network? 384 A.2. PIM Survey for Implementors 386 Introduction: 388 PIM-SM was first published as RFC2117 in 1997 and then again as 389 RFC2362 in 1998. The protocol was classified as Experimental in both 390 of these documents. The PIM-SM protocol specification was then 391 rewritten in whole and advanced to Proposed Standard as RFC4601 in 392 2006. Considering the multiple independent implementations developed 393 and the successful operational experience gained, the IETF has 394 decided to advance the PIM-SM routing protocol to Draft Standard. 395 This survey intends to provide supporting documentation to advance 396 the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing 397 protocol from IETF Proposed Standard to Draft Standard. (Due to 398 RFC6410, now the intention is to progress it to Internet Standard. 399 Draft Standard is no longer used.) 401 This survey is issued on behalf of the IETF PIM Working Group. 403 The responses will be collected by a neutral third-party and kept 404 strictly confidential if requested in the response; only the final 405 combined results will be published. Tim Chown and Bill Atwood have 406 agreed to anonymize the response to this Questionnaire. They have a 407 long experience with multicast but have no direct financial interest 408 in this matter, nor ties to any of the vendors involved. Tim is 409 working at University of Southampton, UK, and he has been active in 410 the IETF for many years, including the mboned working group, and he 411 is a co-chair of the 6renum working group. Bill is at Concordia 412 University, Montreal, Canada, and he has been an active participant 413 in the IETF pim working group for over ten years, especially in the 414 area of security. 416 Please send questionnaire responses addressed to them both. The 417 addresses are tjc@ecs.soton.ac.uk and william.atwood@concordia.ca. 418 Please include the string "RFC 4601 bis Questionnaire" in the subject 419 field. 421 Before answering the questions, please complete the following 422 background information. 424 Name of the Respondent: 426 Affiliation/Organization: 428 Contact Email: 430 Provide description of PIM implementation: 432 Do you wish to keep the information provided confidential: 434 Questions: 436 1 Have you implemented PIM-SM? 438 2 Is the PIM-SM implementation based on RFC2362 or RFC4601? 440 3 Have you implemented (*,*, RP) state of RFC4601? What is the 441 rationale behind implementing or omitting (*,*,RP)? 443 4 Have you implemented the PMBR as specified in RFC4601 and RFC2715? 444 What is the rationale behind implementing or omitting PMBR? 446 5 Have you implemented other features and functions of RFC4601: 448 - SSM 450 - Join Suppression 452 - Explicit tracking 454 - Register mechanism 456 - SPT switchover at last-hop router 458 - Assert mechanism 460 - Hashing of group to RP mappings 462 6 Does your PIM-SM implementation support IPv6? 464 7 Have you encountered any inter-operability issues with other PIM 465 implementations in trials or in the field? 467 8 Do you have any other comments or concerns about PIM-SM as 468 specified in RFC4601? 470 Authors' Addresses 472 Lianshu Zheng 473 Huawei Technologies 474 China 476 Email: vero.zheng@huawei.com 478 Zhaohui Zhang 479 Juniper Networks 480 USA 482 Email: zzhang@juniper.net 484 Rishabh Parekh 485 Cisco Systems 486 USA 488 Email: riparekh@cisco.com