summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7063.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7063.txt')
-rw-r--r--doc/rfc/rfc7063.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc7063.txt b/doc/rfc/rfc7063.txt
new file mode 100644
index 0000000..27c5829
--- /dev/null
+++ b/doc/rfc/rfc7063.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) L. Zheng
+Request for Comments: 7063 Huawei Technologies
+Category: Informational Z. Zhang
+ISSN: 2070-1721 Juniper Networks
+ R. Parekh
+ Cisco Systems
+ December 2013
+
+
+ Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM)
+ Implementations and Deployments
+
+Abstract
+
+ This document provides supporting documentation to advance the IETF
+ stream's Protocol Independent Multicast - Sparse Mode (PIM-SM)
+ protocol from Proposed Standard to Internet Standard.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7063.
+
+Copyright Notice
+
+ Copyright (c) 2013 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+Zheng, et al. Informational [Page 1]
+
+RFC 7063 Survey Report on PIM-SM December 2013
+
+
+Table of Contents
+
+ 1. Motivation ......................................................3
+ 1.1. Overview of PIM-SM .........................................3
+ 1.2. Requirements of RFCs 2026 and 6410 .........................3
+ 2. Survey on Implementations and Deployments .......................4
+ 2.1. Methodology ................................................4
+ 2.2. Operator Responses .........................................4
+ 2.2.1. Description of PIM-SM Deployments ...................4
+ 2.2.2. PIM-SM Deployment with Other Multicast
+ Technologies ........................................4
+ 2.2.3. PIM-SM Rendezvous Points (RPs) and RP
+ Discovery Mechanisms ................................4
+ 2.3. Vendor Responses ...........................................5
+ 2.3.1. Implementations Based on RFCs 4601 and 2362 .........5
+ 2.3.2. Lack of (*,*,RP) and PMBR Implementations ...........5
+ 2.3.3. Implementations of Other Features of RFC 4601 .......5
+ 2.4. Key Findings ...............................................6
+ 3. Security Considerations .........................................6
+ 4. Acknowledgements ................................................6
+ 5. References ......................................................6
+ 5.1. Normative References .......................................6
+ 5.2. Informative References .....................................7
+ Appendix A. Questionnaire ..........................................8
+ A.1. PIM Survey for Operators ....................................8
+ A.2. PIM Survey for Implementors ................................10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zheng, et al. Informational [Page 2]
+
+RFC 7063 Survey Report on PIM-SM December 2013
+
+
+1. Motivation
+
+1.1. Overview of PIM-SM
+
+ Protocol Independent Multicast - Sparse Mode (PIM-SM) was first
+ published as [RFC2117] in 1997. This version was then obsoleted by
+ [RFC2362] in 1998. The protocol was classified as Experimental in
+ both documents. The protocol specification was then rewritten in
+ whole and advanced to Proposed Standard as [RFC4601] in 2006.
+ Considering its multiple independent implementations developed and
+ sufficient successful operational experience gained, the PIM WG
+ decided to advance the PIM-SM protocol to Internet Standard. The
+ conducted survey and this document are part of the work.
+
+1.2. Requirements of RFCs 2026 and 6410
+
+ [RFC2026] defines the stages in the standardization process, the
+ requirements for moving a document between stages, and the types of
+ documents used during this process. Section 4.1.2 of [RFC2026]
+ states that:
+
+ The requirement for at least two independent and interoperable
+ implementations applies to all of the options and features of the
+ specification. In cases in which one or more options or features
+ have not been demonstrated in at least two interoperable
+ implementations, the specification may advance to the Draft
+ Standard level only if those options or features are removed.
+
+ [RFC6410] updates the IETF Standards Process defined in [RFC2026].
+ Primarily, it reduces the Standards Process from three Standards
+ Track maturity levels to two. The second maturity level is a
+ combination of Draft Standard and Standard as specified in [RFC2026].
+ Section 2.2 of [RFC6410] states that:
+
+ (1) There are at least two independent interoperating
+ implementations with widespread deployment and successful
+ operational experience.
+
+ (2)...
+
+ (3) There are no unused features in the specification that greatly
+ increase implementation complexity.
+
+ Optional features that do not meet the aforesaid criteria have been
+ identified by the PIM Working Group and will be removed. This
+ document provides supporting documentation to advance the IETF
+ stream's Protocol Independent Multicast - Sparse Mode (PIM-SM)
+ protocol from Proposed Standard to Internet Standard.
+
+
+
+Zheng, et al. Informational [Page 3]
+
+RFC 7063 Survey Report on PIM-SM December 2013
+
+
+2. Survey on Implementations and Deployments
+
+2.1. Methodology
+
+ A questionnaire was issued by the PIM WG co-chairs and announced
+ widely to the vendors and operational community to obtain information
+ on PIM-SM implementations and deployments. The survey concluded on
+ 22 Oct 2012. The responses remain confidential and only combined
+ results are published here, while responders chose whether to keep
+ their affiliations confidential. The raw questionnaire is shown in
+ Appendix A, and a compilation of the responses is included in the
+ following section.
+
+2.2. Operator Responses
+
+ Nine operators responded to the survey. They are SWITCH, National
+ Research Council Canada, South Dakota School of Mines and Technology,
+ Motorola Solutions, and five anonymous operators.
+
+2.2.1. Description of PIM-SM Deployments
+
+ Since 1998, PIM-SM has been deployed for a wide variety of
+ applications: Campus, Enterprise, Research and WAN networks,
+ Broadband ISP, and Digital TV. There are five deployments based on
+ [RFC4601] implementations and two on [RFC2362] implementations. PIM-
+ SM for IPv6 has been deployed by three operators. Out of the nine
+ operators, six have deployed PIM-SM implementations from multiple
+ vendors.
+
+ Operators reported minor interoperability issues and these were
+ addressed by the vendors. There was no major interoperability
+ concern reported by the operators.
+
+2.2.2. PIM-SM Deployment with Other Multicast Technologies
+
+ Except for one deployment of PIM-SM with Multicast Extensions to OSPF
+ (MOSPF), all other operators have deployed PIM-SM exclusively. No
+ operators acknowledged deployments of either (*,*,RP) or PIM
+ Multicast Border Route (PMBR) for interconnection between PIM-SM and
+ other multicast domains.
+
+2.2.3. PIM-SM Rendezvous Points (RPs) and RP Discovery Mechanisms
+
+ The number of PIM-SM RPs deployed by operators ranges from a few
+ (e.g., sixteen) to a massively scaled number (four hundred). Both
+ static configuration and Bootstrap Router (BSR) have been deployed as
+ RP discovery mechanisms.
+
+
+
+
+Zheng, et al. Informational [Page 4]
+
+RFC 7063 Survey Report on PIM-SM December 2013
+
+
+ Anycast-RP has been deployed for RP redundancy. Two operators have
+ deployed Anycast-RP using the Multicast Source Discovery Protocol
+ (MSDP) [RFC3446]. Three operators have deployed Anycast-RP using
+ both MSDP [RFC3446] and PIM [RFC4610] for different scenarios. The
+ best common practice seems to be to use static-RP configuration with
+ Anycast-RP for redundancy.
+
+2.3. Vendor Responses
+
+ Eight vendors reported PIM-SM implementations. They are XORP, Huawei
+ Technologies, Cisco Systems, Motorola Solutions, Juniper Networks,
+ and three other anonymous vendors.
+
+2.3.1. Implementations Based on RFCs 4601 and 2362
+
+ Four vendors reported PIM-SM implementations based on [RFC4601] and
+ two reported PIM-SM implementations based on [RFC2362]. Two other
+ reported implementations are hybrids.
+
+ Minor interoperability issues have been addressed by the vendors over
+ the years and no concerns were reported by any vendor.
+
+2.3.2. Lack of (*,*,RP) and PMBR Implementations
+
+ Most vendors have not implemented (*,*,RP) state as specified in
+ [RFC4601] either due to lack of deployment requirements or due to
+ security concerns. Similarly, most vendors have also not implemented
+ PMBR due to lack of deployment requirements or because it was
+ considered too complex and non-scalable.
+
+ Only one vendor, XORP, reported (*,*,RP) and PMBR implementation and
+ they were implemented just because these were part of the [RFC4601]
+ specification.
+
+2.3.3. Implementations of Other Features of RFC 4601
+
+ Most vendors have implemented all of the following from the [RFC4601]
+ specification:
+
+ o Source-Specific Multicast (SSM)
+
+ o Join suppression
+
+ o Explicit tracking
+
+ o Register mechanism
+
+ o Shortest Path Tree (SPT) switchover at last-hop router
+
+
+
+Zheng, et al. Informational [Page 5]
+
+RFC 7063 Survey Report on PIM-SM December 2013
+
+
+ o Assert mechanism
+
+ o Hashing of group to RP mappings
+
+ Some vendors do not implement explicit tracking and SSM.
+
+2.4. Key Findings
+
+ PIM-SM has been widely implemented and deployed for different
+ applications. The protocol is sufficiently well specified in
+ [RFC4601] resulting in interoperable implementation deployed by
+ operators.
+
+ There are no deployments and only one known implementation of
+ (*,*,RP) and PMBR as specified in [RFC4601]. Hence, it is necessary
+ to remove these features from the specification as required by
+ [RFC2026] and [RFC6410].
+
+3. Security Considerations
+
+ The PIM WG is aware of at least three (and believes there are more)
+ PIM-SM implementations that support the use of IPsec to protect PIM
+ messages. For at least one of them, IPsec is not part of the PIM
+ implementation itself -- one just configures IPsec with Security
+ Policy Databases (SPDs) where interface, the ALL_PIM_ROUTERS
+ multicast address, etc., can be used as selectors, according to
+ [RFC5796].
+
+4. Acknowledgements
+
+ The authors would like to thank Tim Chown and Bill Atwood, who helped
+ to collect and anonymize the responses as the neutral third party.
+ Special thanks are also given to Alexander Gall, William F. Maton
+ Sotomayor, Steve Bauer, Sonum Mathur, Pavlin Radoslavov, Shuxue Fan,
+ Sameer Gulrajani, and to the anonymous responders.
+
+5. References
+
+5.1. Normative References
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the
+ Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
+ October 2011.
+
+
+
+
+
+Zheng, et al. Informational [Page 6]
+
+RFC 7063 Survey Report on PIM-SM December 2013
+
+
+5.2. Informative References
+
+ [RFC2117] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
+ S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L.
+ Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM):
+ Protocol Specification", RFC 2117, June 1997.
+
+ [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
+ S., Handley, M., and V. Jacobson, "Protocol Independent
+ Multicast-Sparse Mode (PIM-SM): Protocol Specification",
+ RFC 2362, June 1998.
+
+ [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast
+ Rendevous Point (RP) mechanism using Protocol Independent
+ Multicast (PIM) and Multicast Source Discovery Protocol
+ (MSDP)", RFC 3446, January 2003.
+
+ [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
+ "Protocol Independent Multicast - Sparse Mode (PIM-SM):
+ Protocol Specification (Revised)", RFC 4601, August 2006.
+
+ [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
+ Independent Multicast (PIM)", RFC 4610, August 2006.
+
+ [RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and
+ Confidentiality in Protocol Independent Multicast Sparse
+ Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zheng, et al. Informational [Page 7]
+
+RFC 7063 Survey Report on PIM-SM December 2013
+
+
+Appendix A. Questionnaire
+
+ This section provides copies of the questionnaires exactly as
+ distributed to operators and implementors.
+
+A.1. PIM Survey for Operators
+
+ Introduction:
+
+ PIM-SM was first published as RFC2117 in 1997 and then again as
+ RFC2362 in 1998. The protocol was classified as Experimental in
+ both of these documents. The PIM-SM protocol specification was then
+ rewritten in whole and advanced to Proposed Standard as RFC4601 in
+ 2006. Considering the multiple independent implementations developed
+ and the successful operational experience gained, the IETF has
+ decided to advance the PIM-SM routing protocol to Draft Standard.
+ This survey intends to provide supporting documentation to advance
+ the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing
+ protocol from IETF Proposed Standard to Draft Standard. (Due to
+ RFC6410, now the intention is to progress it to Internet Standard.
+ Draft Standard is no longer used.)
+
+ This survey is issued on behalf of the IETF PIM Working Group.
+
+ The responses will be collected by a neutral third-party and kept
+ strictly confidential if requested in the response; only the final
+ combined results will be published. Tim Chown and Bill Atwood have
+ agreed to anonymize the response to this Questionnaire. They have a
+ long experience with multicast but have no direct financial interest
+ in this matter, nor ties to any of the vendors involved. Tim is
+ working at University of Southampton, UK, and he has been active in
+ the IETF for many years, including the mboned working group, and he
+ is a co-chair of the 6renum working group. Bill is at Concordia
+ University, Montreal, Canada, and he has been an active participant
+ in the IETF pim working group for over ten years, especially in the
+ area of security.
+
+ Please send questionnaire responses addressed to them both. The
+ addresses are tjc@ecs.soton.ac.uk and william.atwood@concordia.ca.
+ Please include the string "RFC4601 bis Questionnaire" in the subject
+ field.
+
+
+
+
+
+
+
+
+
+
+Zheng, et al. Informational [Page 8]
+
+RFC 7063 Survey Report on PIM-SM December 2013
+
+
+ Before answering the questions, please complete the following
+ background information.
+
+ Name of the Respondent:
+
+ Affiliation/Organization:
+
+ Contact Email:
+
+ Provide description of PIM deployment:
+
+ Do you wish to keep the information provided confidential:
+
+ Questions:
+
+ 1 Have you deployed PIM-SM in your network?
+
+ 2 How long have you had PIM-SM deployed in your network? Do you know
+ if your deployment is based on the most recent RFC4601?
+
+ 3 Have you deployed PIM-SM for IPv6 in your network?
+
+ 4 Are you using equipment with different (multi-vendor) PIM-SM
+ implementations for your deployment?
+
+ 5 Have you encountered any inter-operability or backward-
+ compatibility issues amongst differing implementations? If yes,
+ what are your concerns about these issues?
+
+ 6 Have you deployed both dense mode and sparse mode in your network?
+ If yes, do you route between these modes using features such as
+ *,*,RP or PMBR?
+
+ 7 To what extent have you deployed PIM functionality, like BSR, SSM,
+ and Explicit Tracking?
+
+ 8 Which RP mapping mechanism do you use: Static, AutoRP, or BSR?
+
+ 9 How many RPs have you deployed in your network?
+
+ 10 If you use Anycast-RP, is it Anycast-RP using MSDP (RFC 3446) or
+ Anycast-RP using PIM (RFC4610)?
+
+ 11 Do you have any other comments on PIM-SM deployment in your
+ network?
+
+
+
+
+
+
+Zheng, et al. Informational [Page 9]
+
+RFC 7063 Survey Report on PIM-SM December 2013
+
+
+A.2. PIM Survey for Implementors
+
+ Introduction:
+
+ PIM-SM was first published as RFC2117 in 1997 and then again as
+ RFC2362 in 1998. The protocol was classified as Experimental in both
+ of these documents. The PIM-SM protocol specification was then
+ rewritten in whole and advanced to Proposed Standard as RFC4601 in
+ 2006. Considering the multiple independent implementations developed
+ and the successful operational experience gained, the IETF has
+ decided to advance the PIM-SM routing protocol to Draft Standard.
+ This survey intends to provide supporting documentation to advance
+ the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing
+ protocol from IETF Proposed Standard to Draft Standard. (Due to
+ RFC6410, now the intention is to progress it to Internet Standard.
+ Draft Standard is no longer used.)
+
+ This survey is issued on behalf of the IETF PIM Working Group.
+
+ The responses will be collected by a neutral third-party and kept
+ strictly confidential if requested in the response; only the final
+ combined results will be published. Tim Chown and Bill Atwood have
+ agreed to anonymize the response to this Questionnaire. They have a
+ long experience with multicast but have no direct financial interest
+ in this matter, nor ties to any of the vendors involved. Tim is
+ working at University of Southampton, UK, and he has been active in
+ the IETF for many years, including the mboned working group, and he
+ is a co-chair of the 6renum working group. Bill is at Concordia
+ University, Montreal, Canada, and he has been an active participant
+ in the IETF pim working group for over ten years, especially in the
+ area of security.
+
+ Please send questionnaire responses addressed to them both. The
+ addresses are tjc@ecs.soton.ac.uk and william.atwood@concordia.ca.
+ Please include the string "RFC 4601 bis Questionnaire" in the subject
+ field.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zheng, et al. Informational [Page 10]
+
+RFC 7063 Survey Report on PIM-SM December 2013
+
+
+ Before answering the questions, please complete the following
+ background information.
+
+ Name of the Respondent:
+
+ Affiliation/Organization:
+
+ Contact Email:
+
+ Provide description of PIM implementation:
+
+ Do you wish to keep the information provided confidential:
+
+ Questions:
+
+ 1 Have you implemented PIM-SM?
+
+ 2 Is the PIM-SM implementation based on RFC2362 or RFC4601?
+
+ 3 Have you implemented (*,*, RP) state of RFC4601? What is the
+ rationale behind implementing or omitting (*,*,RP)?
+
+ 4 Have you implemented the PMBR as specified in RFC4601 and RFC2715?
+ What is the rationale behind implementing or omitting PMBR?
+
+ 5 Have you implemented other features and functions of RFC4601:
+
+ - SSM
+
+ - Join Suppression
+
+ - Explicit tracking
+
+ - Register mechanism
+
+ - SPT switchover at last-hop router
+
+ - Assert mechanism
+
+ - Hashing of group to RP mappings
+
+ 6 Does your PIM-SM implementation support IPv6?
+
+ 7 Have you encountered any inter-operability issues with other PIM
+ implementations in trials or in the field?
+
+ 8 Do you have any other comments or concerns about PIM-SM as
+ specified in RFC4601?
+
+
+
+Zheng, et al. Informational [Page 11]
+
+RFC 7063 Survey Report on PIM-SM December 2013
+
+
+Authors' Addresses
+
+ Lianshu Zheng
+ Huawei Technologies
+ China
+
+ EMail: vero.zheng@huawei.com
+
+
+ Zhaohui Zhang
+ Juniper Networks
+ USA
+
+ EMail: zzhang@juniper.net
+
+
+ Rishabh Parekh
+ Cisco Systems
+ USA
+
+ EMail: riparekh@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zheng, et al. Informational [Page 12]
+