idnits 2.17.1 draft-ietf-pim-dr-improvement-05.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 127: '... a shared-media LAN. But BDR MUST not...' RFC 2119 keyword, line 129: '...ows immediately. A single BDR MUST be...' RFC 2119 keyword, line 209: '...rs. But the BDR MUST not forward the ...' RFC 2119 keyword, line 218: '...R / BDR election SHOULD be handled in ...' RFC 2119 keyword, line 236: '... router MAY stop sending DR/BDR capa...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Backup Designated Router (BDR): Like DR, A BDR which acts on behalf of directly connected hosts in a shared-media LAN. But BDR MUST not forward the flows when DR works normally. When DR is down, the BDR will forward multicast flows immediately. A single BDR MUST be elected per interface like the DR. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When the new router becomes the new BDR, the router will join the current multicast groups, import multicast flows from upstream routers. But the BDR MUST not forward the multicast flows to avoid the duplicate multicast packets in the shared-media LAN. The new router will monitor the DR. The method that BDR monitors the DR may be BFD technology or other ways that can be used to detect link/node failure quickly. When the DR becomes unavailable because of the down or other reasons, the BDR will forward multicast flows immediately. -- The document date (June 28, 2018) is 2126 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: 'HRW' is defined on line 447, but no explicit reference was found in the text == Unused Reference: 'RFC2362' is defined on line 454, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'HRW' ** Obsolete normative reference: RFC 2362 (Obsoleted by RFC 4601, RFC 5059) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). 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: December 30, 2018 ZTE Corporation 6 Mankamana. Mishra 7 Cisco Systems 8 June 28, 2018 10 PIM DR Improvement 11 draft-ietf-pim-dr-improvement-05.txt 13 Abstract 15 PIM is widely deployed multicast protocol. PIM protocol is defined 16 in [RFC7761]. As deployment for PIM protocol is growing day by day, 17 user expects lower traffic loss and faster convergence in case of any 18 network failure. This document provides extension to the existing 19 protocol which would improve stability of PIM protocol with respect 20 to traffic loss and convergence time when the PIM DR is down. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 30, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. PIM hello message format . . . . . . . . . . . . . . . . . . 3 59 3.1. DR Address Option format . . . . . . . . . . . . . . . . 4 60 3.2. BDR Address Option format . . . . . . . . . . . . . . . . 4 61 4. The Protocol Treatment . . . . . . . . . . . . . . . . . . . 4 62 4.1. Deployment Choice . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Election Algorithm . . . . . . . . . . . . . . . . . . . 6 64 4.3. Sending Hello Messages . . . . . . . . . . . . . . . . . 7 65 4.4. Receiving Hello Messages . . . . . . . . . . . . . . . . 8 66 4.5. The treatment . . . . . . . . . . . . . . . . . . . . . . 9 67 4.6. Sender side . . . . . . . . . . . . . . . . . . . . . . . 9 68 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6. Deployment suggestion . . . . . . . . . . . . . . . . . . . . 9 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 73 10. Normative References . . . . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 Multicast technology is used widely. Many modern technologies, such 79 as IPTV, Net-Meeting, use PIM-SM to facilitate multicast service. 80 There are many events that will influence the quality of multicast 81 services. Like the change of unicast routes, the change of the PIM- 82 SM DR may cause the loss of multicast packets too. 84 After a DR on a shared-media LAN went down, other routers will elect 85 a new DR after the expiration of Hello-Holdtime. The default value 86 of Hello-Holdtime is 105 seconds. Although the minimum Hello 87 interval can be adjust to 1 second and the Hello-Holdtime is 3.5 88 times Hello interval. Thus, the detection of DR Down event cannot be 89 guaranteed in less than 3.5 seconds. And it is still too long for 90 modern multicast services. Still, may multicast packets will be 91 lost. The quality of IPTV and Net-Meeting will be influenced. 93 \ / 94 \ / 95 ------- ------- 96 | A | | B | 97 ------- ------- 98 | DR | 99 | | 100 ------- ------- 101 | SW |-----------------------------| SW | 102 ------- ------- 103 | | 104 Figure 1: An example of multicast network 106 For example, there are two routers on one Ethernet. RouterA is 107 elected to DR. When RouterA is down, the multicast packets are 108 discarded until the RouterB is elected to DR and RouterB imports the 109 multicast flows successfully. 111 We suppose that there is only a RouterA in the Ethernet at first in 112 Figure 1. RouterA is the DR which is responsible for forwarding 113 multicast flows. When RouterB connects to the Ethernet segment, 114 RouterB will be elected as DR because of its higher priority. So 115 RouterA will stop forwarding multicast packets. The multicast flows 116 will not recover until RouterB pulls the multicast flows after it is 117 elected to DR. 119 So if we want to increase the stability of DR, carrying DR/ BDR role 120 information in PIM hello packet is a feasible way to show the DR/ BDR 121 roles explicitly. It avoids the confusion caused by new comers which 122 has a higher priority. 124 2. Terminology 126 Backup Designated Router (BDR): Like DR, A BDR which acts on behalf 127 of directly connected hosts in a shared-media LAN. But BDR MUST not 128 forward the flows when DR works normally. When DR is down, the BDR 129 will forward multicast flows immediately. A single BDR MUST be 130 elected per interface like the DR. 132 Designed Router Other (DROther): A router which is neither DR nor 133 BDR. 135 3. PIM hello message format 137 In [RFC7761], the PIM hello message format is defined. In this 138 document, we define two new option values which are including Type, 139 Length, and Value. 141 0 1 2 3 142 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 143 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 144 | Hello message format | 145 | | 146 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 147 | OptionType + OptionLength | 148 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 149 | OptionValue | 150 | | 151 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 152 Figure 2: Hello message format 154 3.1. DR Address Option format 156 o OptionType : The value is TBD. 158 o OptionLength: If the network is support IPv4, the OptionLength is 159 4 octets. If the network is support IPv6, the OptionLength is 16 160 octets. 162 o OptionValue: The OptionValue is IP address of DR. If the network 163 is support IPv4, the value is IPv4 address of DR. If the network 164 is support IPv6, the value is IPv6 address of DR. 166 3.2. BDR Address Option format 168 o OptionType : The value is TBD. 170 o OptionLength: If the network is support IPv4, the OptionLength is 171 4 octets. If the network is support IPv6, the OptionLength is 16 172 octets. 174 o OptionValue: The OptionValue is IP address of BDR. If the network 175 is support IPv4, the value is IPv4 address of BDR. If the network 176 is support IPv6, the value is IPv6 address of BDR. 178 4. The Protocol Treatment 180 Carrying DR/ BDR role information in PIM hello packet is a feasible 181 way to keep the stability of DR. It avoid the confusion caused by 182 new comers which has a higher priority. So there are some changes in 183 PIM hello procedure and interface state machine. 185 A new router starts to send hello messages with the values of DR and 186 BDR are all set to 0 after its interface is enabled in PIM on a 187 shared-media LAN. When the router receives hello messages from other 188 routers on the same shared-media LAN, the router will check if the 189 value of DR is filled. If the value of DR is filled with IP address 190 of router which is sending hello messages, the router will store the 191 IP address as the DR address of this interface. 193 Then the new router compares the priority and IP address itself to 194 the stored information of DR and BDR according to the algorithm of 195 [RFC7761]. If the new router notices that it is better to be DR than 196 the current DR or BDR. The router will make itself the BDR, and send 197 new hello messages with its IP address as BDR and current DR. If the 198 router notices that the current DR has the highest priority in the 199 shared-media LAN, but the current BDR is set to 0x00000000 if IPv4 200 addresses are in use or 0:0:0:0:0:0:0:0/128 if IPv6 addresses are in 201 use in the received hello messages (To be simplify, we use 0x0 in 202 abbreviation in following parts of the draft), or the current BDR is 203 not better than the new router, the new router will elect itself to 204 BDR. If the router notices that it is not better to be DR than 205 current DR and BDR, the router will follow the current DR and BDR. 207 When the new router becomes the new BDR, the router will join the 208 current multicast groups, import multicast flows from upstream 209 routers. But the BDR MUST not forward the multicast flows to avoid 210 the duplicate multicast packets in the shared-media LAN. The new 211 router will monitor the DR. The method that BDR monitors the DR may 212 be BFD technology or other ways that can be used to detect link/node 213 failure quickly. When the DR becomes unavailable because of the down 214 or other reasons, the BDR will forward multicast flows immediately. 216 4.1. Deployment Choice 218 DR / BDR election SHOULD be handled in two ways. Selection of which 219 procedure to use would be totally dependent on deployment scenario. 221 1. The algorithm defined in [RFC7761] should be used if it is ok to 222 adopt with new DR as and when they are available, and the loss caused 223 by DR changing is acceptable. 225 2. If the deployment requirement is to have minium packets loss when 226 DR changing the mechanism defined in this draft should be used. That 227 is, if the new router notices that it is better to be DR than the 228 current DR or BDR, the router will make itself the BDR, and send new 229 hello message with its IP address as BDR and current DR. 231 According to section 4.9.2 defined in [RFC7761], the device receives 232 unknown options Hello packet will ignore it. So the new extension 233 defined in this draft will not influence the stability of neighbor. 234 But if the router which has the ability defined in this draft 235 receives non-DR/BDR capable Hello messages defined in [RFC7761], the 236 router MAY stop sending DR/BDR capable Hello messages in the LAN and 237 go back to use the advertisement and election algorithm defined in 238 [RFC7761]. 240 4.2. Election Algorithm 242 The DR and BDR election is according the rules defined below, the 243 algorithm is similar to the DR election definition in [RFC2328]. 245 (1) Note the current values for the network's Designated Router and 246 Backup Designated Router. This is used later for comparison 247 purposes. 249 (2) Calculate the new Backup Designated Router for the network as 250 follows. The router that has not declared itself to be Designated 251 Router is eligible to become Backup Designated Router. The one which 252 have the highest priority will be chosen to be Backup Designed 253 Router. In case of a tie, the one having the highest Router ID is 254 chosen. 256 (3) Calculate the new Designated Router for the network as follows. 257 If one or more of the routers have declared themselves Designated 258 Router (i.e., they are currently listing themselves as Designated 259 Router in their Hello Packets) the one having highest Router Priority 260 is declared to be Designated Router. In case of a tie, the one 261 having the highest Router ID is chosen. If no routers have declared 262 themselves Designated Router, assign the Designated Router to be the 263 same as the newly elected Backup Designated Router. 265 (4) If Router X is now newly the Designated Router or newly the 266 Backup Designated Router, or is now no longer the Designated Router 267 or no longer the Backup Designated Router, repeat steps 2 and 3, and 268 then proceed to step 5. For example, if Router X is now the 269 Designated Router, when step 2 is repeated X will no longer be 270 eligible for Backup Designated Router election. Among other things, 271 this will ensure that no router will declare itself both Backup 272 Designated Router and Designated Router. 274 (5) As a result of these calculations, the router itself may now be 275 Designated Router or Backup Designated Router. 277 The reason behind the election algorithm's complexity is the desire 278 for the DR stability. 280 The above procedure may elect the same router to be both Designated 281 Router and Backup Designated Router, although that router will never 282 be the calculating router (Router X) itself. The elected Designated 283 Router may not be the router having the highest Router Priority. If 284 Router X is not itself eligible to become Designated Router, it is 285 possible that neither a Backup Designated Router nor a Designated 286 Router will be selected in the above procedure. Note also that if 287 Router X is the only attached router that is eligible to become 288 Designated Router, it will select itself as Designated Router and 289 there will be no Backup Designated Router for the network. 291 4.3. Sending Hello Messages 293 According to Section 4.3.1 in [RFC7761], when a new router's 294 interface is enabled in PIM protocol, the router sends Hello messages 295 with the values of DR and BDR are filled with 0x0. Then the 296 interface is in Waiting state and start the hold-timer which is equal 297 to the Neighbor Liveness Timer. When the timer is expired, the 298 interface will elect the DR and BDR according to the DR election 299 rules. 301 When a new router sets itself BDR after receive hello messages from 302 other routers, the router send hello messages with the value of DR is 303 set to the IP address of current DR and the value of BDR is set to 304 the IP address of the router itself. 306 A current BDR MUST set itself DROther after it receives Hello 307 messages from other routers, the router will send hello messages with 308 the value of DR is set to current DR and the value of BDR is set to 309 new BDR. 311 DR newcomer 312 \ / 313 ----- ----- ----- 314 | A | | B | | C | 315 ----- ----- ----- 316 | | | 317 | | | 318 ------------------------------------------- LAN 319 Figure 3 321 For example, there is a stable LAN that includes RouterA and RouterB. 322 RouterA is the DR which has the best priority. RouterC is a 323 newcomer. RouterC sends hello packet with the DR and BDR is all set 324 to zero. 326 If RouterC cannot send hello packet with the DR/BDR capability, 327 Router C MAY send the hello packet according the rule defined in 328 [RFC7761]. 330 If deployment requirement is to adopt with new DR as and when they 331 are available, a new router with highest priority or best IP address 332 sends hello packet with DR and BDR all set to zero at first. It 333 sends hello packet with itself set to DR after it finish join all the 334 existing multicast groups. Then current DR compares with the new 335 router, the new router will be final DR. 337 4.4. Receiving Hello Messages 339 When the values of DR and BDR which are carried by hello messages are 340 received is all set to 0x0, the router MUST elect the DR using 341 procedure defined in DR election algorithm after the hold-timer 342 expires. And elect a new BDR which is the best choice except DR. 343 The election cases can be executed as following: 345 In case the value of DR which is carried by received hello messages 346 is not 0x0, and the value of BDR is set to 0x0, when the hold-timer 347 expires there is no hello packet from other router is received, the 348 router will elect itself to BDR. 350 In case either of the values of DR and BDR that are carried by 351 received hello messages are larger than 0x0. The router will mark 352 the current DR, and compare itself and the BDR in message. When the 353 router notice that it is better to be DR than current BDR. The 354 router will elect itself to the BDR. 356 When a router receives a new hello message with the values of DR and 357 BDR are set to 0x0. The router will compare the new router with 358 current information. If the router noticed that the new router is 359 better to be DR than itself, or the new router is better to be BDR 360 than the current BDR, the router will set the BDR to the new router. 362 When current DR receives hello packet with DR set larger than zero, 363 algorithm defined in section 4.1 can be used to select the final DR. 365 As illustrated in Figure 3, after RouterC sends hello packet, RouterC 366 will not elect the DR until hold-timer expired. During the period, 367 RouterC should receive the hello packets from RouterA and RouterB. 368 RouterC accepts the result that RouterA is the DR. In case RouterC 369 has the lowest priority than RouterA and RouterB, RouterC will also 370 accept that Router B is the BDR. In case RouterC has the 371 intermediate priority among the three routers, RouterC will treat 372 itself as new BDR after the hold-timer expired. In case RouterC has 373 the highest priority among the three routers, RouterC will treat 374 RouterA which is the current DR as DR, and RouterC will treat itself 375 as new BDR. If the network administrator thinks that RouterC should 376 be new DR, the DR changing should be triggered manually. 378 Exception: During the hold-timer period, RouterC receives only the 379 hello packet from RouterA. When the hold-timer expired, RouterC 380 treats RouterA as DR. and RouterC treats itself as BDR. In case 381 RouterC only receives the hello packet from RouterB during the hold- 382 timer period, RouterC will compare the priority between RouterB and 383 itself to elect the new DR. In these situations, some interfaces or 384 links go wrong in the LAN. 386 4.5. The treatment 388 When all the routers on a shared-media LAN are start to work on the 389 same time, the election result of DR is same as [RFC7761]. And all 390 the routers will elect a BDR which is next best to DR. The routers 391 in the network will store the DR and BDR. The hello messages sent by 392 all the routers are same with the value of DR and BDR are all set. 394 When a new router start to work on a shared-media LAN and receive 395 hello messages from other routers that the value of DR is set. The 396 new router will not change the current DR even if it is superior to 397 the current DR. If the new router is superior to current BDR, the 398 new router will replace the current BDR. 400 When the routers receive hello message from a new router, the routers 401 will compare the new router and all the other routers on the LAN. If 402 the new router is superior to current BDR, the new router will be new 403 BDR. Then the old BDR will send prune message to upstream routers. 405 As a result, the BDR is the one which has the highest priority except 406 DR. Once the DR is elected, the DR will not change until it fails or 407 manually adjustment. After the DR and BDR are elected, the routers 408 in the network will store the address of DR and BDR. 410 4.6. Sender side 412 DR/BDR function also can be used in source side that multiple routers 413 and source is in same shared-media network. The algorithm is the 414 same as the receiver side. Only the BDR need not build multicast 415 tree from downstream router. 417 5. Compatibility 419 If the LAN is a hybrid network that there are some routers which have 420 DR/BDR capability and the other routers which have not DR/BDR 421 capability. All the routers MAY go backward to use the algorithm 422 defined in [RFC7761]. 424 6. Deployment suggestion 426 If there are two and more routers which is responsible for multicast 427 flow forwarding on a shared-media LAN, and the multicast services is 428 sensitive to the lost of multicast packets, the function of DR and 429 BDR defined in this document SHOULD be deployed. 431 7. Security Considerations 433 For general PIM Security Considerations. 435 8. IANA Considerations 437 IANA is requested to allocate OptionType in TLVs of hello message. 438 Include DR and BDR. 440 9. Acknowledgements 442 The authors would like to thank Greg Mirsky for their valuable 443 comments and suggestions. 445 10. Normative References 447 [HRW] IEEE, "Using name-based mappings to increase hit rates", 448 IEEE HRW, February 1998. 450 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 451 DOI 10.17487/RFC2328, April 1998, 452 . 454 [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, 455 S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. 456 Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): 457 Protocol Specification", RFC 2362, DOI 10.17487/RFC2362, 458 June 1998, . 460 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 461 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 462 Multicast - Sparse Mode (PIM-SM): Protocol Specification 463 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 464 2016, . 466 Authors' Addresses 468 Zheng(Sandy) Zhang 469 ZTE Corporation 470 No. 50 Software Ave, Yuhuatai Distinct 471 Nanjing 472 China 474 Email: zhang.zheng@zte.com.cn 475 Fangwei Hu 476 ZTE Corporation 477 No.889 Bibo Rd 478 Shanghai 479 China 481 Email: hu.fangwei@zte.com.cn 483 Benchong Xu 484 ZTE Corporation 485 No. 68 Zijinghua Road, Yuhuatai Distinct 486 Nanjing 487 China 489 Email: xu.benchong@zte.com.cn 491 Mankamana Mishra 492 Cisco Systems 493 821 Alder Drive, 494 MILPITAS, CALIFORNIA 95035 495 UNITED STATES 497 Email: mankamis@cisco.com