idnits 2.17.1 draft-ietf-pim-dr-improvement-12.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 (15 August 2021) is 978 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-06 Summary: 0 errors (**), 0 flaws (~~), 3 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: 16 February 2022 Individual 6 B. Xu 7 ZTE Corporation 8 M. Mishra 9 Cisco Systems 10 15 August 2021 12 Protocol Independent Multicast - Sparse Mode (PIM-SM) Designated Router 13 (DR) Improvement 14 draft-ietf-pim-dr-improvement-12 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'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 16 February 2022. 43 Copyright Notice 45 Copyright (c) 2021 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 (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Protocol Specification . . . . . . . . . . . . . . . . . . . 4 63 3.1. Election Algorithm . . . . . . . . . . . . . . . . . . . 5 64 3.2. Sending Hello Messages . . . . . . . . . . . . . . . . . 7 65 3.3. Receiving Hello Messages . . . . . . . . . . . . . . . . 8 66 3.4. Working with the DRLB function . . . . . . . . . . . . . 9 67 4. PIM Hello message format . . . . . . . . . . . . . . . . . . 9 68 4.1. DR Address Option format . . . . . . . . . . . . . . . . 9 69 4.2. BDR Address Option format . . . . . . . . . . . . . . . . 10 70 4.3. Error handling . . . . . . . . . . . . . . . . . . . . . 10 71 5. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 10 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 77 9.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 Multicast technology, with PIM-SM ([RFC7761]), is used widely in 83 Modern services. Some events, such as changes in unicast routes, or 84 a change in the PIM-SM DR, may cause the loss of multicast packets. 86 The PIM DR has two responsibilities in the PIM-SM protocol. For any 87 active sources on a LAN, the PIM DR is responsible for registering 88 with the Rendezvous Point (RP). Also, the PIM DR is responsible for 89 tracking local multicast listeners and forwarding data to these 90 listeners. 92 + + 93 | | 94 +-----+----+ +-----+----+ 95 | RouterA | | RouterB | 96 +-----+----+ +-----+----+ 97 | | 98 +----+----+--------+---------+---+----+ 99 | | | 100 + + + 101 Receiver1 Receiver2 Receiver3 102 Figure 1: An example of multicast network 104 The simple network in Figure 1 presents two routers (A and B) 105 connected to a shared-media LAN segment. Two different scenarios are 106 described to illustrate potential issues. 108 (a) Both routers are on the network, and RouterB is elected as the 109 DR. If RouterB then fails, multicast packets are discarded until 110 RouterA is elected as DR, and it assumes the multicast flows on the 111 LAN. As detailed in [RFC7761], a DR's election is triggered after 112 the current DR's Hello_Holdtime expires. The failure detection and 113 election procedures may take several seconds. That is too long for 114 modern multicast services. 116 (b) Only RouterA is initially on the network, making it the DR. If 117 RouterB joins the network with a higher DR Priority. Then it will be 118 elected as DR. RouterA will stop forwarding multicast packets, and 119 the flows will not recover until RouterB assumes them. 121 In either of the situations listed, many multicast packets may be 122 lost, and the quality of the services noticeably affected. To 123 increase the stability of the network this document introduces the 124 Designated DR (DR) and Backup Designated Router (BDR) options, and 125 specifies how the identity of these nodes is explicitly advertised. 127 1.1. Keywords 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 2. Terminology 137 Modern services: The real time multicast services, such like IPTV, 138 Net-meeting, etc. 140 Backup Designated Router (BDR): Immediately takes over all DR 141 functions ([RFC7761]) on an interface once the DR is no longer 142 present. A single BDR SHOULD be elected per interface. 144 Designated Router Other (DROther): A router which is neither a DR nor 145 a BDR. 147 0x0: 0.0.0.0 if IPv4 addresses are in use or 0:0:0:0:0:0:0:0/128 if 148 IPv6 addresses are in use. To simplify, 0x0 is used in abbreviation 149 in this draft. 151 Sticky: The DR doesn't change unnecessarily when routers, even with 152 higher priority, go down or come up. 154 3. Protocol Specification 156 The router follows the following procedures, these steps are to be 157 used when a router starts, or the interface is enabled: 159 (a). When a router first starts or its interface is enabled, it 160 includes the DR and BDR Address options with the OptionValue set to 161 0x0 in its Hello messages (Section 4). At this point the router 162 considers itself a DROther, and starts a timer set to 163 Default_Hello_Holdtime [RFC7761]. 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 address. 170 (c). After the timer expires, the router first executes the 171 algorithm defined in section 3.1. After that, the router acts as one 172 of the roles in the LAN: DR, BDR, or DROther. 174 If the router is elected the BDR, it takes on all the functions of a 175 DR as specified in [RFC7761], but it SHOULD NOT actively forward 176 multicast flows or send a register message to avoid duplication. 178 If the DR becomes unreachable on the LAN, the BDR MUST take over all 179 the DR functions, including multicast flow forwarding and sending the 180 Register messages. Mechanisms outside the scope of this 181 specification, such as [I-D.ietf-pim-bfd-p2mp-use-case] or BFD 182 Asynchronous mode [RFC5880] can be used for faster failure detection. 184 For example, there are three routers: A, B, and C. If all three were 185 in the LAN, then their DR preference would be A, B, and C, in that 186 order. Initially, only C is on the LAN, so C is DR. Later, B joins; 187 C is still the DR, and B is the BDR. Later A joins, then A becomes 188 the BDR, and B is simply DROther. 190 3.1. Election Algorithm 192 The DR and BDR election refers the DR election algorithm defined in 193 section 9.4 in [RFC2328], and updates the election function defined 194 in section 4.3.2 in [RFC7761]. 196 * The DR is elected among the DR candidates directly. If there is 197 no DR candidates, i.e., all the routers advertise the DR Address 198 options with zero OptionValue, the elected BDR will be the DR. 199 And then the BDR is elected again from the other routers in the 200 LAN. 202 * The BDR election is not sticky. Whatever there is a router that 203 advertise the BDR Address option, the router which has the highest 204 priority, expect for the elected DR, is elected as the BDR. That 205 is the BDR may be the router which has the highest priority in the 206 LAN. 208 * The advertisement is through PIM Hello message. 210 Except for the information recorded in section 4.3.2 in [RFC7761], 211 the DR/BDR OptionValue from the neighbor is also recorded: 213 * neighbor.dr: The DR Address OptionValue that presents in the Hello 214 message from the PIM neighbor. 216 * neighbor.bdr: The BDR Address OptionValue that presents in the 217 Hello message from the PIM neighbor. 219 The pseudocode is shown below: A BDR election function is added, and 220 the DR function is updated. The validneighbor function means that a 221 valid Hello message has been received from this neighbor. 223 BDR(I) { 224 bdr = NULL 225 for each neighbor on interface I { 226 if ( neighbor.bdr != NULL ) { 227 if (validneighbor (neighbor.bdr) == TRUE) { 228 if bdr == NULL 229 bdr = neighbor.bdr 230 else (dr_is_better( neighbor.bdr, bdr, I ) 231 == TRUE ) { 232 bdr = neighbor.bdr 233 } 234 } 235 } 236 } 237 return bdr 238 } 240 DR(I) { 241 dr = NULL 242 for each neighbor on interface I { 243 if ( neighbor.dr != NULL ) { 244 if (validneighbor (neighbor.dr) == TRUE) { 245 if (dr == NULL) 246 dr = neighbor.dr 247 else (dr_is_better( neighbor.dr, dr, I ) 248 == TRUE ) { 249 dr = neighbor.dr 250 } 251 } 252 } 253 } 254 if (dr == NULL) { 255 dr = bdr 256 } 257 if (dr == NULL) { 258 dr = me 259 } 260 return dr 261 } 263 Compare to the DR election function defined in section 4.3.2 in 264 [RFC7761] the differences include: 266 * The router, that can be elected as DR, has the highest priority 267 among the DR candidates. The elected DR may not be the one that 268 has the highest priority in the LAN. 270 * The router that supports the election algorithm defined in section 271 3.1 MUST advertise the DR Address option defined in section 4.1 in 272 PIM Hello message, and SHOULD advertise the BDR Address option 273 defined in section 4.2 in PIM Hello message. In case a DR is 274 elected and no BDR is elected, only the DR Address option is 275 advertised in the LAN. 277 3.2. Sending Hello Messages 279 When PIM is enabled on an interface or a router first starts, Hello 280 messages MUST be sent with the OptionValue of the DR Address option 281 set to 0x0. The BDR Address option SHOULD also be sent, the 282 OptionValue MUST be set to 0x0. Then the interface starts a timer 283 which value is set to Default_Hello_Holdtime. When the timer 284 expires, the DR and BDR will be elected on the interface according to 285 the DR election algorithm (Section 3.1). 287 After the election, if there is one existed DR in the LAN, the DR 288 remains unchanged. If there is no existed DR in the LAN, a new DR is 289 elected, the routers in the LAN MUST send the Hello message with the 290 OptionValue of DR Address option set to the elected DR. If there are 291 more than one routers with non-zero DR priority in the LAN, a BDR is 292 also elected. Then the routers in the LAN MUST send the Hello 293 message with the OptionValue of BDR Address option set to the elected 294 BDR. Any DROther router MUST NOT use its IP addresses in the DR/BDR 295 Address option. 297 DR newcomer 298 \ / 299 ----- ----- ----- 300 | A | | B | | C | 301 ----- ----- ----- 302 | | | 303 | | | 304 ------------------------------------------- LAN 305 Figure 2 307 For example, there is a stable LAN that includes RouterA and RouterB. 308 RouterA is the DR that has the highest priority. RouterC is a 309 newcomer. RouterC sends a Hello message with the OptionValue of DR/ 310 BDR Address option set to zero. RouterA and RouterB sends the Hello 311 message with the DR OptionValue set to RouterA, the BDR OptionValue 312 set to RouterB. 314 In case RouterC has a higher priority than RouterB, RouterC elects 315 itself as the BDR after it runs the election algorithm, then RouterC 316 sends Hello messages with the DR OptionValue set to the IP address of 317 current DR (RouterA), and the BDR OptionValue set to RouterC. 319 In case RouterB has a higher priority than RouterC, RouterC finds 320 that it can not be the BDR after it runs the election algorithm, it 321 sets the status to DROther. Then RouterC sends Hello messages with 322 the DR OptionValue set to RouterA and the BDR OptionValue set to 323 RouterB. 325 3.3. Receiving Hello Messages 327 When a Hello message is received, the OptionValue of DR/BDR is 328 checked. If the OptionValue of DR is not zero and it isn't the same 329 with local stored values, or the OptionValue of DR is zero but the 330 advertising router is the stored DR, the interface timer of election 331 MAY be set/reset. 333 Before the election algorithm runs, the validity check MUST be done. 334 The DR/BDR OptionValue in the Hello message MUST match with a known 335 neighbor, otherwise the DR/BDR OptionValue can not become the DR/BDR 336 candidates. 338 If there is one or more candidates which are different from the 339 stored DR/BDR value after the validity check, the election MUST be 340 taken. The new DR/BDR will be elected according to the rules defined 341 in section 3.1. 343 3.4. Working with the DRLB function 345 A network can use the enhancement described in this document with the 346 DR Load Balancing (DRLB) mechanism [RFC8775]. The DR MUST send the 347 DRLB-List Hello Option defined in [RFC8775]. If the DR becomes 348 unreachable, the BDR will take over all the multicast flows on the 349 link, which may result in duplicated traffic as it may not have been 350 a Group DR (GDR). The new DR MUST then follow the procedures in 351 [RFC8775]. 353 In case the DR, or the BDR which becomes DR after the DR failure, 354 doesn't support the mechanism defined in [RFC8775], the DRLB-List 355 Hello Option can not be advertised, then the DRLB mechanism takes no 356 effection. 358 4. PIM Hello message format 360 Two new PIM Hello Options are defined, which conform to the format 361 defined in [RFC7761]. 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | OptionType | OptionLength | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | OptionValue | 369 | ... | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Figure 3: Hello Option Format 373 4.1. DR Address Option format 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Type = 37 | Length = | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | DR Address (Encoded-Unicast format) | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Figure 4: DR Address Option 384 * OptionType : The value is 37. 386 * OptionLength: 4 bytes if using IPv4 and 16 bytes if using IPv6. 388 * DR Address: If the IP version of the PIM message is IPv4, the 389 value MUST be the IPv4 address of the DR. If the IP version of 390 the PIM message is IPv6, the value MUST be the link-local address 391 of the DR. 393 4.2. BDR Address Option format 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Type = 38 | Length = | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | BDR Address (Encoded-Unicast format) | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Figure 5: BDR Address Option 404 * OptionType : The value is 38. 406 * OptionLength: 4 bytes if using IPv4 and 16 bytes if using IPv6. 408 * BDR Address: If the IP version of the PIM message is IPv4, the 409 value MUST be the IPv4 address of the BDR. If the IP version of 410 the PIM message is IPv6, the value MUST be the link-local address 411 of the BDR. 413 4.3. Error handling 415 The DR and BDR addresses MUST correspond to an address used to send 416 PIM Hello messages by one of the PIM neighbors on the interface. If 417 that is not the case then the OptionValue of DR/BDR MUST be ignored 418 as described in section 3.3. 420 An option with unexpected values MUST be ignored. For example, a DR 421 Address option with an IPv4 address received while the interface only 422 supports IPv6 is ignored. 424 5. Backwards Compatibility 426 Any router using the DR and BDR Address Options MUST set the 427 corresponding OptionValues. If at least one router on a LAN doesn't 428 send a Hello message, including the DR Address Option, then the 429 specification in this document MUST NOT be used. For example, the 430 routers in a LAN all support the options defined in this document, 431 the DR/BDR is elected. A new router which doesn't support the 432 options joins, when the hello message without DR Address Option is 433 received, all the router MUST switch the election function back 434 immediately. This action results in all routers using the DR 435 election function defined in [RFC7761] or [I-D.mankamana-pim-bdr]. 436 Both this draft and the draft [I-D.mankamana-pim-bdr], introduce a 437 backup DR. The later draft does this without introducing new options 438 but does not consider the sticky behavior. In case there is router 439 which doesn't support the DR/BDR Address Option defined in this 440 document, the routers SHOULD take the function defined in 441 [I-D.mankamana-pim-bdr] if all the routers support it, otherwise the 442 router SHOULD used the function defined in [RFC7761]. 444 A router that does not support this specification ignores unknown 445 options according to section 4.9.2 defined in [RFC7761]. So the new 446 extension defined in this draft will not influence the stability of 447 neighbors. 449 6. Security Considerations 451 [RFC7761] describes the security concerns related to PIM-SM. A rogue 452 router can become the DR/BDR by appropriately crafting the Address 453 options to include a more desirable IP address or priority. Because 454 the election algorithm makes the DR role be non-preemptive, an 455 attacker can then take control for long periods of time. The effect 456 of these actions can result in multicast flows not being forwarded 457 (already considered in [RFC7761]). 459 Some security measures, such as IP address filtering for the 460 election, may be taken to avoid these situations. For example, the 461 Hello message received from an untrusted neighbor is ignored by the 462 election process. 464 7. IANA Considerations 466 IANA is requested to allocate two new code points from the "PIM-Hello 467 Options" registry. 469 +======+====================+===============+ 470 | Type | Description | Reference | 471 +======+====================+===============+ 472 | 37 | DR Address Option | This Document | 473 +------+--------------------+---------------+ 474 | 38 | BDR Address Option | This Document | 475 +------+--------------------+---------------+ 477 Table 1 479 8. Acknowledgements 481 The authors would like to thank Alvaro Retana, Greg Mirsky, Jake 482 Holland, Stig Venaas for their valuable comments and suggestions. 484 9. References 486 9.1. Normative References 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, 490 DOI 10.17487/RFC2119, March 1997, 491 . 493 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 494 DOI 10.17487/RFC2328, April 1998, 495 . 497 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 498 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 499 Multicast - Sparse Mode (PIM-SM): Protocol Specification 500 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 501 2016, . 503 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 504 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 505 May 2017, . 507 [RFC8775] Cai, Y., Ou, H., Vallepalli, S., Mishra, M., Venaas, S., 508 and A. Green, "PIM Designated Router Load Balancing", 509 RFC 8775, DOI 10.17487/RFC8775, April 2020, 510 . 512 9.2. Informative References 514 [I-D.ietf-pim-bfd-p2mp-use-case] 515 Mirsky, G. and J. Xiaoli, "The Use of Bidirectional 516 Forwarding Detection (BFD) for Multipoint Networks in 517 Protocol Independent Multicast - Sparse Mode (PIM-SM)", 518 Work in Progress, Internet-Draft, draft-ietf-pim-bfd-p2mp- 519 use-case-06, 4 August 2021, 520 . 523 [I-D.mankamana-pim-bdr] 524 Mishra, M., Santhanam, S., Paramasivam, A., Goh, J., and 525 G. S. Mishra, "PIM Backup Designated Router Procedure", 526 Work in Progress, Internet-Draft, draft-mankamana-pim-bdr- 527 05, 8 April 2021, . 530 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 531 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 532 . 534 Authors' Addresses 536 Zheng(Sandy) Zhang 537 ZTE Corporation 538 No. 50 Software Ave, Yuhuatai Distinct 539 Nanjing 540 China 542 Email: zhang.zheng@zte.com.cn 544 Fangwei Hu 545 Individual 546 Shanghai 547 China 549 Email: hufwei@gmail.com 551 Benchong Xu 552 ZTE Corporation 553 No. 68 Zijinghua Road, Yuhuatai Distinct 554 Nanjing, 555 China 557 Email: xu.benchong@zte.com.cn 559 Mankamana Mishra 560 Cisco Systems 561 821 Alder Drive, 562 MILPITAS, CALIFORNIA 95035 563 United States 565 Email: mankamis@cisco.com