idnits 2.17.1 draft-ietf-bess-evpn-per-mcast-flow-df-election-06.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 ([I-D.ietf-bess-evpn-igmp-mld-proxy], [I-D.ietf-bess-evpn-df-election-framework], [RFC7432]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 26, 2022) is 821 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: 'HRW1999' is defined on line 484, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'HRW1999' == Outdated reference: A later version (-09) exists of draft-ietf-bess-evpn-df-election-framework-03 == Outdated reference: A later version (-08) exists of draft-ietf-bess-evpn-fast-df-recovery-00 == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-00 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WorkGroup Ali. Sajassi 3 Internet-Draft Mankamana. Mishra 4 Intended status: Standards Track Samir. Thoria 5 Expires: July 30, 2022 Cisco Systems 6 Jorge. Rabadan 7 Nokia 8 John. Drake 9 Juniper Networks 10 January 26, 2022 12 Per multicast flow Designated Forwarder Election for EVPN 13 draft-ietf-bess-evpn-per-mcast-flow-df-election-06 15 Abstract 17 [RFC7432] describes mechanism to elect designated forwarder (DF) at 18 the granularity of (ESI, EVI) which is per VLAN (or per group of 19 VLANs in case of VLAN bundle or VLAN-aware bundle service). However, 20 the current level of granularity of per-VLAN is not adequate for some 21 applications.[I-D.ietf-bess-evpn-df-election-framework] improves base 22 line DF election by introducing HRW DF election. 23 [I-D.ietf-bess-evpn-igmp-mld-proxy] introduces applicability of EVPN 24 to Multicast flows, routes to sync them and a default DF election. 25 This document is an extension to HRW base draft 26 [I-D.ietf-bess-evpn-df-election-framework] and further enhances HRW 27 algorithm for the Multicast flows to do DF election at the 28 granularity of (ESI, VLAN, Mcast flow). 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 30, 2022. 47 Internet-DrafPer multicast flow Designated Forwarder Electi January 2022 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. The DF Election Extended Community . . . . . . . . . . . . . 4 69 4. HRW base per multicast flow EVPN DF election . . . . . . . . 6 70 4.1. DF election for IGMP (S,G) membership request . . . . . . 6 71 4.2. DF election for IGMP (*,G) membership request . . . . . . 7 72 4.3. Default DF election procedure . . . . . . . . . . . . . . 7 73 5. Procedure to use per multicast flow DF election algorithm . . 8 74 6. Triggers for DF re-election . . . . . . . . . . . . . . . . . 9 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 78 10. Normative References . . . . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 EVPN based All-Active multi-homing is becoming the basic building 84 block for providing redundancy in next generation data center 85 deployments as well as service provider access/aggregation networks. 86 [RFC7432] defines the role of a designated forwarder as the node in 87 the redundancy group that is responsible to forward Broadcast, 88 Unknown unicast, Multicast (BUM) traffic on that Ethernet Segment (CE 89 device or network) in All-Active multi-homing. 91 The default DF election mechanism allows selecting a DF at the 92 granularity of (ES, VLAN) or (ES, VLAN bundle) for BUM traffic. 93 While [I-D.ietf-bess-evpn-df-election-framework] improve on the 94 default DF election procedure, some service provider residential 95 applications require a finer granularity, where whole multicast flows 96 are delivered on a single VLAN. 98 Internet-DrafPer multicast flow Designated Forwarder Electi January 2022 100 (Multicast sources) 101 | 102 | 103 +---+ 104 |CE4| 105 +---+ 106 | 107 | 108 +-----+-----+ 109 +------------| PE-1 |------------+ 110 | | | | 111 | +-----------+ | 112 | | 113 | EVPN | 114 | | 115 | | 116 | (DF) (NDF)| 117 +-----------+ +-----------+ 118 | |EVI-1| | | |EVI-1| | 119 | PE-2 |------------------------| PE-3 | 120 +-----------+ +-----------+ 121 AC1 \ / AC2 122 \ / 123 \ ESI-1 / 124 \ / 125 \ / 126 +---------------+ 127 | CE2 | 128 +---------------+ 129 | 130 | 131 (Multiple receivers) 133 Figure 1: Multi-homing Network of EVPN 134 for IPTV deployments 136 Consider the above topology, which shows a typical residential 137 deployment scenario, where multiple receivers are behind an all- 138 active multihoming segments. All of the multicast traffic is 139 provisioned on EVI-1. Assume PE-2 get elected as DF. According to 140 [RFC7432], PE-2 will be responsible for forwarding multicast traffic 141 to that Ethernet segment. 143 o Forcing sole data plane forwarding responsibility on PE-2 is a 144 limitation in the current DF election mechanism. The topology at 145 Figure 1 would always have only one of the PE to be elected as DF 146 irrespective of which current DF election mechanism is in use 148 Internet-DrafPer multicast flow Designated Forwarder Electi January 2022 150 defined in [RFC7432] or 151 [I-D.ietf-bess-evpn-df-election-framework]. 153 o The problem may also manifest itself in a different way. For 154 example, AC1 happens to use 80% of its available bandwidth to 155 forward unicast data. And now there is need to serve multicast 156 receivers where it would require more than 20% of AC1 bandwidth. 157 In this case, AC1 becomes oversubscribed and multicast traffic 158 drop would be observed even though there is already another link 159 (AC2) present in network which can be used more efficiently load 160 balance the multicast traffic. 162 In this document, we propose an extension to the HRW base draft to 163 allow DF election at the granularity of (ESI, VLAN, Mcast flow) which 164 would allow multicast flows to be better distributed among redundancy 165 group PEs to share the load. 167 2. Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119] . 173 With respect to EVPN, this document follows the terminology that has 174 been defined in [RFC7432] and [RFC4601] for multicast terminology. 176 3. The DF Election Extended Community 178 [I-D.ietf-bess-evpn-df-election-framework] defines an extended 179 community, which would be used for PEs in redundancy group to reach a 180 consensus as to which DF election procedure is desired. A PE can 181 notify other participating PEs in redundancy group about its 182 willingness to support Per multicast flow base DF election capability 183 by signaling a DF election extended community along with Ethernet- 184 Segment Route (Type-4). The current proposal extends the existing 185 extended community defined in 186 [I-D.ietf-bess-evpn-df-election-framework]. This draft defines new a 187 DF type. 189 o DF type (1 octet) - Encodes the DF Election algorithm values 190 (between 0 and 255) that the advertising PE desires to use for the 191 ES. 193 * Type 0: Default DF Election algorithm, or modulus-based 194 algorithms in [RFC7432]. 196 * Type 1: HRW algorithm defined in 197 [I-D.ietf-bess-evpn-df-election-framework] 199 Internet-DrafPer multicast flow Designated Forwarder Electi January 2022 201 * Type 2: Handshake defines in 202 [I-D.ietf-bess-evpn-fast-df-recovery] 204 * Type 3: Time-Synch defined in 205 [I-D.ietf-bess-evpn-fast-df-recovery] 207 * Type 4: HRW base per (S,G) multicast flow DF election 208 (explained in this document) 210 * Type 5: HRW base per (*,G) multicast flow DF election 211 (explained in this document) 213 * Type 6 - 254: Unassigned 215 * Type 255: Reserved for Experimental Use. 217 o The [I-D.ietf-bess-evpn-df-election-framework] describes encoding 218 of capabilities associated to the DF election algorithm using 219 Bitmap field. When these capabilities bits are set along with the 220 DF type-4 and type-5, they need to be interpreted in context of 221 this new DF type-4 and type-5. For example, consider a scenario 222 where all PEs in the same redundancy group (same ES) can support 223 both AC-DF, DF type-4 and DF type-5 and receive such indications 224 from the other PEs in the ES. In this scenario, if a VLAN is not 225 active in a PE, then the DF election procedure on all PEs in the 226 ES should factor that in and exclude that PE in the DF election 227 per multicast flow. 229 o A PE SHOULD attach the DF election Extended Community to ES route 230 and Extended Community MUST be sent if the ES is locally 231 configured for DF type Per Multicast flow DF election. Only one 232 DF Election Extended community can be sent along with an ES route. 234 o When a PE receives the ES Routes from all the other PEs for the 235 ES, it checks if all of other PEs have advertised their desire to 236 proceed by Per multicast flow DF election. If all peering PEs 237 have done so, it performs DF election based on Per multicast flow 238 procedure. But if: 240 * There is at least one PE which advertised route-4 ( AD per ES 241 Route) which does not indicate its capability to perform Per 242 multicast flow DF election. OR 244 * There is at least one PE signaling single active in the AD per 245 ES route 247 Internet-DrafPer multicast flow Designated Forwarder Electi January 2022 249 it MUST be considered as an indication to support of only Default 250 DF election [RFC7432] and DF election procedure in [RFC7432] MUST 251 be used. 253 4. HRW base per multicast flow EVPN DF election 255 This document is an extension of 256 [I-D.ietf-bess-evpn-df-election-framework], so this draft does not 257 repeat the description of HRW algorithm itself. 259 EVPN PE does the discovery of redundancy groups based on [RFC7432]. 260 If redundancy group consists of N peering EVPN PE nodes, after the 261 discovery all PEs build an unordered list of IP address of all the 262 nodes in the redundancy group. The procedure defined in this draft 263 does not require the list of PEs to be ordered. Address [i] denotes 264 the IP address of the [i]th EVPN PE in redundancy group where (0 < i 265 <= N ). 267 4.1. DF election for IGMP (S,G) membership request 269 The DF is the PE who has maximum weight for (S, G, V, Es) where 271 o S - Multicast Source 273 o G - Multicast Group 275 o V - VLAN ID. 277 o Es - Ethernet Segment Identifier 279 Address[i] is address of the ith PE. The PEs IP address length does 280 not matter as only the lower-order 31 bits are modulo significant. 282 1. Weight 284 * The weight of PE(i) to (S,G,VLAN ID, Es) is calculated by 285 function, weight (S,G,V, Es, Address(i)), where (0 < i <= N), 286 PE(i) is the PE at ordinal i. 288 * Weight (S,G,V, Es, Address(i)) = (1103515245. 289 ((1103515245.Address(i) + 12345) XOR D(S,G,V,ESI))+12345) (mod 290 2^31) 292 * In case of tie, the PE whose IP address is numerically least 293 is chosen. 295 2. Digest 297 Internet-DrafPer multicast flow Designated Forwarder Electi January 2022 299 * D(S,G,V, Es) = CRC_32(S,G,V, Es) 301 * Here D(S,G,V,Es) is the 31-bit digest (CRC_32 and discarding 302 the MSB) of the Source IP, Group IP, Vlan ID and Es. The CRC 303 MUST proceed as if the architecture is in network byte order 304 (big-endian). 306 4.2. DF election for IGMP (*,G) membership request 308 The DF is the PE who has maximum weight for (G, V, Es) where 310 o G - Multicast Group 312 o V - VLAN ID. 314 o Es - Ethernet Segment Identifier 316 Address[i] is address of the ith PE. The PEs IP address length does 317 not matter as only the lower-order 31 bits are modulo significant. 319 1. Weight 321 * The weight of PE(i) to (G,VLAN ID, Es) is calculated by 322 function, weight (G,V, Es, Address(i)), where (0 < i <= N), 323 PE(i) is the PE at ordinal i. 325 * Weight (G,V, Es, Address(i)) = (1103515245. 326 ((1103515245.Address(i) + 12345) XOR D(G,V,ESI))+12345) (mod 327 2^31) 329 * In case of tie, the PE whose IP address is numerically least 330 is chosen. 332 2. Digest 334 * D(G,V, Es) = CRC_32(G,V, Es) 336 * Here D(G,V,Es) is the 31-bit digest (CRC_32 and discarding the 337 MSB) of the Group IP, Vlan ID and Es. The CRC MUST proceed as 338 if the architecture is in network byte order (big-endian). 340 4.3. Default DF election procedure 342 Per multicast DF election procedure would be applicable only when 343 host behind Attachment Circuit (of the Es) start sending IGMP 344 membership requests. Membership requests are synced using procedure 345 defined in [I-D.ietf-bess-evpn-igmp-mld-proxy], and each of the PE in 346 redundancy group can use per flow DF election and create DF state per 348 Internet-DrafPer multicast flow Designated Forwarder Electi January 2022 350 multicast flow. The HRW DF election "Type 1" procedure defined in 351 [I-D.ietf-bess-evpn-df-election-framework] MUST be used for the Es DF 352 election and SHOULD be performed on Es even before learning multicast 353 membership request state. This default election procedure MUST be 354 used at port level but will be overwritten by Per flow DF election as 355 and when new membership request state are learnt. 357 5. Procedure to use per multicast flow DF election algorithm 359 Multicast Source 360 | 361 | 362 | 363 | 364 +---------+ 365 +--------------+ PE-4 +--------------+ 366 | | | | 367 | +---------+ | 368 | | 369 | EVPN CORE | 370 | | 371 | | 372 | | 373 +---------+ +---------+ +---------+ 374 | PE-1 +--------+ PE-2 +---------+ PE-3 | 375 | EVI-1 | | EVI-1 | | EVI-1 | 376 +---------+ +---------+ +---------+ 377 |__________________|___________________| 378 AC-1 ESI-1 | AC-2 AC-3 379 +---------+ 380 | CE-1 | 381 | | 382 +---------+ 383 | 384 | 385 | 386 | 387 Multicast Receivers 389 Figure-2 : Multihomed network 391 Figure-2 shows multihomed network. Where EVPN PE-1, PE-2, PE-3 are 392 multihomed to CE-1. Multiple multicast receivers are behind all 393 active multihoming segment. 395 1. PEs connected to the same Ethernet segment can automatically 396 discover each other through exchange of the Ethernet Segment 398 Internet-DrafPer multicast flow Designated Forwarder Electi January 2022 400 Route. This draft does not change any of this procedure, it 401 still uses the procedure defined in [RFC7432]. 403 2. Each of the PEs in redundancy group advertise Ethernet segment 404 route with extended community indicating their ability to 405 participate in per multicast flow DF election procedure. Since 406 Per multicast flow would not be applicable unless PE learns about 407 membership request from receiver, there is a need to have the 408 default DF election among PEs in redundancy group for BUM 409 traffic. Until multicast membership state are learnt, we use the 410 the DF election procedure in Section 4.3, namely HRW per (v,Es) 411 as defined in [I-D.ietf-bess-evpn-df-election-framework] . 413 3. When a receiver starts sending membership requests for (s1,g1), 414 where s1 is multicast source address and g1 is multicast group 415 address, CE-1 could hash membership request (IGMP join) to any of 416 the PEs in redundancy group. Let's consider it is hashed to PE- 417 2. [I-D.ietf-bess-evpn-igmp-mld-proxy] defines a procedure to 418 sync IGMP join state among redundancy group of PEs. Now each of 419 the PE would have information about membership request (s1,g1) 420 and each of them run DF election procedure Section 4.1 to elect 421 DF among participating PEs in redundancy group. Consider PE-2 422 gets elected as DF for multicast flow (s1,g1). 424 1. PE-1 forwarding state would be nDF for flow (s1,g1) and DF 425 for rest other BUM traffic. 427 2. PE-2 forwarding state would be DF for flow (s1,g1) and nDF 428 for rest other BUM traffic. 430 3. PE-3 forwarding state would be nDF for flow (s1,g1) and rest 431 other BUM traffic. 433 4. As and when new multicast membership request comes, same 434 procedure as above would continue. 436 5. If Section 3 has DF type 4, For membership request (S,G) it MUST 437 use Section 4.1 to elect DF among participating PEs. And 438 membership request (*,G) MUST use Section 4.2 to elect DF among 439 participating PEs. 441 6. Triggers for DF re-election 443 There are multiple triggers which can cause DF re-election. Some of 444 the triggers could be 446 1. Local ES going down due to physical failure or configuration 447 change triggers DF re-election at peering PE. 449 Internet-DrafPer multicast flow Designated Forwarder Electi January 2022 451 2. Detection of new PE through ES route. 453 3. AC going up / down 455 4. ESI change 457 5. Remote PE removed / Down 459 6. Local configuration change of DF election Type and peering PE 460 consensus on new DF Type 462 This document does not provide any new mechanism to handle DF re- 463 election procedure. It uses the existing mechanism defined in 464 [RFC7432]. Whenever either of the triggers occur, a DF re-election 465 would be done. and all of the flows would be redistributed among 466 existing PEs in redundancy group for ES. 468 7. Security Considerations 470 The same Security Considerations described in [RFC7432] are valid for 471 this document. 473 8. IANA Considerations 475 Allocation of DF type in DF extended community for EVPN. 477 9. Acknowledgement 479 Authors would like to acknowledge helpful comments and contributions 480 of Luc Andre Burdet. 482 10. Normative References 484 [HRW1999] IEEE, "Using name-based mappings to increase hit rates", 485 IEEE HRW, February 1998. 487 [I-D.ietf-bess-evpn-df-election-framework] 488 Rabadan, J., satyamoh@cisco.com, s., Sajassi, A., Drake, 489 J., Nagaraj, K., and S. Sathappan, "Framework for EVPN 490 Designated Forwarder Election Extensibility", draft-ietf- 491 bess-evpn-df-election-framework-03 (work in progress), May 492 2018. 494 [I-D.ietf-bess-evpn-fast-df-recovery] 495 Sajassi, A., Badoni, G., Rao, D., Brissette, P., Drake, 496 J., and J. Rabadan, "Fast Recovery for EVPN DF Election", 497 draft-ietf-bess-evpn-fast-df-recovery-00 (work in 498 progress), June 2018. 500 Internet-DrafPer multicast flow Designated Forwarder Electi January 2022 502 [I-D.ietf-bess-evpn-igmp-mld-proxy] 503 Sajassi, A., Thoria, S., Patel, K., Yeung, D., Drake, J., 504 and W. Lin, "IGMP and MLD Proxy for EVPN", draft-ietf- 505 bess-evpn-igmp-mld-proxy-00 (work in progress), March 506 2017. 508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 509 Requirement Levels", BCP 14, RFC 2119, 510 DOI 10.17487/RFC2119, March 1997, 511 . 513 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 514 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 515 Protocol Specification (Revised)", RFC 4601, 516 DOI 10.17487/RFC4601, August 2006, 517 . 519 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 520 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 521 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 522 2015, . 524 Authors' Addresses 526 Ali Sajassi 527 Cisco Systems 528 821 Alder Drive, 529 MILPITAS, CALIFORNIA 95035 530 UNITED STATES 532 Email: sajassi@cisco.com 534 Mankamana Mishra 535 Cisco Systems 536 821 Alder Drive, 537 MILPITAS, CALIFORNIA 95035 538 UNITED STATES 540 Email: mankamis@cisco.com 542 Internet-DrafPer multicast flow Designated Forwarder Electi January 2022 544 Samir Thoria 545 Cisco Systems 546 821 Alder Drive, 547 MILPITAS, CALIFORNIA 95035 548 UNITED STATES 550 Email: sthoria@cisco.com 552 Jorge Rabadan 553 Nokia 554 777 E. Middlefield Road 555 Mountain View, CA 94043 556 UNITED STATES 558 Email: jorge.rabadan@nokia.com 560 John Drake 561 Juniper Networks 563 Email: jdrake@juniper.net