doc: Add RFC documents

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]
+