idnits 2.17.1 draft-ietf-pim-bdr-00.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: First a PIM Hello MUST be sent with priority 0. Once it has gotten Hello from other PIM neighbors, it knows that it is not eligible to be PIM DR or BDR. It MUST send configured PIM DR priority immediately. It MUST not wait for next hello interval. -- The document date (August 17, 2021) is 982 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-pim-dr-improvement-04 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Mishra 3 Internet-Draft S. Santhanam 4 Intended status: Informational A. Paramasivam 5 Expires: February 18, 2022 J. Goh 6 Cisco Systems 7 G. Mishra 8 Verizon Communications Inc. (VZ) 9 August 17, 2021 11 PIM Backup Designated Router Procedure 12 draft-ietf-pim-bdr-00 14 Abstract 16 On a multi-access network, one of the PIM routers is elected as a 17 Designated Router (DR). On the last hop LAN, the PIM DR is 18 responsible for tracking local multicast listeners and forwarding 19 traffic to these listeners if the group is operating in PIM-SM. In 20 this document, we propose a mechanism to elect backup DR on a shared 21 LAN. A backup DR on LAN would be useful for faster convergence. 22 This draft introduces the concept of a Backup Designated Router (BDR) 23 and the procedure to implement it. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 18, 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Applicability and deviation from draft PIM DR Improvement . . 4 62 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 4 63 4.1. PIM Backup DR (BDR) election procedure . . . . . . . . . 4 64 4.2. Existing PIM DR failure . . . . . . . . . . . . . . . . . 4 65 4.3. Existing PIM BDR failure . . . . . . . . . . . . . . . . 4 66 4.4. New PIM Router addition in network . . . . . . . . . . . 4 67 4.4.1. New PIM router eligible to be PIM DR on shared LAN . 4 68 4.4.2. New PIM router eligible to be PIM BDR on shared LAN . 5 69 4.4.3. New PIM router is not eligible to be PIM DR or BDR on 70 shared LAN . . . . . . . . . . . . . . . . . . . . . 5 71 4.5. Initial case, All new PIM router coming up in shared LAN 5 72 4.6. Benefit . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 6 74 6. Manageability Considerations . . . . . . . . . . . . . . . . 6 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 77 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 78 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 81 1. Introduction 83 On a multi-access LAN such as an Ethernet, one of the PIM routers is 84 elected as a DR. The PIM DR has two roles in the PIM-SM protocol. 85 On the first hop network, the PIM DR is responsible for registering 86 an active source with the Rendezvous Point (RP) if the group is 87 operating in PIM-SM. On the last hop LAN, the PIM DR is responsible 88 for tracking local multicast listeners and forwarding to these 89 listeners if the group is operating in PIM-SM. 91 Consider the following last hop LAN in Figure 1: 93 ( core networks ) 94 | | | 95 | | | 96 R1 R2 R3 97 | | | 98 --(last hop LAN)-- 99 | 100 | 101 (many receivers) 103 Figure 1: Last Hop LAN 105 Assume R1 is elected as the Designated Router. According to 106 [RFC4601], R1 will be responsible for forwarding traffic to that LAN 107 on behalf of any local member. In addition to keeping track of IGMP 108 and MLD membership reports, R1 is also responsible for initiating the 109 creation of source and/or shared trees towards the senders or the 110 RPs. 112 There are multiple reasons for why network could potentially trigger 113 DR re-election. Some of the reasons are 115 1. R1 going down 117 2. Access interface towards shared LAN going down 119 3. Config changed with lower DR priority 121 When any of above network event occurs, PIM DR re-election would be 122 triggered. When a new DR is elected in shared LAN, new DR would be 123 responsible to build a multicast tree towards source / RP. There are 124 some cases, where traffic is crucial and the operator wants to have 125 minimum traffic loss with DR failure. To address this requirement, 126 this draft introduces a backup DR election procedure which would 127 minimize traffic loss during PIM DR failure. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119] . 135 BDR - PIM Backup DR 137 With respect to PIM, this document follows the terminology that has 138 been defined in [RFC4601] . 140 3. Applicability and deviation from draft PIM DR Improvement 142 [I-D.ietf-pim-dr-improvement] defines procedure to solve same problem 143 which was stated in the introduction section of this draft. 144 [I-D.ietf-pim-dr-improvement] introduces new PIM Hello options for 145 election of backup PIM DR. 147 This draft provides mechanism to elect BDR without using any new PIM 148 Hello. 150 4. Protocol Specification 152 4.1. PIM Backup DR (BDR) election procedure 154 [RFC7761] defines procedure for PIM DR election. PIM DR is elected 155 on interface "I" among all PIM routers for which "I" has received PIM 156 Hello. BDR election follows the exact same procedure and the second 157 best PIM DR on shared LAN to be chosen as BDR on interface "I" 159 BDR would perform each of the responsibility of PIM DR except it 160 would not forward traffic on shared LAN. 162 4.2. Existing PIM DR failure 164 When PIM DR fails, PIM DR re-election is triggered on shared LAN. 165 Since BDR is second best DR in LAN, it MUST take over immediately and 166 MUST start forwarding multicast traffic on shared LAN. 168 Again on a shared LAN, new BDR would be elected. and current BDR 169 would be the new DR. 171 4.3. Existing PIM BDR failure 173 When an existing PIM BDR fails, the shared LAN MUST have BDR re- 174 election using the DR election procedure from [RFC7761]. 176 4.4. New PIM Router addition in network 178 When a new PIM router is added in shared LAN, It could be either one 179 of the below defined roles. 181 4.4.1. New PIM router eligible to be PIM DR on shared LAN 183 When a new PIM router is added in a shared LAN and has the highest 184 PIM DR priority configured, if a new router starts propagating its 185 configured DR priority right away, the existing PIM DR would give up 186 its role. Then there would be potential traffic loss till the new DR 187 learns about membership states and builds a multicast tree to the 188 source or RP. 190 To avoid any such traffic loss situation, new PIM router SHOULD send 191 a PIM Hello with priority 0. After 2 (default value, SHOULD have way 192 to configure) PIM Hello interval or IGMP Query Interval (Which ever 193 is higher) it SHOULD start propagating its original configured DR 194 priority. 196 Even though a new PIM router propagating its priority as 0, it MUST 197 start building a multicast tree towards source / RP, This is So that 198 traffic loss could be minimized once it starts sending Hello with 199 configured DR priority. 201 For a brief amount of time, there would be multiple copies of flows 202 present in the multicast core, but a user SHOULD be able to configure 203 whether to send hello with 0 priority or a configured priority. 204 Depending on the application tolerance (Traffic loss Vs Extra traffic 205 in core) the operator can choose option whichever is suitable for 206 network. 208 After a PIM Hello or IGMP Query interval, the network would get 209 stable with only one DR and one BDR. 211 4.4.2. New PIM router eligible to be PIM BDR on shared LAN 213 It SHOULD follow the exact same procedure defined in the previous 214 section. 216 4.4.3. New PIM router is not eligible to be PIM DR or BDR on shared LAN 218 First a PIM Hello MUST be sent with priority 0. Once it has gotten 219 Hello from other PIM neighbors, it knows that it is not eligible to 220 be PIM DR or BDR. It MUST send configured PIM DR priority 221 immediately. It MUST not wait for next hello interval. 223 4.5. Initial case, All new PIM router coming up in shared LAN 225 In this case, initially each of the PIM routers would send Hellos 226 with priorities of 0. If a PIM router receives all Hellos with 227 priorities 0, it MUST send out a Hello with a configured PIM DR 228 priority. Since it is initial startup case, it would take up to one 229 Hello interval to converge. 231 4.6. Benefit 233 1. Easy to implement as it uses an existing PIM procedure to elect 234 DR. 236 2. Does not introduce any new Hello option 238 5. Compatibility 240 6. Manageability Considerations 242 7. IANA Considerations 244 8. Security Considerations 246 9. Acknowledgement 248 The author would like to thank Stig Venaas, Tharak Abraham, Anish 249 Kachinthaya, Anvitha Kachinthaya for helping with original idea. 251 10. Normative References 253 [I-D.ietf-pim-dr-improvement] 254 Zhang, Z., hu, f., Xu, B., and m. mishra, "PIM DR 255 Improvement", draft-ietf-pim-dr-improvement-04 (work in 256 progress), December 2017. 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, 260 DOI 10.17487/RFC2119, March 1997, 261 . 263 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 264 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 265 Protocol Specification (Revised)", RFC 4601, 266 DOI 10.17487/RFC4601, August 2006, 267 . 269 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 270 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 271 Multicast - Sparse Mode (PIM-SM): Protocol Specification 272 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 273 2016, . 275 Authors' Addresses 277 Mankamana Mishra 278 Cisco Systems 279 821 Alder Drive, 280 MILPITAS, CALIFORNIA 95035 281 UNITED STATES 283 Email: mankamis@cisco.com 285 Sridhar Santhanam 286 Cisco Systems 287 821 Alder Drive, 288 MILPITAS, CALIFORNIA 95035 289 UNITED STATES 291 Email: sridsant@cisco.com 293 Aravind Paramasivam 294 Cisco Systems 295 821 Alder Drive, 296 MILPITAS, CALIFORNIA 95035 297 UNITED STATES 299 Email: arparama@cisco.com 301 Joseph Goh 302 Cisco Systems 303 SINGAPORE 305 Email: hocgoh@cisco.com 307 Gyan S. Mishra 308 Verizon Communications Inc. (VZ) 309 13101 Columbia Pike FDC1 Rm 304-D 310 Silver Spring MD 20904 311 UNITED STATES 313 Email: gyan.s.mishra@verizon.com