idnits 2.17.00 (12 Aug 2021) /tmp/idnits24746/draft-mmcbride-pim-refresh-problem-statement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 210. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 203. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 219. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 226. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 232. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** An RFC 3978, Section 5.1 paragraph was found, but not on the first page, as required. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 31 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2007) is 5294 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Morin' is mentioned on line 98, but not defined == Unused Reference: 'MVPN' is defined on line 176, but no explicit reference was found in the text == Unused Reference: 'MORIN' is defined on line 181, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (ref. 'Fenner') (Obsoleted by RFC 7761) == Outdated reference: draft-ietf-l3vpn-2547bis-mcast has been published as RFC 6513 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Mike McBride 2 Internet Draft Cisco Systems 3 Intended Status: Informational 4 Expires: May 2008 6 November 2007 8 PIM Refresh Reduction Problem Statement 10 draft-mmcbride-pim-refresh-problem-statement-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The PIM Working Group has a PIM refresh reduction charter goal. The 42 solution to this goal will help reduce the periodic join/prune 43 processing in PIM. The L3VPN Working Group identified this periodic 44 messaging of PIM as a potential scaling problem for PIM based MVPNs. 45 This document identifies the issues we are trying to solve with PIM 46 refresh reduction. 48 Table of Contents 50 1 Introduction ....................................... 2 51 2 History ............................................ 3 52 3 Problem ............................................ 3 53 4 Solutions .......................................... 4 54 5 Security Considerations ............................ 4 55 6 Iana Considerations ................................ 5 56 7 Acknowledgments .................................... 5 57 8 Normative References ............................... 5 58 9 Informative References ............................. 5 59 10 Authors' Addresses ................................. 5 60 11 Full Copyright Statement ........................... 6 61 12 Intellectual Property .............................. 6 63 1. Introduction 65 PIM Joins are refreshed every 60 seconds by a downstream router to 66 keep multicast state alive at the upstream router. With an increase 67 in state there is an increase in control traffic required for 68 refresh. 70 The PIM Working Group has a PIM refresh reduction charter goal. The 71 solution to this goal will help reduce the periodic join/prune 72 processing in PIM. The L3VPN Working Group identified this periodic 73 messaging of PIM as a potential scaling problem for PIM based MVPNs. 74 This document identifies the issues we are trying to solve with PIM 75 refresh reduction. 77 2. History 79 At the November 2004 IETF, the L3VPN WG identified the effects of 80 periodic Join/Prune processing in PIM as a potential scalability 81 problem for PIM based MVPNs and asked that the PIM WG provide a 82 solution. The PIM WG subsequently created a pim refresh design team 83 to understand the problem area and provide a solution in needed. 85 Although there were disagreements on certain details, the design team 86 had rough agreement on a Join/Prune acknowledgement solution. But, 87 before recommending any solution, the PIM WG decided to ask the L3VPN 88 WG for a requirements (or similar) document to help determine if this 89 is really an area for which a solution is needed. 91 The PIM WG continued to discuss the future efforts we wanted to make 92 to PIM. The primary focus, of the working group, at the time was in 93 completing the PIMv2 [Fenner] draft. There are many enhancements we 94 could make to PIM. Do we refrain from future PIM enhancements and 95 close the working group? Or should we start going down the path of a 96 major PIMv3 revision? 98 The L3VPN did produce an MVPN requirements document [Morin] which did 99 help to better understand the future scalability requirements of 100 MVPN. But that requirements document didn't help in understanding at 101 what point PIM messaging could cause a scalability problem for PIM 102 based MVPNs. 104 In 2007, with the PIMv2 draft complete and the PIM WG tasked with a 105 new Charter, it was decided it would be of benefit for the WG to 106 provide enhancements to PIM. The WG has determined there is 107 additional work to be accomplished and is now chartered to 108 standardize extensions to RFC 4601 - Protocol Independent Multicast 109 Version 2 - Sparse Mode. These PIM extensions will include PIM 110 refresh reduction. 112 3. Problem 114 The PIM WG has decided to provide a solution(s) to reduce the effects 115 of the periodic Join/Prune processing in PIM. This solution could 116 help in the future scalability of PIM based MVPN as well as other PIM 117 deployments. 119 PIM Joins are refreshed every 60 seconds by a downstream router to 120 keep multicast state alive at the upstream router. With an increase 121 in multicast state there is an increase in PIM control traffic 122 required for refresh. Scaling could become an issue with MVPNs where, 123 for instance, there could be 1000 MVPNs having 100 mroute entries 124 each along with 10 RPF neighbors. One million entries would then be 125 sent out on the MDT. 127 Additionally, route changes cause Joins to be sent to the new RPF 128 neighbor. If the Join is lost, there will be disruption of traffic. 129 There is no reliability in the Join/Prune exchange between downstream 130 and upstream routers. Larger values of holdtime in the Join/Prune PDU 131 would reduce the frequency of refreshes, but could also cause larger 132 convergence delays. 134 4. Solutions 136 This is not a solutions draft. Subsequent to this draft, there will 137 be drafts which outline solutions to this problem. The following 138 ideas have been discussed as possible solutions to be further 139 specified: 141 + Join/Prune Ack extension to PIM. 143 + Hard state (TCP) solution. 145 + PIMv3 (strong RPF, explicit tracking, hard state, etc) 147 + Include checksums in Hello messages rather than sending periodic 148 JPs. 150 + Use long holdtimes. 152 5. Security Considerations 154 This document is a problem statement, which describes the reduction 155 of PIM messaging, and does not introduce security considerations by 156 itself. Any potential solution must protect against exploiting PIM 157 as specified in RFC 4601. 159 6. Iana Considerations 161 This document does not require any action on the part of IANA. 163 7. Acknowledgments 165 We'd like to thank Dino Farinacci, Suresh Boddapati, Tom Pusateri, 166 Marshall Eubanks, Robert Kebler, Venu Hemige, Yiqun Cai, Yakov 167 Rekhter, Yetik Serbest, Albert Tian, for their work on the pim 168 refresh design team and helping the PIM WG to define a few possible 169 solutions. 171 8. Normative References 173 [Fenner] B. Fenner, "Protocol Independent Multicast - Sparse Mode 174 (PIM-SM)". RFC 4601 176 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, July 2007, 177 draft-ietf-l3vpn-2547bis-mcast-05.txt 179 9. Informative References 181 [MORIN] T. Morin, "Requirements for Multicast in L3 Provider- 182 Provisioned VPNs", RFC 4834 184 10. Authors' Addresses 186 Mike McBride 187 mmcbride@cisco.com 189 11. Full Copyright Statement 191 Copyright (C) The IETF Trust (2007). 193 This document is subject to the rights, licenses and restrictions 194 contained in BCP 78, and except as set forth therein, the authors 195 retain all their rights. 197 This document and the information contained herein are provided on an 198 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 199 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 200 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 201 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 202 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 203 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 205 12. Intellectual Property 207 By submitting this Internet-Draft, each author represents that any 208 applicable patent or other IPR claims of which he or she is aware 209 have been or will be disclosed, and any of which he or she becomes 210 aware will be disclosed, in accordance with Section 6 of BCP 79. 212 The IETF takes no position regarding the validity or scope of any 213 Intellectual Property Rights or other rights that might be claimed to 214 pertain to the implementation or use of the technology described in 215 this document or the extent to which any license under such rights 216 might or might not be available; nor does it represent that it has 217 made any independent effort to identify any such rights. Information 218 on the procedures with respect to rights in RFC documents can be 219 found in BCP 78 and BCP 79. 221 Copies of IPR disclosures made to the IETF Secretariat and any 222 assurances of licenses to be made available, or the result of an 223 attempt made to obtain a general license or permission for the use of 224 such proprietary rights by implementers or users of this 225 specification can be obtained from the IETF on-line IPR repository at 226 http://www.ietf.org/ipr. 228 The IETF invites any interested party to bring to its attention any 229 copyrights, patents or patent applications, or other proprietary 230 rights that may cover technology that may be required to implement 231 this standard. Please address the information to the IETF at ietf- 232 ipr@ietf.org.