idnits 2.17.1 draft-ietf-pim-dr-improvement-08.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 (August 15, 2019) is 1715 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) == Unused Reference: 'RFC2362' is defined on line 525, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2362 (Obsoleted by RFC 4601, RFC 5059) == Outdated reference: A later version (-10) exists of draft-ietf-pim-bfd-p2mp-use-case-02 == Outdated reference: A later version (-05) exists of draft-mankamana-pim-bdr-02 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM WG Zheng. Zhang 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track Fangwei. Hu 5 Expires: February 16, 2020 Individual 6 Benchong. Xu 7 ZTE Corporation 8 Mankamana. Mishra 9 Cisco Systems 10 August 15, 2019 12 PIM DR Improvement 13 draft-ietf-pim-dr-improvement-08.txt 15 Abstract 17 Protocol Independent Multicast - Sparse Mode (PIM-SM) is widely 18 deployed multicast protocol. As deployment for PIM protocol is 19 growing day by day, user expects lower traffic loss and faster 20 convergence in case of any network failure. This document provides 21 an extension to the existing protocol which would improve the 22 stability of the PIM protocol with respect to traffic loss and 23 convergence time when the PIM DR role changes. 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 16, 2020. 42 Copyright Notice 44 Copyright (c) 2019 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 1.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. PIM hello message format . . . . . . . . . . . . . . . . . . 4 63 3.1. DR Address Option format . . . . . . . . . . . . . . . . 4 64 3.2. BDR Address Option format . . . . . . . . . . . . . . . . 4 65 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 5 66 4.1. Deployment Choice . . . . . . . . . . . . . . . . . . . . 6 67 4.2. Election Algorithm . . . . . . . . . . . . . . . . . . . 6 68 4.3. Sending Hello Messages . . . . . . . . . . . . . . . . . 7 69 4.4. Receiving Hello Messages . . . . . . . . . . . . . . . . 8 70 4.5. The treatment . . . . . . . . . . . . . . . . . . . . . . 9 71 4.6. Sender side . . . . . . . . . . . . . . . . . . . . . . . 10 72 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 10 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 78 9.2. Informative References . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 Multicast technology is used widely. Many modern technologies, such 84 as IPTV, Net-Meeting, use PIM-SM to facilitate multicast service. 85 There are many events that will influence the quality of multicast 86 services. Like the change of unicast routes, the change of the PIM- 87 SM DR may cause the loss of multicast packets too. 89 After a DR on a shared-media LAN goes down, other routers will elect 90 a new DR after the expiration of Hello-Holdtime. The default value 91 of Hello-Holdtime is 105 seconds. Although the minimum Hello 92 interval can be adjusted to 1 second, the Hello-Holdtime is 3.5 times 93 Hello interval. Thus, the detection of DR Down event cannot be 94 guaranteed in less than 3.5 seconds. And it is too long for modern 95 multicast services. Still, many multicast packets will be lost. The 96 quality of IPTV and Net-Meeting will be influenced. 98 \ / 99 \ / 100 ------- ------- 101 | A | | B | 102 ------- ------- 103 | DR | 104 | | 105 ------- ------- 106 | SW |-----------------------------| SW | 107 ------- ------- 108 | | 109 Figure 1: An example of multicast network 111 For example, there are two routers on one LAN. Two SWs (Layer 2 112 switches) provide shared-media LAN connection. RouterA is elected as 113 DR. When RouterA goes down, the multicast packets are discarded 114 until the RouterB is elected to DR and RouterB imports the multicast 115 flows successfully. 117 We suppose that there is only a RouterA in the LAN at first in 118 Figure 1. RouterA is the DR which is responsible for forwarding 119 multicast flows. When RouterB connects to the LAN, RouterB will be 120 elected as DR because of its higher priority. RouterA will stop 121 forwarding multicast packets. The multicast flows will not recover 122 until RouterB pulls the multicast flows after it is elected to DR. 124 So if we want to increase the stability of DR, carrying DR/ BDR role 125 information in PIM hello packet is a feasible way to show the DR/ BDR 126 roles explicitly. It avoids the confusion caused by newcomers which 127 have a higher priority. 129 1.1. Keywords 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in BCP 134 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 2. Terminology 139 Backup Designated Router (BDR): Like DR (Designated Router), a BDR 140 which acts on behalf of directly connected hosts in a shared-media 141 LAN. But BDR must not forward the flows when DR works normally. 142 When DR goes down, the BDR will forward multicast flows immediately. 143 A single BDR MUST be elected per interface like the DR. 145 Designated Router Other (DROther): A router which is neither DR nor 146 BDR. 148 3. PIM hello message format 150 The PIM hello message format is defined in [RFC7761]. In this 151 document, we define two new option values which are including Type, 152 Length, and Value. 154 0 1 2 3 155 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 156 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 157 | Hello message format | 158 | | 159 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 160 | OptionType + OptionLength | 161 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 162 | OptionValue | 163 | | 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 165 Figure 2: Hello message format 167 3.1. DR Address Option format 169 o OptionType : The value is TBD1. 171 o OptionLength: If the IP version of PIM message is IPv4, the 172 OptionLength is 4 octets. If the IP version of PIM message is 173 IPv6, the OptionLength is 16 octets. 175 o OptionValue: The OptionValue is IP address of DR. If the IP 176 version of PIM message is IPv4, the value is the IPv4 address of 177 DR. If the IP version of PIM message is IPv6, the value is the 178 IPv6 address of DR. 180 3.2. BDR Address Option format 182 o OptionType : The value is TBD2. 184 o OptionLength: If the IP version of PIM message is IPv4, the 185 OptionLength is 4 octets. If the IP version of PIM message is 186 IPv6, the OptionLength is 16 octets. 188 o OptionValue: The OptionValue is IP address of BDR. If the IP 189 version of PIM message is IPv4, the value is the IPv4 address of 190 BDR. If the IP version of PIM message is IPv6, the value is the 191 IPv6 address of BDR. 193 4. Protocol Specification 195 Carrying DR/ BDR role information in PIM hello packet is a feasible 196 way to keep the stability of DR. It avoids the confusion caused by 197 newcomers which have a higher priority. So there are some changes in 198 PIM hello procedure and interface state machine. 200 A new router starts to send hello messages with the values of DR and 201 BDR are all set to 0 after its interface is enabled in PIM on a 202 shared-media LAN. When the router receives hello messages from other 203 routers on the same shared-media LAN, the router will check if the 204 value of DR is filled. If the value of DR is filled with IP address 205 of the router which is sending hello messages, the router will store 206 the IP address as the DR address of this interface. 208 Then the new router compares the priority and IP address itself to 209 the stored information of DR and BDR according to the algorithm of 210 [RFC7761]. If the new router notices that it is better to be DR than 211 the current DR or BDR, the new router will make itself the BDR, and 212 send new hello messages with its IP address as BDR and current DR. 213 If the router notices that the current DR has the highest priority in 214 the shared-media LAN, but the current BDR is set to 0.0.0.0 if IPv4 215 addresses are in use or 0:0:0:0:0:0:0:0/128 if IPv6 addresses are in 216 use in the received hello messages (To simplify, we use 0x0 in 217 abbreviation in following parts of the draft), or the current BDR is 218 not better than the new router, the new router will elect itself to 219 BDR. If the router notices that it is not better to be DR than 220 current DR and BDR, the router will follow the current DR and BDR. 222 When the new router becomes the new BDR, the router will join the 223 current multicast groups, and import multicast flows from upstream 224 routers. But the BDR must not forward the multicast flows to avoid 225 the duplicate multicast packets in the shared-media LAN. The new 226 router will monitor the DR. The method that BDR monitors the DR may 227 be Bidirectional Forwarding Detection (BFD) for Multi-point Networks 228 and Protocol Independent Multicast [I-D.ietf-pim-bfd-p2mp-use-case] 229 technology, BFD (Bidirectional Forwarding Detection) [RFC5880] 230 technology, or other ways that can be used to detect link/node 231 failure quickly. When the DR becomes unavailable because of the down 232 or other reasons, the BDR will forward multicast flows immediately. 234 BFD for PIM function defined in [I-D.ietf-pim-bfd-p2mp-use-case], or 235 asynchronous mode defined in BFD [RFC5880] are suggested to be used 236 for the DR failure detection. BDR monitors DR after the BFD session 237 between DR and BDR is established. For example, an aggressive BFD 238 session that achieves a detection time of 300 milliseconds, by using 239 a transmit interval of 100 milliseconds and a detect multiplier of 3. 240 So BDR can replace DR to forward flows when DR goes down within sub 241 second. The other BFD modes can also be used to monitor the failure 242 of DR, the network administrator should choose the most suitable 243 function. 245 4.1. Deployment Choice 247 DR / BDR election SHOULD be handled in two ways. Selection of which 248 procedure to use would be totally dependent on deployment scenario. 250 1. The algorithm defined in [RFC7761] should be used if it is ok to 251 adopt with new DR as and when they are available, and the loss caused 252 by DR changing is acceptable. 254 2. If the deployment requirement is to have minimum packets loss 255 when DR changing, the mechanism defined in this draft should be used. 256 That is, if the new router notices that it is better to be DR than 257 the current DR or BDR, the new router will make itself the BDR, and 258 send new hello message with its IP address as BDR and current DR. 260 According to section 4.9.2 defined in [RFC7761], the device receives 261 unknown options Hello packet will ignore it. So the new extension 262 defined in this draft will not influence the stability of neighbor. 263 But if the router which has the ability defined in this draft 264 receives non-DR/BDR capable Hello messages defined in [RFC7761], the 265 router MAY stop sending DR/BDR capable Hello messages in the LAN and 266 go back to use the advertisement and election algorithm defined in 267 [RFC7761]. 269 4.2. Election Algorithm 271 The DR and BDR election is according to the rules defined below, the 272 algorithm is similar to the DR election defined in [RFC2328]. 274 (1) Note the current values for the network's Designated Router and 275 Backup Designated Router. This is used later for comparison 276 purposes. 278 (2) Calculate the new Backup Designated Router for the network as 279 follows. The router that has not declared itself to be Designated 280 Router is eligible to become Backup Designated Router. The one which 281 has the highest priority will be chosen to be Backup Designated 282 Router. In case of a tie, the one having the highest primary address 283 is chosen. 285 (3) Calculate the new Designated Router for the network as follows. 286 If one or more of the routers have declared themselves Designated 287 Router (i.e., they are currently listing themselves as Designated 288 Router in their Hello Packets) the one having highest Router Priority 289 is declared to be Designated Router. In case of a tie, the one 290 having the highest primary address is chosen. If no routers have 291 declared themselves Designated Router, assign the Designated Router 292 to be the same as the newly elected Backup Designated Router. 294 (4) If Router X is now newly the Designated Router or newly the 295 Backup Designated Router, or is now no longer the Designated Router 296 or no longer the Backup Designated Router, repeat steps 2 and 3, and 297 then proceed to step 5. For example, if Router X is now the 298 Designated Router, when step 2 is repeated X will no longer be 299 eligible for Backup Designated Router election. Among other things, 300 this will ensure that no router will declare itself both Backup 301 Designated Router and Designated Router. 303 (5) As a result of these calculations, the router itself may now be 304 Designated Router or Backup Designated Router. 306 The reason behind the election algorithm's complexity is the desire 307 for the DR stability. 309 The above procedure may elect the same router to be both Designated 310 Router and Backup Designated Router, although that router will never 311 be the calculating router (Router X) itself. The elected Designated 312 Router may not be the router having the highest Router Priority. If 313 Router X is not itself eligible to become Designated Router, it is 314 possible that neither a Backup Designated Router nor a Designated 315 Router will be selected in the above procedure. Note also that if 316 Router X is the only attached router that is eligible to become 317 Designated Router, it will select itself as Designated Router and 318 there will be no Backup Designated Router for the network. 320 4.3. Sending Hello Messages 322 According to Section 4.3.1 in [RFC7761], when a new router's 323 interface is enabled in PIM protocol, the router sends Hello messages 324 with the values of DR and BDR are filled with 0x0. Then the 325 interface is in Waiting state and starts the hold-timer which is 326 equal to the Neighbor Liveness Timer. When the timer is expired, the 327 interface will elect the DR and BDR according to the DR election 328 rules. 330 When a new router sets itself BDR after receives hello messages from 331 other routers, the router sends hello messages with the value of DR 332 is set to the IP address of current DR and the value of BDR is set to 333 the IP address of the router itself. 335 A current BDR MUST set itself DROther after it receives Hello 336 messages from other router which is eligible to be BDR/DR, the router 337 will send hello messages with the value of DR is set to current DR 338 and the value of BDR is set to the new BDR. 340 DR newcomer 341 \ / 342 ----- ----- ----- 343 | A | | B | | C | 344 ----- ----- ----- 345 | | | 346 | | | 347 ------------------------------------------- LAN 348 Figure 3 350 For example, there is a stable LAN that includes RouterA and RouterB. 351 RouterA is the DR which has the highest priority. RouterC is a 352 newcomer. RouterC sends hello packet with the DR and BDR are all set 353 to zero. 355 If RouterC cannot send hello packet with the DR/BDR capability, 356 Router C MAY send the hello packet according to the rule defined in 357 [RFC7761]. 359 If deployment requirement is to adopt with a new DR when it is 360 available, a new router with the highest priority or the highest IP 361 address sends hello packet with DR and BDR are all set to zero at 362 first. It sends hello packet with itself set to DR after it finish 363 join all the existing multicast groups. Then current DR compares 364 with the new router, the new router will be the final DR. 366 4.4. Receiving Hello Messages 368 When the values of DR and BDR which are carried by hello messages 369 received are all set to 0x0, the router MUST elect the DR using 370 procedure defined in DR election algorithm after the hold-timer 371 expires. And elect a new BDR which is the best choice except DR. 372 The election cases can be executed as follows: 374 In case the value of DR which is carried by received hello messages 375 is not 0x0, and the value of BDR is set to 0x0, when the hold-timer 376 expires there is no hello packet from other router is received, the 377 router will elect itself to BDR. 379 In case either of the values of DR and BDR that are carried by 380 received hello messages is greater than 0x0. The router will mark 381 the current DR, and compare itself with the BDR in the message. When 382 the router notices that it is better to be DR than the current BDR. 383 The router will elect itself to the BDR. 385 When a router receives a new hello message with the values of DR and 386 BDR are set to 0x0. The router will compare the new router with 387 current information. If the router noticed that the new router is 388 better to be DR than itself, or the new router is better to be BDR 389 than the current BDR, the router will set the BDR to the new router. 391 When current DR receives hello packet with the value of DR is set 392 larger than zero, the algorithm defined in section 4.2 can be used to 393 select the final DR. 395 As illustrated in Figure 3, after RouterC sends hello packet, RouterC 396 will not elect the DR until hold-timer expired. During the period, 397 RouterC should receive the hello packets from RouterA and RouterB. 398 RouterC accepts the result that RouterA is the DR. In case RouterC 399 has the lowest priority than RouterA and RouterB, RouterC will also 400 accept that Router B is the BDR. In case RouterC has the 401 intermediate priority among the three routers, RouterC will treat 402 itself as new BDR after the hold-timer expired. In case RouterC has 403 the highest priority among the three routers, RouterC will treat 404 RouterA which is the current DR as DR, and RouterC will treat itself 405 as the new BDR. If the network administrator thinks that RouterC 406 should be the new DR, the DR changing should be triggered manually. 407 That is RouterC will be elected as DR after it sends hello message 408 with DR is set to RouterC itself. 410 Exception: In case RouterC receives only the hello packet from 411 RouterA during the hold-timer period, when the hold-timer expired, 412 RouterC treats RouterA as DR, and RouterC treats itself as BDR. In 413 case RouterC only receives the hello packet from RouterB during the 414 hold-timer period, RouterC will compare the priority between RouterB 415 and itself to elect the new DR. In these situations, some interfaces 416 or links go wrong in the LAN. 418 4.5. The treatment 420 If all the routers on a shared-media LAN have started working at the 421 same time, then the election result of DR is same as the definition 422 in [RFC7761]. And all the routers will elect a BDR which is next 423 best to DR. The routers in the network MUST store the DR and BDR. 424 The hello messages sent by all the routers are the same with the 425 value of DR and BDR are all set. When a new router is activated on 426 the shared-media LAN and receives hello messages from other routers 427 with the value of DR is already set. The new router will not change 428 the current DR even if it is superior to the current DR. If the new 429 router is superior to current BDR, the new router will replace the 430 current BDR. 432 When the routers receive a hello message from a new router, the 433 routers compare the new router and all the other routers on the LAN. 434 If the new router is superior to the current BDR, the new router will 435 be the new BDR. Then the "old" BDR will send the Prune message to 436 upstream routers. 438 As a result, the BDR is the one which has the highest priority except 439 for DR. Once the DR is elected, the DR will not change until it 440 fails or be manually adjusted. Once the DR and BDR are elected, the 441 routers in the network MUST store the address of DR and BDR. 443 4.6. Sender side 445 DR/BDR function is also used in source side that multiple routers and 446 source is in a same shared-media LAN. The algorithm is the same as 447 the receiver side. Only the BDR need not build multicast tree from a 448 downstream router. 450 5. Compatibility 452 If the LAN is a hybrid network that there are some routers which 453 support DR/BDR capability and the other routers which do not support 454 DR/BDR capability. All the routers MUST go backward to use the 455 election algorithm defined in [RFC7761]. And the values of DR and 456 BDR carried in hello message MUST be set to zero. That is once a 457 router sends hello messages with no DR/BDR options, the DR election 458 MUST go backward to the definition in [RFC7761]. 460 If the routers find that all the routers in the LAN support DR/BDR 461 capability by the hello messages with DR/BDR options set, they MUST 462 elect DR and BDR according the algorithm defined in this document. 463 And the routers MUST send hello messages with correct DR/BDR options 464 set. 466 In case there is only one router which does not support DR/BDR 467 capability in a shared-media LAN, the other routers in the LAN send 468 hello messages with the values of DR and BDR are set to zero, the 469 router which does not support DR/BDR capability ignores the options. 470 All the routers elect DR according to the algorithm defined in 471 [RFC7761]. When the router which does not support DR/BDR capability 472 goes away, the routers in the LAN MUST elect DR/BDR according to the 473 algorithm defined in this document, and send hello messages with 474 correct DR/BDR options set. 476 This draft allows DR election to be sticky by not unnecessarily 477 changing the DR when routers go down or come up. This is done by 478 introducing new PIM Hello options. Both this draft, and the draft 479 [I-D.mankamana-pim-bdr], introduce a backup DR. The latter draft 480 does this without introducing new options, but does not consider the 481 sticky behavior. 483 6. Security Considerations 485 If an attacker which has the highest priority participates in the DR 486 election when a shared-media LAN starts to work, it will be elected 487 as DR, but it may not forward flows to receivers. And the attacker 488 remains DR position even if a legal router which has a higher 489 priority joins the LAN. 491 If an attacker is a newcomer which has a higher priority than the 492 existed BDR, it will be elected as the new BDR, but it may not 493 monitor DR, import multicast flows and forward flows to receiver when 494 DR is down. 496 In order to avoid these situations, source authentication should be 497 used to identify the validity of the DR/BDR candidates. 498 Authentication methods mentioned in section 6 RFC7761 can be used. 500 And the network administrator should consider the potential BFD 501 session attack if BFD is used between BDR and DR for DR failure 502 detection. The security function mentioned in section 9 RFC5880 can 503 be used. 505 7. IANA Considerations 507 IANA is requested to allocate two OptionTypes in TLVs of hello 508 message: DR Address Option and BDR Address Option. The strings TBD1 509 and TBD2 will be replaced by the assigned values. 511 8. Acknowledgements 513 The authors would like to thank Greg Mirsky, Jake Holland, Stig 514 Venaas for their valuable comments and suggestions. 516 9. References 518 9.1. Normative References 520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 521 Requirement Levels", BCP 14, RFC 2119, 522 DOI 10.17487/RFC2119, March 1997, 523 . 525 [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, 526 S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. 527 Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): 528 Protocol Specification", RFC 2362, DOI 10.17487/RFC2362, 529 June 1998, . 531 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 532 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 533 Multicast - Sparse Mode (PIM-SM): Protocol Specification 534 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 535 2016, . 537 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 538 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 539 May 2017, . 541 9.2. Informative References 543 [I-D.ietf-pim-bfd-p2mp-use-case] 544 Mirsky, G. and J. Xiaoli, "Bidirectional Forwarding 545 Detection (BFD) for Multi-point Networks and Protocol 546 Independent Multicast - Sparse Mode (PIM-SM) Use Case", 547 draft-ietf-pim-bfd-p2mp-use-case-02 (work in progress), 548 July 2019. 550 [I-D.mankamana-pim-bdr] 551 mishra, m., "PIM Backup Designated Router Procedure", 552 draft-mankamana-pim-bdr-02 (work in progress), April 2019. 554 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 555 DOI 10.17487/RFC2328, April 1998, 556 . 558 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 559 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 560 . 562 Authors' Addresses 564 Zheng(Sandy) Zhang 565 ZTE Corporation 566 No. 50 Software Ave, Yuhuatai Distinct 567 Nanjing 568 China 570 Email: zhang.zheng@zte.com.cn 571 Fangwei Hu 572 Individual 573 Shanghai 574 China 576 Email: hufwei@gmail.com 578 Benchong Xu 579 ZTE Corporation 580 No. 68 Zijinghua Road, Yuhuatai Distinct 581 Nanjing 582 China 584 Email: xu.benchong@zte.com.cn 586 Mankamana Mishra 587 Cisco Systems 588 821 Alder Drive, 589 MILPITAS, CALIFORNIA 95035 590 UNITED STATES 592 Email: mankamis@cisco.com