idnits 2.17.1 draft-ietf-pim-dr-improvement-10.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 30, 2020) is 1297 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-pim-bfd-p2mp-use-case-04 == Outdated reference: A later version (-05) exists of draft-mankamana-pim-bdr-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM WG Z. Zhang 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track F. Hu 5 Expires: April 3, 2021 Individual 6 B. Xu 7 ZTE Corporation 8 M. Mishra 9 Cisco Systems 10 September 30, 2020 12 Protocol Independent Multicast - Sparse Mode (PIM-SM) Designated Router 13 (DR) Improvement 14 draft-ietf-pim-dr-improvement-10 16 Abstract 18 Protocol Independent Multicast - Sparse Mode (PIM-SM) is a widely 19 deployed multicast protocol. As deployment for the PIM protocol is 20 growing day by day, a user expects lower packet loss and faster 21 convergence regardless of the cause of the network failure. This 22 document defines an extension to the existing protocol, which 23 improves the PIM protocol's stability with respect to packet loss and 24 convergence time when the PIM Designated Router (DR) role changes. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 3, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Protocol Specification . . . . . . . . . . . . . . . . . . . 4 64 3.1. Election Algorithm . . . . . . . . . . . . . . . . . . . 5 65 3.2. Sending Hello Messages . . . . . . . . . . . . . . . . . 5 66 3.3. Receiving Hello Messages . . . . . . . . . . . . . . . . 6 67 3.4. Working with the DRLB function . . . . . . . . . . . . . 6 68 4. PIM Hello message format . . . . . . . . . . . . . . . . . . 7 69 4.1. DR Address Option format . . . . . . . . . . . . . . . . 7 70 4.2. BDR Address Option format . . . . . . . . . . . . . . . . 7 71 4.3. Error handling . . . . . . . . . . . . . . . . . . . . . 7 72 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 8 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 9.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 Multicast technology, with PIM-SM ([RFC7761]), is used widely in 84 modern services like IPTV and Net-Meeting. Some events, such as 85 changes in unicast routes, or a change in the PIM-SM DR, may cause 86 the loss of multicast packets. 88 The PIM DR has two responsibilities in the PIM-SM protocol. For any 89 active sources on a LAN, the PIM DR is responsible for registering 90 with the Rendezvous Point (RP) if the group is operating in PIM-SM. 91 Also, the PIM DR is responsible for tracking local multicast 92 listeners and forwarding data to these listeners if the group is 93 operating in PIM-SM. 95 + + 96 | | 97 +-----+----+ +-----+----+ 98 | RouterA | | RouterB | 99 +-----+----+ +-----+----+ 100 | | 101 +----+----+--------+---------+---+----+ 102 | | | 103 + + + 104 Receiver1 Receiver2 Receiver3 105 Figure 1: An example of multicast network 107 The simple network in Figure 1 presents two routers (A and B) 108 connected to a shared-media LAN segment. Two different scenarios are 109 described to illustrate potential issues. 111 (a) Both routers are on the network, and RouterB is elected as the 112 DR. If RouterB then fails, multicast packets are discarded until 113 RouterA is elected as DR and it assumes the multicast flows on the 114 LAN. As detailed in [RFC7761], a DR's election is triggered after 115 the current DR's Hello_Holdtime expires. When the DR (RouterB) is 116 deemed unavailable, as the result of DR failure detection, RouterA is 117 elected as the DR. Then RouterA joins the multicast trees, starts 118 receiving the flows and proceeds with the multicast forwarding. All 119 the procedures usually take several seconds. That is too long for 120 modern multicast services. 122 (b) Only RouterA is initially on the network, making it the DR. If 123 RouterB joins the network with a higher DR Priority. Then it will 124 then be elected as DR. RouterA will stop forwarding multicast 125 packets, and the multicast flows will not recover until RouterB 126 assumes the multicast flows on the LAN. 128 In either of the situations listed, many multicast packets are lost, 129 and the quality of multicast services noticeably affected. To 130 increase the stability of the network, this document introduces the 131 Designated DR (DR) and Backup Designated Router (BDR) options and 132 specifies how its identity is explicitly advertised. 134 1.1. Keywords 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 2. Terminology 144 Backup Designated Router (BDR): Immediately takes over all DR 145 functions ([RFC7761]) on an interface once the DR is no longer 146 present. A single BDR SHOULD be elected per interface. 148 Designated Router Other (DROther): A router which is neither a DR nor 149 a BDR. 151 0x0: 0.0.0.0 if IPv4 addresses are in use or 0:0:0:0:0:0:0:0/128 if 152 IPv6 addresses are in use. To simplify, 0x0 is used in abbreviation 153 in this draft. 155 3. Protocol Specification 157 The router follows the following procedures: 159 (a). A router first starts sending Hello messages with the values of 160 DR and BDR Address options are all set to 0x0, after its interface is 161 enabled in PIM on a shared-media LAN. The router treats itself as 162 DROther role, and starts a timer which value is set to 163 Hello_Holdtime. 165 (b). When the router receives Hello messages from other routers on 166 the same shared-media LAN, the router checks the value of DR/BDR 167 Address option. If the value is filled with a non-zero IP address, 168 the router stores the IP addresses. 170 (c). When a Hello message with a non-zero DR Address option is 171 received or after the timer expires, the router first executes the 172 algorithm defined in section 3.1. After that, the router first one 173 of the roles in the LAN: DR, BDR, or DROther. 175 If the role of the router first starts changes to BDR, the following 176 steps are: 178 o The BDR takes on all the functions of a DR as specified in 179 [RFC7761], except that it SHOULD NOT actively forward multicast 180 flows or send a register message to avoid duplication. 182 o If the DR becomes unreachable on the LAN, the BDR MUST take over 183 all the DR functions, including multicast flow forwarding or send 184 the register message. Mechanisms outside the scope of this 185 specification, such as [I-D.ietf-pim-bfd-p2mp-use-case] or BFD 186 Asynchronous mode [RFC5880] can be used for faster failure 187 detection. 189 For example, there are three routers: A, B, and C. If all three were 190 in the LAN, then their DR preference would be A, B, and C, in that 191 order. Initially, only C is on the LAN, so C is DR. Later, A joins; 192 C is still the DR, and A is the BDR. Later B joins, and if B is 193 better than A, then B becomes the BDR, and A is simply DROther. 195 3.1. Election Algorithm 197 The DR and BDR election is according to the DR election algorithm 198 defined in section 9.4 in [RFC2328], except: 200 o The DR is elected among the DR candidates directly. If there is 201 no DR candidates, i.e., no router advertise the DR Address options 202 with a non-zero IP address, the elected BDR will be the DR. And 203 then the BDR is elected again from the other routers in the LAN. 205 o The BDR election is not sticky. Whatever there is a router that 206 advertise the BDR Address option, the router which has the highest 207 priority, expect the elected DR, is elected as the BDR. That is 208 the BDR may be the router which has the highest priority in the 209 LAN. 211 o The advertisement is through PIM Hello message. 213 o Step 6 and 7 in section 9.4 in [RFC2328] are not applicable here. 215 Compare to the DR election function defined in section 4.3.2 in 216 [RFC7761] the differences include: 218 o The router, that can be elected as DR, has the highest priority 219 among the DR candidates. The elected DR may not be the one that 220 has the highest priority in the LAN. 222 o The router that supports the election algorithm defined in section 223 3.1 MUST advertise the DR Address option defined in section 4.1 in 224 PIM Hello message, and SHOULD advertise the BDR Address option 225 defined in section 4.2 in PIM Hello message. In case a DR is 226 elected and no BDR is elected, only the DR Address option is 227 advertised in the LAN. 229 3.2. Sending Hello Messages 231 When PIM is enabled on an interface or a router first starts, Hello 232 messages MUST be sent with the values of the DR Address option filled 233 with 0x0. The BDR Address option SHOULD be sent, if the option is 234 carried, the value MUST be filled with 0x0. Then the interface 235 starts a timer which value is set to Hello_Holdtime. When the timer 236 expires, the DR and BDR will be elected on the interface according to 237 the DR election algorithm (Section 3.1). 239 DR newcomer 240 \ / 241 ----- ----- ----- 242 | A | | B | | C | 243 ----- ----- ----- 244 | | | 245 | | | 246 ------------------------------------------- LAN 247 Figure 2 249 For example, there is a stable LAN that includes RouterA and RouterB. 250 RouterA is the DR that has the highest priority. RouterC is a 251 newcomer. RouterC sends a Hello message with the DR and BDR Address 252 options are all set to zero. 254 When a router first starts (RouterC) elects itself as the BDR after 255 it running the election algorithm, the router sends Hello messages 256 with the value of DR is set to the IP address of current DR (RouterA) 257 and the value of BDR is set to the IP address of the router first 258 starts itself (RouterC). 260 A current BDR (RouterB) may find that it can not be the BDR after it 261 running the election algorithm, it MUST set itself DROther and stop 262 sending the BDR Address options with its IP address. It MUST send 263 Hello messages with the value of DR is set to current DR and the 264 value of BDR is set to the newly elected BDR. 266 3.3. Receiving Hello Messages 268 When a Hello message is received, if the DR/BDR Address option 269 carried in the message is different from the previous message. The 270 election algorithm MUST be rerun. As a result, the associate actions 271 should be taken according to the role changing. 273 3.4. Working with the DRLB function 275 The DRLB function defined in [RFC8775] can work with the mechanism 276 defined in this document. The routers advertise the DR/BDR Address 277 options and the DRLB-Cap Hello Option defined in [RFC8775]. After 278 running the election algorithm defined in section 3.1, the elected DR 279 advertises the DRLB-List Hello Option to carry the GDR candidates. 281 When the current DR is unavailable, the BDR MUST send the DRLB-List 282 Hello Option to carry the GDR candidates. The BDR starts forwarding 283 the multicast flows, but there may be duplicated flows because the DR 284 may not be the same as the GDR. 286 4. PIM Hello message format 288 Two new PIM Hello Options are defined, which conform to the format 289 defined in [RFC7761]. 291 0 1 2 3 292 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | OptionType | OptionLength | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | OptionValue | 297 | ... | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 3: Hello Option Format 301 4.1. DR Address Option format 303 o OptionType : The value is 37. 305 o OptionLength: 4 bytes if using IPv4 and 16 bytes if using IPv6. 307 o OptionValue: IP address of the DR. If the IP version of the PIM 308 message is IPv4, the value MUST be the IPv4 address of the DR. If 309 the IP version of the PIM message is IPv6, the value MUST be the 310 link-local address of the DR. 312 4.2. BDR Address Option format 314 o OptionType : The value is 38. 316 o OptionLength: 4 bytes if using IPv4 and 16 bytes if using IPv6. 318 o OptionValue: IP address of the BDR. If the IP version of the PIM 319 message is IPv4, the value MUST be the IPv4 address of the BDR. 320 If the IP version of the PIM message is IPv6, the value MUST be 321 the link-local address of the BDR. 323 4.3. Error handling 325 The DR and BDR addresses MUST be the same with the addresses which 326 are used to send PIM Hello message. 328 Unknown options MUST be ignored, which conforms to the format defined 329 in section 4.9.2 in [RFC7761], and the options MUST be ignored that 330 include unexpected values. For example, when a DR Address option 331 with IPv4 address is received while the interface supports IPv6 only, 332 the option MUST be ignored. 334 5. Compatibility 336 If at least one router on a LAN doesn't send a Hello message, 337 including the DR Address Options, then the specification in this 338 document MUST NOT be used. Any router using the DR and BDR Address 339 Options MUST set the corresponding OptionValues to 0x0. This action 340 results in all routers using the DR election function defined in 341 [RFC7761] or [I-D.mankamana-pim-bdr]. 343 This draft allows the DR election to be sticky by not unnecessarily 344 changing the DR when routers go down or come up. That is done by 345 introducing new PIM Hello options. Both this draft and the draft 346 [I-D.mankamana-pim-bdr], introduce a backup DR. The latter draft 347 does this without introducing new options but does not consider the 348 sticky behavior. 350 A router that does not support this specification ignores unknown 351 options According to section 4.9.2 defined in [RFC7761]. So the new 352 extension defined in this draft will not influence the stability of 353 neighbors. 355 The DR election mechanism selection would depend on deployment 356 scenario. 358 6. Security Considerations 360 [RFC7761] describes the security concerns related to PIM-SM, the 361 potential BFD session attack can be used as the security function in 362 section 9 [RFC5880] mentioned. 364 If an attacker wants to hijack the DR role, it may send PIM Hello 365 message with the altered DR/BDR Address options. The attacker sends 366 the Hello message with the DR Address option set to itself as DR 367 except for the highest priority or IP address. Or the attacker sends 368 the Hello message without the DR/BDR Address option except for the 369 highest priority or IP address. 371 If an attacker wants to take the BDR role, it simply sends PIM Hello 372 message with BDR Address options except for the higher priority or IP 373 address than the current BDR. 375 Some security measures, such as IP address filtering for the 376 election, may be taken to avoid these situations. For example, the 377 Hello message received from an unknown neighbor is ignored by the 378 election process. 380 7. IANA Considerations 382 IANA is requested to allocate two new code points from the "PIM-Hello 383 Options" registry. 385 +------+--------------------+---------------+ 386 | Type | Description | Reference | 387 +------+--------------------+---------------+ 388 | 37 | DR Address Option | This Document | 389 | 38 | BDR Address Option | This Document | 390 +------+--------------------+---------------+ 392 Table 1 394 8. Acknowledgements 396 The authors would like to thank Alvaro Retana, Greg Mirsky, Jake 397 Holland, Stig Venaas for their valuable comments and suggestions. 399 9. References 401 9.1. Normative References 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, 405 DOI 10.17487/RFC2119, March 1997, 406 . 408 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 409 DOI 10.17487/RFC2328, April 1998, 410 . 412 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 413 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 414 . 416 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 417 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 418 Multicast - Sparse Mode (PIM-SM): Protocol Specification 419 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 420 2016, . 422 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 423 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 424 May 2017, . 426 [RFC8775] Cai, Y., Ou, H., Vallepalli, S., Mishra, M., Venaas, S., 427 and A. Green, "PIM Designated Router Load Balancing", 428 RFC 8775, DOI 10.17487/RFC8775, April 2020, 429 . 431 9.2. Informative References 433 [I-D.ietf-pim-bfd-p2mp-use-case] 434 Mirsky, G. and J. Xiaoli, "Bidirectional Forwarding 435 Detection (BFD) for Multi-point Networks and Protocol 436 Independent Multicast - Sparse Mode (PIM-SM) Use Case", 437 draft-ietf-pim-bfd-p2mp-use-case-04 (work in progress), 438 July 2020. 440 [I-D.mankamana-pim-bdr] 441 mishra, m., Goh, J., and G. Mishra, "PIM Backup Designated 442 Router Procedure", draft-mankamana-pim-bdr-04 (work in 443 progress), April 2020. 445 Authors' Addresses 447 Zheng(Sandy) Zhang 448 ZTE Corporation 449 No. 50 Software Ave, Yuhuatai Distinct 450 Nanjing 451 China 453 Email: zhang.zheng@zte.com.cn 455 Fangwei Hu 456 Individual 457 Shanghai 458 China 460 Email: hufwei@gmail.com 462 Benchong Xu 463 ZTE Corporation 464 No. 68 Zijinghua Road, Yuhuatai Distinct 465 Nanjing 466 China 468 Email: xu.benchong@zte.com.cn 469 Mankamana Mishra 470 Cisco Systems 471 821 Alder Drive, 472 MILPITAS, CALIFORNIA 95035 473 UNITED STATES 475 Email: mankamis@cisco.com