idnits 2.17.1 draft-ietf-pim-dr-improvement-07.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7761]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 (January 17, 2019) is 1926 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 520, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2362 (Obsoleted by RFC 4601, RFC 5059) Summary: 2 errors (**), 0 flaws (~~), 3 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 Fangwei. Hu 4 Intended status: Standards Track Benchong. Xu 5 Expires: July 21, 2019 ZTE Corporation 6 Mankamana. Mishra 7 Cisco Systems 8 January 17, 2019 10 PIM DR Improvement 11 draft-ietf-pim-dr-improvement-07.txt 13 Abstract 15 Protocol Independent Multicast - Sparse Mode (PIM-SM) is widely 16 deployed multicast protocol. PIM protocol is defined in [RFC7761]. 17 As deployment for PIM protocol is growing day by day, user expects 18 lower traffic loss and faster convergence in case of any network 19 failure. This document provides an extension to the existing 20 protocol which would improve the stability of the PIM protocol with 21 respect to traffic loss and convergence time when the PIM DR is down. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 21, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. PIM hello message format . . . . . . . . . . . . . . . . . . 4 61 3.1. DR Address Option format . . . . . . . . . . . . . . . . 4 62 3.2. BDR Address Option format . . . . . . . . . . . . . . . . 4 63 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 5 64 4.1. Deployment Choice . . . . . . . . . . . . . . . . . . . . 6 65 4.2. Election Algorithm . . . . . . . . . . . . . . . . . . . 6 66 4.3. Sending Hello Messages . . . . . . . . . . . . . . . . . 7 67 4.4. Receiving Hello Messages . . . . . . . . . . . . . . . . 8 68 4.5. The treatment . . . . . . . . . . . . . . . . . . . . . . 9 69 4.6. Sender side . . . . . . . . . . . . . . . . . . . . . . . 10 70 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 10 71 6. Deployment suggestion . . . . . . . . . . . . . . . . . . . . 10 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 10.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 Multicast technology is used widely. Many modern technologies, such 83 as IPTV, Net-Meeting, use PIM-SM to facilitate multicast service. 84 There are many events that will influence the quality of multicast 85 services. Like the change of unicast routes, the change of the PIM- 86 SM DR may cause the loss of multicast packets too. 88 After a DR on a shared-media LAN goes down, other routers will elect 89 a new DR after the expiration of Hello-Holdtime. The default value 90 of Hello-Holdtime is 105 seconds. Although the minimum Hello 91 interval can be adjusted to 1 second, the Hello-Holdtime is 3.5 times 92 Hello interval. Thus, the detection of DR Down event cannot be 93 guaranteed in less than 3.5 seconds. And it is too long for modern 94 multicast services. Still, many multicast packets will be lost. The 95 quality of IPTV and Net-Meeting will be influenced. 97 \ / 98 \ / 99 ------- ------- 100 | A | | B | 101 ------- ------- 102 | DR | 103 | | 104 ------- ------- 105 | SW |-----------------------------| SW | 106 ------- ------- 107 | | 108 Figure 1: An example of multicast network 110 For example, there are two routers on one LAN. Two SWs (Layer 2 111 switchers) provide shared-media LAN connection. RouterA is elected 112 as DR. When RouterA goes down, the multicast packets are discarded 113 until the RouterB is elected to DR and RouterB imports the multicast 114 flows successfully. 116 We suppose that there is only a RouterA in the LAN at first in 117 Figure 1. RouterA is the DR which is responsible for forwarding 118 multicast flows. When RouterB connects to the LAN, RouterB will be 119 elected as DR because of its higher priority. RouterA will stop 120 forwarding multicast packets. The multicast flows will not recover 121 until RouterB pulls the multicast flows after it is elected to DR. 123 So if we want to increase the stability of DR, carrying DR/ BDR role 124 information in PIM hello packet is a feasible way to show the DR/ BDR 125 roles explicitly. It avoids the confusion caused by newcomers which 126 have a higher priority. 128 1.1. Keywords 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 2. Terminology 138 Backup Designated Router (BDR): Like DR (Designated Router), a BDR 139 which acts on behalf of directly connected hosts in a shared-media 140 LAN. But BDR must not forward the flows when DR works normally. 141 When DR goes down, the BDR will forward multicast flows immediately. 142 A single BDR MUST be elected per interface like the DR. 144 Designed Router Other (DROther): A router which is neither DR nor 145 BDR. 147 3. PIM hello message format 149 The PIM hello message format is defined in [RFC7761]. In this 150 document, we define two new option values which are including Type, 151 Length, and Value. 153 0 1 2 3 154 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 155 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 156 | Hello message format | 157 | | 158 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 159 | OptionType + OptionLength | 160 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 161 | OptionValue | 162 | | 163 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 164 Figure 2: Hello message format 166 3.1. DR Address Option format 168 o OptionType : The value is TBD1. 170 o OptionLength: If the IP version of PIM message is IPv4, the 171 OptionLength is 4 octets. If the IP version of PIM message is 172 IPv6, the OptionLength is 16 octets. 174 o OptionValue: The OptionValue is IP address of DR. If the IP 175 version of PIM message is IPv4, the value is the IPv4 address of 176 DR. If the IP version of PIM message is IPv6, the value is the 177 IPv6 address of DR. 179 3.2. BDR Address Option format 181 o OptionType : The value is TBD2. 183 o OptionLength: If the IP version of PIM message is IPv4, the 184 OptionLength is 4 octets. If the IP version of PIM message is 185 IPv6, the OptionLength is 16 octets. 187 o OptionValue: The OptionValue is IP address of BDR. If the IP 188 version of PIM message is IPv4, the value is the IPv4 address of 189 BDR. If the IP version of PIM message is IPv6, the value is the 190 IPv6 address of BDR. 192 4. Protocol Specification 194 Carrying DR/ BDR role information in PIM hello packet is a feasible 195 way to keep the stability of DR. It avoids the confusion caused by 196 newcomers which have a higher priority. So there are some changes in 197 PIM hello procedure and interface state machine. 199 A new router starts to send hello messages with the values of DR and 200 BDR are all set to 0 after its interface is enabled in PIM on a 201 shared-media LAN. When the router receives hello messages from other 202 routers on the same shared-media LAN, the router will check if the 203 value of DR is filled. If the value of DR is filled with IP address 204 of the router which is sending hello messages, the router will store 205 the IP address as the DR address of this interface. 207 Then the new router compares the priority and IP address itself to 208 the stored information of DR and BDR according to the algorithm of 209 [RFC7761]. If the new router notices that it is better to be DR than 210 the current DR or BDR, the new router will make itself the BDR, and 211 send new hello messages with its IP address as BDR and current DR. 212 If the router notices that the current DR has the highest priority in 213 the shared-media LAN, but the current BDR is set to 0x00000000 if 214 IPv4 addresses are in use or 0:0:0:0:0:0:0:0/128 if IPv6 addresses 215 are in use in the received hello messages (To simplify, we use 0x0 in 216 abbreviation in following parts of the draft), or the current BDR is 217 not better than the new router, the new router will elect itself to 218 BDR. If the router notices that it is not better to be DR than 219 current DR and BDR, the router will follow the current DR and BDR. 221 When the new router becomes the new BDR, the router will join the 222 current multicast groups, and import multicast flows from upstream 223 routers. But the BDR must not forward the multicast flows to avoid 224 the duplicate multicast packets in the shared-media LAN. The new 225 router will monitor the DR. The method that BDR monitors the DR may 226 be BFD (Bidirectional Forwarding Detection) [RFC5880] technology or 227 other ways that can be used to detect link/node failure quickly. 228 When the DR becomes unavailable because of the down or other reasons, 229 the BDR will forward multicast flows immediately. 231 Asynchronous mode defined in BFD [RFC5880] is suggested to be used 232 for the DR failure detection. BDR monitors DR after the BFD session 233 between DR and BDR is established. For example, an aggressive BFD 234 session that achieves a detection time of 50 milliseconds, by using a 235 transmit interval of 16.7 milliseconds and a detect multiplier of 3. 236 So BDR can replace DR to forward flows when DR goes down within 100 237 milliseconds. The other BFD modes can also be used to monitor the 238 failure of DR, the network administrator should choose the most 239 suitable function. 241 4.1. Deployment Choice 243 DR / BDR election SHOULD be handled in two ways. Selection of which 244 procedure to use would be totally dependent on deployment scenario. 246 1. The algorithm defined in [RFC7761] should be used if it is ok to 247 adopt with new DR as and when they are available, and the loss caused 248 by DR changing is acceptable. 250 2. If the deployment requirement is to have minium packets loss when 251 DR changing, the mechanism defined in this draft should be used. 252 That is, if the new router notices that it is better to be DR than 253 the current DR or BDR, the new router will make itself the BDR, and 254 send new hello message with its IP address as BDR and current DR. 256 According to section 4.9.2 defined in [RFC7761], the device receives 257 unknown options Hello packet will ignore it. So the new extension 258 defined in this draft will not influence the stability of neighbor. 259 But if the router which has the ability defined in this draft 260 receives non-DR/BDR capable Hello messages defined in [RFC7761], the 261 router MAY stop sending DR/BDR capable Hello messages in the LAN and 262 go back to use the advertisement and election algorithm defined in 263 [RFC7761]. 265 4.2. Election Algorithm 267 The DR and BDR election is according to the rules defined below, the 268 algorithm is similar to the DR election defined in [RFC2328]. 270 (1) Note the current values for the network's Designated Router and 271 Backup Designated Router. This is used later for comparison 272 purposes. 274 (2) Calculate the new Backup Designated Router for the network as 275 follows. The router that has not declared itself to be Designated 276 Router is eligible to become Backup Designated Router. The one which 277 has the highest priority will be chosen to be Backup Designed Router. 278 In case of a tie, the one having the highest primary address is 279 chosen. 281 (3) Calculate the new Designated Router for the network as follows. 282 If one or more of the routers have declared themselves Designated 283 Router (i.e., they are currently listing themselves as Designated 284 Router in their Hello Packets) the one having highest Router Priority 285 is declared to be Designated Router. In case of a tie, the one 286 having the highest primary address is chosen. If no routers have 287 declared themselves Designated Router, assign the Designated Router 288 to be the same as the newly elected Backup Designated Router. 290 (4) If Router X is now newly the Designated Router or newly the 291 Backup Designated Router, or is now no longer the Designated Router 292 or no longer the Backup Designated Router, repeat steps 2 and 3, and 293 then proceed to step 5. For example, if Router X is now the 294 Designated Router, when step 2 is repeated X will no longer be 295 eligible for Backup Designated Router election. Among other things, 296 this will ensure that no router will declare itself both Backup 297 Designated Router and Designated Router. 299 (5) As a result of these calculations, the router itself may now be 300 Designated Router or Backup Designated Router. 302 The reason behind the election algorithm's complexity is the desire 303 for the DR stability. 305 The above procedure may elect the same router to be both Designated 306 Router and Backup Designated Router, although that router will never 307 be the calculating router (Router X) itself. The elected Designated 308 Router may not be the router having the highest Router Priority. If 309 Router X is not itself eligible to become Designated Router, it is 310 possible that neither a Backup Designated Router nor a Designated 311 Router will be selected in the above procedure. Note also that if 312 Router X is the only attached router that is eligible to become 313 Designated Router, it will select itself as Designated Router and 314 there will be no Backup Designated Router for the network. 316 4.3. Sending Hello Messages 318 According to Section 4.3.1 in [RFC7761], when a new router's 319 interface is enabled in PIM protocol, the router sends Hello messages 320 with the values of DR and BDR are filled with 0x0. Then the 321 interface is in Waiting state and starts the hold-timer which is 322 equal to the Neighbor Liveness Timer. When the timer is expired, the 323 interface will elect the DR and BDR according to the DR election 324 rules. 326 When a new router sets itself BDR after receives hello messages from 327 other routers, the router sends hello messages with the value of DR 328 is set to the IP address of current DR and the value of BDR is set to 329 the IP address of the router itself. 331 A current BDR MUST set itself DROther after it receives Hello 332 messages from other router which is eligible to be BDR/DR, the router 333 will send hello messages with the value of DR is set to current DR 334 and the value of BDR is set to the new BDR. 336 DR newcomer 337 \ / 338 ----- ----- ----- 339 | A | | B | | C | 340 ----- ----- ----- 341 | | | 342 | | | 343 ------------------------------------------- LAN 344 Figure 3 346 For example, there is a stable LAN that includes RouterA and RouterB. 347 RouterA is the DR which has the highest priority. RouterC is a 348 newcomer. RouterC sends hello packet with the DR and BDR are all set 349 to zero. 351 If RouterC cannot send hello packet with the DR/BDR capability, 352 Router C MAY send the hello packet according to the rule defined in 353 [RFC7761]. 355 If deployment requirement is to adopt with a new DR when it is 356 available, a new router with the highest priority or the highest IP 357 address sends hello packet with DR and BDR are all set to zero at 358 first. It sends hello packet with itself set to DR after it finish 359 join all the existing multicast groups. Then current DR compares 360 with the new router, the new router will be the final DR. 362 4.4. Receiving Hello Messages 364 When the values of DR and BDR which are carried by hello messages 365 received are all set to 0x0, the router MUST elect the DR using 366 procedure defined in DR election algorithm after the hold-timer 367 expires. And elect a new BDR which is the best choice except DR. 368 The election cases can be executed as follows: 370 In case the value of DR which is carried by received hello messages 371 is not 0x0, and the value of BDR is set to 0x0, when the hold-timer 372 expires there is no hello packet from other router is received, the 373 router will elect itself to BDR. 375 In case either of the values of DR and BDR that are carried by 376 received hello messages is greater than 0x0. The router will mark 377 the current DR, and compare itself with the BDR in the message. When 378 the router notices that it is better to be DR than the current BDR. 379 The router will elect itself to the BDR. 381 When a router receives a new hello message with the values of DR and 382 BDR are set to 0x0. The router will compare the new router with 383 current information. If the router noticed that the new router is 384 better to be DR than itself, or the new router is better to be BDR 385 than the current BDR, the router will set the BDR to the new router. 387 When current DR receives hello packet with the value of DR is set 388 larger than zero, the algorithm defined in section 4.2 can be used to 389 select the final DR. 391 As illustrated in Figure 3, after RouterC sends hello packet, RouterC 392 will not elect the DR until hold-timer expired. During the period, 393 RouterC should receive the hello packets from RouterA and RouterB. 394 RouterC accepts the result that RouterA is the DR. In case RouterC 395 has the lowest priority than RouterA and RouterB, RouterC will also 396 accept that Router B is the BDR. In case RouterC has the 397 intermediate priority among the three routers, RouterC will treat 398 itself as new BDR after the hold-timer expired. In case RouterC has 399 the highest priority among the three routers, RouterC will treat 400 RouterA which is the current DR as DR, and RouterC will treat itself 401 as the new BDR. If the network administrator thinks that RouterC 402 should be the new DR, the DR changing should be triggered manually. 403 That is RouterC will be elected as DR after it sends hello message 404 with DR is set to RouterC itself. 406 Exception: In case RouterC receives only the hello packet from 407 RouterA during the hold-timer period, when the hold-timer expired, 408 RouterC treats RouterA as DR, and RouterC treats itself as BDR. In 409 case RouterC only receives the hello packet from RouterB during the 410 hold-timer period, RouterC will compare the priority between RouterB 411 and itself to elect the new DR. In these situations, some interfaces 412 or links go wrong in the LAN. 414 4.5. The treatment 416 If all the routers on a shared-media LAN have started working at the 417 same time, then the election result of DR is same as the definition 418 in [RFC7761]. And all the routers will elect a BDR which is next 419 best to DR. The routers in the network MUST store the DR and BDR. 420 The hello messages sent by all the routers are the same with the 421 value of DR and BDR are all set. When a new router is activated on 422 the shared-media LAN and receives hello messages from other routers 423 with the value of DR is already set. The new router will not change 424 the current DR even if it is superior to the current DR. If the new 425 router is superior to current BDR, the new router will replace the 426 current BDR. 428 When the routers receive a hello message from a new router, the 429 routers compare the new router and all the other routers on the LAN. 430 If the new router is superior to the current BDR, the new router will 431 be the new BDR. Then the "old" BDR will send the Prune message to 432 upstream routers. 434 As a result, the BDR is the one which has the highest priority except 435 for DR. Once the DR is elected, the DR will not change until it 436 fails or be manually adjusted. Once the DR and BDR are elected, the 437 routers in the network MUST store the address of DR and BDR. 439 4.6. Sender side 441 DR/BDR function also can be used in source side that multiple routers 442 and source is in a same shared-media LAN. The algorithm is the same 443 as the receiver side. Only the BDR need not build multicast tree 444 from a downstream router. 446 5. Compatibility 448 If the LAN is a hybrid network that there are some routers which 449 support DR/BDR capability and the other routers which do not support 450 DR/BDR capability. All the routers MUST go backward to use the 451 election algorithm defined in [RFC7761]. And the values of DR and 452 BDR carried in hello message SHOULD be set to zero. That is once a 453 router sends hello messages with no DR/BDR options, the DR election 454 MUST go backward to the definition in [RFC7761]. 456 If the routers find that all the routers in the LAN support DR/BDR 457 capability by the hello messages with DR/BDR options set, they MUST 458 elect DR and BDR according the algorithm defined in this document. 459 And the routers MUST send hello messages with correct DR/BDR options 460 set. 462 In case there is only one router which does not support DR/BDR 463 capability in a shared-media LAN, the other routers in the LAN send 464 hello messages with the values of DR and BDR are set to zero, the 465 router which does not support DR/BDR capability ignores the options. 466 All the routers elect DR according to the algorithm defined in 467 [RFC7761]. When the router which does not support DR/BDR capability 468 goes away, the routers in the LAN MUST elect DR/BDR according to the 469 algorithm defined in this document, and send hello messages with 470 correct DR/BDR options set. 472 6. Deployment suggestion 474 If there are two or more routers which are responsible for multicast 475 flow forwarding on a shared-media LAN, and the multicast services are 476 sensitive to the lost of multicast packets, the functions of DR and 477 BDR, defined in this document, SHOULD be deployed. 479 7. Security Considerations 481 If an attacker which has the highest priority participates in the DR 482 election when a shared-media LAN starts to work, it will be elected 483 as DR, but it may not forward flows to receivers. And the attacker 484 remains DR position even if a legal router which has a higher 485 priority joins the LAN. 487 If an attacker is a newcomer which has a higher priority than the 488 existed BDR, it will be elected as the new BDR, but it may not 489 monitor DR, import multicast flows and forward flows to receiver when 490 DR is down. 492 In order to avoid these situations, source authentication should be 493 used to identify the validity of the DR/BDR candidates. 494 Authentication methods mentioned in section 6 RFC7761 can be used. 496 And the network administrator should consider the potential BFD 497 session attack if BFD is used between BDR and DR for DR failure 498 detection. The security function mentioned in section 9 RFC5880 can 499 be used. 501 8. IANA Considerations 503 IANA is requested to allocate two OptionTypes in TLVs of hello 504 message. One type is used for DR and the other one is used for BDR. 506 9. Acknowledgements 508 The authors would like to thank Greg Mirsky, Jake Holland, Stig 509 Venaas for their valuable comments and suggestions. 511 10. References 513 10.1. Normative References 515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 516 Requirement Levels", BCP 14, RFC 2119, 517 DOI 10.17487/RFC2119, March 1997, 518 . 520 [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, 521 S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. 522 Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): 523 Protocol Specification", RFC 2362, DOI 10.17487/RFC2362, 524 June 1998, . 526 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 527 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 528 Multicast - Sparse Mode (PIM-SM): Protocol Specification 529 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 530 2016, . 532 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 533 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 534 May 2017, . 536 10.2. Informative References 538 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 539 DOI 10.17487/RFC2328, April 1998, 540 . 542 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 543 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 544 . 546 Authors' Addresses 548 Zheng(Sandy) Zhang 549 ZTE Corporation 550 No. 50 Software Ave, Yuhuatai Distinct 551 Nanjing 552 China 554 Email: zhang.zheng@zte.com.cn 556 Fangwei Hu 557 ZTE Corporation 558 No.889 Bibo Rd 559 Shanghai 560 China 562 Email: hu.fangwei@zte.com.cn 564 Benchong Xu 565 ZTE Corporation 566 No. 68 Zijinghua Road, Yuhuatai Distinct 567 Nanjing 568 China 570 Email: xu.benchong@zte.com.cn 571 Mankamana Mishra 572 Cisco Systems 573 821 Alder Drive, 574 MILPITAS, CALIFORNIA 95035 575 UNITED STATES 577 Email: mankamis@cisco.com