idnits 2.17.00 (12 Aug 2021) /tmp/idnits42056/draft-mmcbride-pim-refresh-problem-statement-00.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 208. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 201. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 224. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 230. 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 41 instances of too long lines in the document, the longest one being 2 characters 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 5300 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Fenner' is defined on line 171, but no explicit reference was found in the text == Unused Reference: 'MVPN' is defined on line 174, but no explicit reference was found in the text == Unused Reference: 'MORIN' is defined on line 179, 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. -------------------------------------------------------------------------------- 2 Network Working Group Mike McBride 3 Internet Draft 4 Intended Status: Informational 5 Expires: May 2008 7 November 2007 9 PIM Refresh Reduction Problem Statement 11 draft-mmcbride-pim-refresh-problem-statement-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The PIM Working Group has a charter item to provide solutions to 43 reduce the effects of periodic join/prune processing in PIM. The 44 L3VPN Working Group identified the periodic messaging of PIM as a 45 potential future scaling problem for PIM based MVPNs. This document 46 identifies the issues we are trying to solve with PIM refresh 47 reduction. 49 Table of Contents 51 1 Introduction ....................................... 2 52 2 History ............................................ 3 53 3 Problem ............................................ 3 54 4 Solutions .......................................... 4 55 5 Security Considerations ............................ 4 56 6 Iana Considerations ................................ 5 57 7 Acknowledgments .................................... 5 58 8 Normative References ............................... 5 59 9 Informative References ............................. 5 60 10 Authors' Addresses ................................. 5 61 11 Full Copyright Statement ........................... 6 62 12 Intellectual Property .............................. 6 64 1. Introduction 66 PIM Joins are refreshed every 60 seconds by a downstream router to 67 keep multicast state alive at the upstream router. The more number of 68 states, the more control traffic required for refresh. 70 The PIM Working Group has a charter item to provide solutions to 71 reduce the effects of periodic join/prune processing in PIM. The 72 L3VPN Working Group identified the periodic messaging of PIM as a 73 potential future scaling problem for PIM based MVPNs. This document 74 identifies the issues we are trying to solve with PIM refresh 75 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. 85 Although there were disagreements on certain details, the design team 86 had rough agreement on a Join/Prune acknowledgement solution. But 87 then the team decided to step back and ask the L3VPN WG for a 88 requirements document to see if this is really an area for which we 89 should provide a solution. 91 The PIM WG discussed the future efforts we wanted to make to PIM. The 92 primary focus, of the working group, at the time was in getting the 93 PIMv2 draft completed. There are many enhancements we could make to 94 PIM. Should we refrain from such future PIM enhancements or should we 95 leave PIM alone and close the working group? Or should we start going 96 down the path of PIMv3? 98 The L3VPN did produce an MVPN requirements document which did help to 99 understand the future scalability requirements of MVPN. But it didn't 100 help in understanding at what point PIM scalability would cause a 101 problem for PIM based MVPNs. 103 In 2007, with the PIMv2 draft complete and the PIM WG tasked with a 104 new Charter, it was decided it would be of benefit to provide 105 enhancements to PIM. The WG has determined there is additional work 106 to be accomplished and is chartered to standardize extensions to RFC 107 4601 - Protocol Independent Multicast Version 2 - Sparse Mode. These 108 PIM extensions will include PIM refresh reduction. 110 3. Problem 112 As previously listed, the PIM WG has decided to discover ways to 113 reduce the effects of the periodic Join/Prune processing in PIM. This 114 could specifically help in the future scalability of PIM based MVPN, 115 but is certainly not limited to that solution. 117 PIM Joins are refreshed every 60 seconds by a downstream router to 118 keep multicast state alive at the upstream router. The more number of 119 states, the more control traffic is required for refresh. Scaling 120 could become an issue, especially with VPNs where there could be 1000 121 MVPNs with 100 mroute entries each and 10 downstream interfaces (1 122 million state refreshes every minute in steady state). 124 Route changes cause Joins to be sent to the new RPF neighbor. If the 125 Join is lost, the disruption of traffic is for at least 60 seconds. 126 There is no reliability in the Join/Prune exchange between downstream 127 and upstream routers. Larger values of holdtime in the Join/Prune PDU 128 will reduce the frequency of refreshes, but can cause larger 129 convergence delays. 131 4. Solutions 133 This is not a solutions draft. Subsequent to this draft, there will 134 be drafts which outline solutions to this problem. The following 135 ideas have been discussed as possible solutions to be further 136 specified: 138 + Join/Prune Ack extension to PIM. 140 + Hard state (TCP) solution. 142 + A PIMv3 containing strong RPF from forwarding plane, explicit 143 tracking of all neighbors and hard state 145 + Include checksums in Hello messages rather than sending periodic 146 JPs. 148 + Use long holdtimes. 150 5. Security Considerations 152 This document is a problem statement, which describes the reduction 153 of PIM messaging, and does not introduce security considerations by 154 itself. Any potential solution must protect against exploiting PIM 155 as specified in RFC 4601. 157 6. Iana Considerations 159 This document does not require any action on the part of IANA. 161 7. Acknowledgments 163 We'd like to thank Dino Farinacci, Suresh Boddapati, Tom Pusateri, 164 Marshall Eubanks, Robert Kebler, Venu Hemige, Yiqun Cai, Yakov 165 Rekhter, Yetik Serbest, Albert Tian, for their work on the pim 166 refresh design team and helping the PIM WG to understand a few 167 possible solutions. 169 8. Normative References 171 [Fenner] B. Fenner, "Protocol Independent Multicast - Sparse Mode 172 (PIM-SM)". RFC 4601 174 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, July 2007, 175 draft-ietf-l3vpn-2547bis-mcast-05.txt 177 9. Informative References 179 [MORIN] T. Morin, "Requirements for Multicast in L3 Provider- 180 Provisioned VPNs", RFC 4834 182 10. Authors' Addresses 184 Mike McBride 185 mmcbride@cisco.com 187 11. Full Copyright Statement 189 Copyright (C) The IETF Trust (2007). 191 This document is subject to the rights, licenses and restrictions 192 contained in BCP 78, and except as set forth therein, the authors 193 retain all their rights. 195 This document and the information contained herein are provided on an 196 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 197 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 198 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 199 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 200 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 201 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 203 12. Intellectual Property 205 By submitting this Internet-Draft, each author represents that any 206 applicable patent or other IPR claims of which he or she is aware 207 have been or will be disclosed, and any of which he or she becomes 208 aware will be disclosed, in accordance with Section 6 of BCP 79. 210 The IETF takes no position regarding the validity or scope of any 211 Intellectual Property Rights or other rights that might be claimed to 212 pertain to the implementation or use of the technology described in 213 this document or the extent to which any license under such rights 214 might or might not be available; nor does it represent that it has 215 made any independent effort to identify any such rights. Information 216 on the procedures with respect to rights in RFC documents can be 217 found in BCP 78 and BCP 79. 219 Copies of IPR disclosures made to the IETF Secretariat and any 220 assurances of licenses to be made available, or the result of an 221 attempt made to obtain a general license or permission for the use of 222 such proprietary rights by implementers or users of this 223 specification can be obtained from the IETF on-line IPR repository at 224 http://www.ietf.org/ipr. 226 The IETF invites any interested party to bring to its attention any 227 copyrights, patents or patent applications, or other proprietary 228 rights that may cover technology that may be required to implement 229 this standard. Please address the information to the IETF at ietf- 230 ipr@ietf.org.