idnits 2.17.1 draft-ietf-bess-evpn-igmp-mld-proxy-21.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 10 instances of too long lines in the document, the longest one being 19 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 22, 2022) is 764 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WorkGroup A. Sajassi 3 Internet-Draft S. Thoria 4 Intended status: Standards Track M. Mishra 5 Expires: September 23, 2022 Cisco Systems 6 K. Patel 7 Arrcus 8 J. Drake 9 W. Lin 10 Juniper Networks 11 March 22, 2022 13 IGMP and MLD Proxy for EVPN 14 draft-ietf-bess-evpn-igmp-mld-proxy-21 16 Abstract 18 This document describes how to support efficiently endpoints running 19 IGMP(Internet Group Management Protocol) or MLD (Multicast Listener 20 Discovery) for the multicast services over an EVPN network by 21 incorporating IGMP/MLD proxy procedures on EVPN (Ethernet VPN) PEs. 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 September 23, 2022. 40 Copyright Notice 42 Copyright (c) 2022 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Proxy Reporting . . . . . . . . . . . . . . . . . . . . . 6 62 4.1.1. IGMP/MLD Membership Report Advertisement in BGP . . . 7 63 4.1.2. IGMP/MLD Leave Group Advertisement in BGP . . . . . . 9 64 4.2. Proxy Querier . . . . . . . . . . . . . . . . . . . . . . 9 65 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 5.1. PE with only attached hosts for a given subnet . . . . . 11 67 5.2. PE with a mix of attached hosts and multicast source . . 12 68 5.3. PE with a mix of attached hosts, a multicast source and a 69 router . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 6. All-Active Multi-Homing . . . . . . . . . . . . . . . . . . . 12 71 6.1. Local IGMP/MLD Membership Report Synchronization . . . . 12 72 6.2. Local IGMP/MLD Leave Group Synchronization . . . . . . . 13 73 6.2.1. Remote Leave Group Synchronization . . . . . . . . . 14 74 6.2.2. Common Leave Group Synchronization . . . . . . . . . 14 75 6.3. Mass Withdraw of Multicast Membership Report Sync route 76 in case of failure . . . . . . . . . . . . . . . . . . . 15 77 7. Single-Active Multi-Homing . . . . . . . . . . . . . . . . . 15 78 8. Selective Multicast Procedures for IR tunnels . . . . . . . . 15 79 9. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . 16 80 9.1. Selective Multicast Ethernet Tag Route . . . . . . . . . 16 81 9.1.1. Constructing the Selective Multicast Ethernet Tag 82 route . . . . . . . . . . . . . . . . . . . . . . . . 18 83 9.1.2. Reconstructing IGMP / MLD Membership Reports from 84 Selective Multicast Route . . . . . . . . . . . . . . 19 85 9.1.3. Default Selective Multicast Route . . . . . . . . . . 20 86 9.2. Multicast Membership Report Synch Route . . . . . . . . . 21 87 9.2.1. Constructing the Multicast Membership Report Synch 88 Route . . . . . . . . . . . . . . . . . . . . . . . . 22 89 9.2.2. Reconstructing IGMP / MLD Membership Reports from 90 Multicast Membership Report Sync Route . . . . . . . 23 91 9.3. Multicast Leave Synch Route . . . . . . . . . . . . . . . 24 92 9.3.1. Constructing the Multicast Leave Synch Route . . . . 26 93 9.3.2. Reconstructing IGMP / MLD Leave from Multicast Leave 94 Sync Route . . . . . . . . . . . . . . . . . . . . . 27 95 9.4. Multicast Flags Extended Community . . . . . . . . . . . 28 96 9.5. EVI-RT Extended Community . . . . . . . . . . . . . . . . 29 97 9.6. Rewriting of RT ECs and EVI-RT ECs by ASBRs . . . . . . . 31 98 9.7. BGP Error Handling . . . . . . . . . . . . . . . . . . . 32 99 10. IGMP Version 1 Membership Report . . . . . . . . . . . . . . 32 100 11. Security Considerations . . . . . . . . . . . . . . . . . . . 32 101 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 102 12.1. EVPN Extended Community Sub-Types Registrations . . . . 32 103 12.2. EVPN Route Type Registration . . . . . . . . . . . . . . 33 104 12.3. Multicast Flags Extended Community Registry . . . . . . 33 105 13. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 33 106 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 107 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 108 15.1. Normative References . . . . . . . . . . . . . . . . . . 34 109 15.2. Informative References . . . . . . . . . . . . . . . . . 35 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 112 1. Introduction 114 In DC applications, a point of delivery (POD) can consist of a 115 collection of servers supported by several top of rack (ToR) and 116 spine switches. This collection of servers and switches are self 117 contained and may have their own control protocol for intra-POD 118 communication and orchestration. However, EVPN is used as standard 119 way of inter-POD communication for both intra-DC and inter-DC. A 120 subnet can span across multiple PODs and DCs. EVPN provides a robust 121 multi-tenant solution with extensive multi-homing capabilities to 122 stretch a subnet (VLAN) across multiple PODs and DCs. There can be 123 many hosts (several hundreds) attached to a subnet that is stretched 124 across several PODs and DCs. 126 These hosts express their interests in multicast groups on a given 127 subnet/VLAN by sending IGMP/MLD Membership Reports for their 128 interested multicast group(s). Furthermore, an IGMP/MLD router 129 periodically sends membership queries to find out if there are hosts 130 on that subnet that are still interested in receiving multicast 131 traffic for that group. The IGMP/MLD Proxy solution described in 132 this document accomplishes three objectives: 134 1. Reduce flooding of IGMP/MLD messages: just like the ARP/ND 135 suppression mechanism in EVPN to reduce the flooding of ARP 136 messages over EVPN, it is also desired to have a mechanism to 137 reduce the flooding of IGMP/MLD messages (both Queries and 138 Membership Reports) in EVPN. 140 2. Distributed anycast multicast proxy: it is desirable for the EVPN 141 network to act as a distributed anycast multicast router with 142 respect to IGMP/MLD proxy function for all the hosts attached to 143 that subnet. 145 3. Selective Multicast: to forward multicast traffic over EVPN 146 network such that it only gets forwarded to the PEs that have 147 interest in the multicast group(s). This document shows how this 148 objective may be achieved when Ingress Replication is used to 149 distribute the multicast traffic among the PEs. Procedures for 150 supporting selective multicast using P2MP tunnels can be found in 151 [I-D.ietf-bess-evpn-bum-procedure-updates] 153 The first two objectives are achieved by using IGMP/MLD proxy on the 154 PE. The third objective is achieved by setting up a multicast tunnel 155 only among the PEs that have interest in that multicast group(s) 156 based on the trigger from IGMP/MLD proxy processes. The proposed 157 solutions for each of these objectives are discussed in the following 158 sections. 160 2. Specification of Requirements 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in BCP 165 14 [RFC2119] [RFC8174] when, and only when, they appear in all 166 capitals, as shown here. 168 3. Terminology 170 o AC: Attachment Circuit. 172 o All-Active Redundancy Mode: When all PEs attached to an Ethernet 173 segment are allowed to forward known unicast traffic to/from that 174 Ethernet segment for a given VLAN, then the Ethernet segment is 175 defined to be operating in All-Active redundancy mode. 177 o BD: Broadcast Domain. As per [RFC7432], an EVI consists of a 178 single or multiple BDs. In case of VLAN-bundle and VLAN-aware 179 bundle service model, an EVI contains multiple BDs. Also, in this 180 document, BD and subnet are equivalent terms. 182 o DC: Data Center 184 o Ethernet Segment (ES): When a customer site (device or network) is 185 connected to one or more PEs via a set of Ethernet links. 187 o Ethernet Segment Identifier (ESI): A unique non-zero identifier 188 that identifies an Ethernet Segment. 190 o Ethernet Tag: It identifies a particular broadcast domain, e.g., a 191 VLAN. An EVPN instance consists of one or more broadcast domains. 193 o EVI: An EVPN instance spanning the Provider Edge (PE) devices 194 participating in that EVPN 196 o EVPN: Ethernet Virtual Private Network 198 o IGMP: Internet Group Management Protocol 200 o IR: Ingress Replication 202 o MLD: Multicast Listener Discovery 204 o OIF: Outgoing Interface for multicast. It can be physical 205 interface, virtual interface or tunnel. 207 o PE: Provider Edge. 209 o POD: Point of Delivery 211 o S-PMSI: Selective P-Multicast Service Interface - a conceptual 212 interface for a PE to send customer multicast traffic to some of 213 the PEs in the same VPN. 215 o Single-Active Redundancy Mode: When only a single PE, among all 216 the PEs attached to an Ethernet segment, is allowed to forward 217 traffic to/from that Ethernet segment for a given VLAN, then the 218 Ethernet segment is defined to be operating in Single-Active 219 redundancy mode. 221 o SMET: Selective Multicast Ethernet Tag 223 o ToR: Top of Rack 225 This document also assumes familiarity with the terminology of 226 [RFC7432], [RFC3376], [RFC2236] . Though most of the place this 227 document uses term IGMP Membership Report, the text applies equally 228 for MLD Membership Report too. Similarly, text for IGMPv2 applies to 229 MLDv1 and text for IGMPv3 applies to MLDv2. IGMP / MLD version 230 encoding in BGP update is stated in Section 9 232 It is important to note when there is text considering whether a PE 233 indicates support for IGMP proxying, the corresponding behavior has a 234 natural analogue for indication of support for MLD proxying, and the 235 analogous requirements apply as well. 237 4. IGMP/MLD Proxy 239 The IGMP Proxy mechanism is used to reduce the flooding of IGMP 240 messages over an EVPN network similar to ARP proxy used in reducing 241 the flooding of ARP messages over EVPN. It also provides a 242 triggering mechanism for the PEs to setup their underlay multicast 243 tunnels. The IGMP Proxy mechanism consists of two components: 245 1. Proxy for IGMP Membership Reports. 247 2. Proxy for IGMP Membership Queries. 249 The goal of IGMP and MLD proxying is to make the EVPN behave 250 seamlessly for the tenant systems with respect to multicast 251 operations, while using a more efficient delivery system for 252 signaling and delivery across the VPN. Accordingly, group state must 253 be tracked synchronously among the PEs serving the VPN, with join and 254 leave events propagated to the peer PEs, and each PE tracking the 255 state of each of its peer PEs with respect whether there are locally 256 attached group members (and in some cases, senders), what version(s) 257 of IGMP/MLD are in use for those locally attached group members, etc. 258 In order to perform this translation, each PE acts as an IGMP router 259 for the locally attached domain, and maintains the requisite state on 260 locally attached nodes, sends periodic membership queries, etc. The 261 role of EVPN SMET route propagation is to ensure that each PE's local 262 state is propagated to the other PEs so that they share a consistent 263 view of the overall IGMP Membership Request and Leave Group state. 264 It is important to note that the need to keep such local state can be 265 triggered by either local IGMP traffic or BGP EVPN signaling. In 266 most cases a local IGMP event will need to be signaled over EVPN, 267 though state initiated by received EVPN traffic will not always need 268 to be relayed to the locally attached domain. 270 4.1. Proxy Reporting 272 When IGMP protocol is used between hosts and their first hop EVPN 273 router (EVPN PE), Proxy-reporting is used by the EVPN PE to summarize 274 (when possible) reports received from downstream hosts and propagate 275 them in BGP to other PEs that are interested in the information. 276 This is done by terminating the IGMP Reports in the first hop PE, and 277 translating and exchanging the relevant information among EVPN BGP 278 speakers. The information is again translated back to IGMP message 279 at the recipient EVPN speaker. Thus it helps create an IGMP overlay 280 subnet using BGP. In order to facilitate such an overlay, this 281 document also defines a new EVPN route type NLRI, the EVPN Selective 282 Multicast Ethernet Tag route, along with its procedures to help 283 exchange and register IGMP multicast groups Section 9. 285 4.1.1. IGMP/MLD Membership Report Advertisement in BGP 287 When a PE wants to advertise an IGMP Membership Report using the BGP 288 EVPN route, it follows the following rules (BGP encoding stated in 289 Section 9). Where first four rules are applicable to originator PE 290 and last three rules are applicable to remote PE processing SMET 291 routes: 293 Processing at BGP route originator: 295 1. When the first hop PE receives IGMP Membership Reports , 296 belonging to the same IGMP version, from different attached hosts 297 for the same (*,G) or (S,G), it SHOULD send a single BGP message 298 corresponding to the very first IGMP Membership Request (BGP 299 update as soon as possible) for that (*,G) or (S,G). This is 300 because BGP is a stateful protocol and no further transmission of 301 the same report is needed. If the IGMP Membership Request is for 302 (*,G), then multicast group address MUST be sent along with the 303 corresponding version flag (v2 or v3) set. In case of IGMPv3, 304 the exclude flag MUST also be set to indicate that no source IP 305 address must be excluded (include all sources "*"). If the IGMP 306 Membership Report is for (S,G), then besides setting multicast 307 group address along with the version flag v3, the source IP 308 address and the IE flag MUST be set. It should be noted that 309 when advertising the EVPN route for (S,G), the only valid version 310 flag is v3 (v2 flags MUST be set to zero). 312 2. When the first hop PE receives an IGMPv3 Membership Report for 313 (S,G) on a given BD, it MUST advertise the corresponding EVPN 314 Selective Multicast Ethernet Tag (SMET) route regardless of 315 whether the source (S) is attached to itself or not in order to 316 facilitate the source move in the future. 318 3. When the first hop PE receives an IGMP version-X Membership 319 Report first for (*,G) and then later it receives an IGMP 320 version-Y Membership Report for the same (*,G), then it MUST re- 321 advertise the same EVPN SMET route with flag for version-Y set in 322 addition to any previously-set version flag(s). In other words, 323 the first hop PE MUST NOT withdraw the EVPN route before sending 324 the new route because the flag field is not part of BGP route key 325 processing. 327 4. When the first hop PE receives an IGMP version-X Membership 328 Report first for (*,G) and then later it receives an IGMPv3 329 Membership Report for the same multicast group address but for a 330 specific source address S, then the PE MUST advertise a new EVPN 331 SMET route with v3 flag set (and v2 reset). The IE flag also 332 need to be set accordingly. Since source IP address is used as 333 part of BGP route key processing it is considered as a new BGP 334 route advertisement. When different version of IGMP Membership 335 Report are received, final state MUST be as per section 5.1 of 336 [RFC3376]. At the end of route processing local and remote group 337 record state MUST be as per section 5.1 of [RFC3376]. 339 Processing at BGP route receiver: 341 1. When a PE receives an EVPN SMET route with more than one version 342 flag set, it will generate the corresponding IGMP report for 343 (*,G) for each version specified in the flags field. With 344 multiple version flags set, there must not be source IP address 345 in the received EVPN route. If there is, then an error SHOULD be 346 logged. If the v3 flag is set (in addition to v2), then the IE 347 flag MUST indicate "exclude". If not, then an error SHOULD be 348 logged. The PE MUST generate an IGMP Membership Report for that 349 (*,G) and each IGMP version in the version flag. 351 2. When a PE receives a list of EVPN SMET NLRIs in its BGP update 352 message, each with a different source IP address and the same 353 multicast group address, and the version flag is set to v3, then 354 the PE generates an IGMPv3 Membership Report with a record 355 corresponding to the list of source IP addresses and the group 356 address along with the proper indication of inclusion/exclusion. 358 3. Upon receiving EVPN SMET route(s) and before generating the 359 corresponding IGMP Membership Request(s), the PE checks to see 360 whether it has any CE multicast router for that BD on any of its 361 ES's . The PE provides such a check by listening for PIM Hello 362 messages on that AC (i.e, ES,BD). If the PE does have the 363 router's ACs, then the generated IGMP Membership Request(s) are 364 sent to those ACs. If it doesn't have any of the router's AC, 365 then no IGMP Membership Request(s) needs to be generated. This 366 is because sending IGMP Membership Requests to other hosts can 367 result in unintentionally preventing a host from joining a 368 specific multicast group using IGMPv2 - i.e., if the PE does not 369 receive a Membership Report from the host it will not forward 370 multicast data to it. Per [RFC4541] , when an IGMPv2 host 371 receives a Membership Report for a group address that it intends 372 to join, the host will suppress its own membership report for the 373 same group, and if the PE does not receive an IGMP Membership 374 Report from the host it will not forward multicast data to it. 375 In other words, an IGMPv2 Membership Report MUST NOT be sent on 376 an AC that does not lead to a CE multicast router. This message 377 suppression is a requirement for IGMPv2 hosts. This is not a 378 problem for hosts running IGMPv3 because there is no suppression 379 of IGMP Membership Reports. 381 4.1.2. IGMP/MLD Leave Group Advertisement in BGP 383 When a PE wants to withdraw an EVPN SMET route corresponding to an 384 IGMPv2 Leave Group or IGMPv3 "Leave" equivalent message, it follows 385 the following rules, where first rule defines the procedure at 386 originator PE and last two rules talk about procedures at remote PE: 388 Processing at BGP route originator: 390 1. When a PE receives an IGMPv2 Leave Group or its "Leave" 391 equivalent message for IGMPv3 from its attached host, it checks 392 to see if this host is the last host that is interested in this 393 multicast group by sending a query for the multicast group. If 394 the host was indeed the last one (i.e. no responses are received 395 for the query), then the PE MUST re-advertises EVPN SMET 396 Multicast route with the corresponding version flag reset. If 397 this is the last version flag to be reset, then instead of re- 398 advertising the EVPN route with all version flags reset, the PE 399 MUST withdraw the EVPN route for that (*,G). 401 Processing at BGP route receiver: 403 1. When a PE receives an EVPN SMET route for a given (*,G), it 404 compares the received version flags from the route with its per- 405 PE stored version flags. If the PE finds that a version flag 406 associated with the (*,G) for the remote PE is reset, then the PE 407 MUST generate IGMP Leave for that (*,G) toward its local 408 interface (if any) attached to the multicast router for that 409 multicast group. It should be noted that the received EVPN route 410 MUST at least have one version flag set. If all version flags 411 are reset, it is an error because the PE should have received an 412 EVPN route withdraw for the last version flag. Error MUST be 413 considered as a BGP error and the PE MUST apply the "treat-as- 414 withdraw" procedure of [RFC7606]. 416 2. When a PE receives an EVPN SMET route withdraw, it removes the 417 remote PE from its OIF list for that multicast group and if there 418 are no more OIF entries for that multicast group (either locally 419 or remotely), then the PE MUST stop responding to Membership 420 Queries from the locally attached router (if any). If there is a 421 source for that multicast group, the PE stops sending multicast 422 traffic for that source. 424 4.2. Proxy Querier 426 As mentioned in the previous sections, each PE MUST have proxy 427 querier functionality for the following reasons: 429 1. To enable the collection of EVPN PEs providing L2VPN service to 430 act as distributed multicast router with Anycast IP address for 431 all attached hosts in that subnet. 433 2. To enable suppression of IGMP Membership Reports and Membership 434 Queries over MPLS/IP core. 436 5. Operation 438 Consider the EVPN network of Figure-1, where there is an EVPN 439 instance configured across the PEs shown in this figure (namely PE1, 440 PE2, and PE3). Let's consider that this EVPN instance consists of a 441 single bridge domain (single subnet) with all the hosts, sources, and 442 the multicast router connected to this subnet. PE1 only has 443 hosts(host denoted by Hx) connected to it. PE2 has a mix of hosts 444 and a multicast source. PE3 has a mix of hosts, a multicast source 445 (source denoted by Sx), and a multicast router (router denoted by 446 Rx). Furthermore, let's consider that for (S1,G1), R1 is used as the 447 multicast router. The following subsections describe the IGMP proxy 448 operation in different PEs with regard to whether the locally 449 attached devices for that subnet are: 451 o only hosts 453 o mix of hosts and multicast source 455 o mix of hosts, multicast source, and multicast router 456 +--------------+ 457 | | 458 | | 459 +----+ | | +----+ 460 H1:(*,G1)v2 ---| | | | | |---- H6(*,G1)v2 461 H2:(*,G1)v2 ---| PE1| | IP/MPLS | | PE2|---- H7(S2,G2)v3 462 H3:(*,G1)v3 ---| | | Network | | |---- S2 463 H4:(S2,G2)v3 --| | | | | | 464 +----+ | | +----+ 465 | | 466 +----+ | | 467 H5:(S1,G1)v3 --| | | | 468 S1 ---| PE3| | | 469 R1 ---| | | | 470 +----+ | | 471 | | 472 +--------------+ 474 Figure 1: EVPN network 476 5.1. PE with only attached hosts for a given subnet 478 When PE1 receives an IGMPv2 Membership Report from H1, it does not 479 forward this Membership Report to any of its other ports (for this 480 subnet) because all these local ports are associated with the hosts. 481 PE1 sends an EVPN Multicast Group route corresponding to this 482 Membership Report for (*,G1) and setting v2 flag. This EVPN route is 483 received by PE2 and PE3 that are the members of the same BD (i.e., 484 same EVI in case of VLAN-based service or EVI,VLAN in case of VLAN- 485 aware bundle service). PE3 reconstructs the IGMPv2 Membership Report 486 from this EVPN BGP route and only sends it to the port(s) with 487 multicast routers attached to it (for that subnet). In this example, 488 PE3 sends the reconstructed IGMPv2 Membership Report for (*,G1) only 489 to R1. Furthermore, even though PE2 receives the EVPN BGP route, it 490 does not send it to any of its ports for that subnet; viz, ports 491 associated with H6 and H7. 493 When PE1 receives the second IGMPv2 Membership Report from H2 for the 494 same multicast group (*,G1), it only adds that port to its OIF list 495 but it doesn't send any EVPN BGP route because there is no change in 496 information. However, when it receives the IGMPv3 Membership Report 497 from H3 for the same (*,G1). Besides adding the corresponding port 498 to its OIF list, it re-advertises the previously sent EVPN SMET route 499 with the v3 and exclude flag set. 501 Finally when PE1 receives the IGMPv3 Membership Report from H4 for 502 (S2,G2), it advertises a new EVPN SMET route corresponding to it. 504 5.2. PE with a mix of attached hosts and multicast source 506 The main difference in this case is that when PE2 receives the IGMPv3 507 Membership Report from H7 for (S2,G2), it does advertise it in BGP to 508 support source move even though PE2 knows that S2 is attached to its 509 local AC. PE2 adds the port associated with H7 to its OIF list for 510 (S2,G2). The processing for IGMPv2 received from H6 is the same as 511 the IGMPv2 Membership Report described in previous section. 513 5.3. PE with a mix of attached hosts, a multicast source and a router 515 The main difference in this case relative to the previous two 516 sections is that IGMP v2/v3 Membership Report messages received 517 locally need to be sent to the port associated with router R1. 518 Furthermore, the Membership Reports received via BGP (SMET) need to 519 be passed to the R1 port but filtered for all other ports. 521 6. All-Active Multi-Homing 523 Because the LAG flow hashing algorithm used by the CE is unknown at 524 the PE, in an All-Active redundancy mode it must be assumed that the 525 CE can send a given IGMP message to any one of the multi-homed PEs, 526 either DF or non-DF; i.e., different IGMP Membership Request messages 527 can arrive at different PEs in the redundancy group and furthermore 528 their corresponding Leave messages can arrive at PEs that are 529 different from the ones that received the Membership Report. 530 Therefore, all PEs attached to a given ES must coordinate IGMP 531 Membership Request and Leave Group (x,G) state, where x may be either 532 '*' or a particular source S, for each BD on that ES. Each PE has a 533 local copy of that state and the EVPN signaling serves to synchronize 534 state across PEs. This allows the DF for that (ES,BD) to correctly 535 advertise or withdraw a Selective Multicast Ethernet Tag (SMET) route 536 for that (x,G) group in that BD when needed. All-Active multihoming 537 PEs for a given ES MUST support IGMP synchronization procedures 538 described in this section if they need to perform IGMP proxy for 539 hosts connected to that ES. 541 6.1. Local IGMP/MLD Membership Report Synchronization 543 When a PE, either DF or non-DF, receives on a given multihomed ES 544 operating in All-Active redundancy mode, an IGMP Membership Report 545 for (x,G), it determines the BD to which the IGMP Membership Report 546 belongs. If the PE doesn't already have local IGMP Membership 547 Request (x,G) state for that BD on that ES, it MUST instantiate local 548 IGMP Membership Request (x,G) state and MUST advertise a BGP IGMP 549 Membership Report Synch route for that (ES,BD). Local IGMP 550 Membership Request (x,G) state refers to IGMP Membership Request 551 (x,G) state that is created as a result of processing an IGMP 552 Membership Report for (x,G). 554 The IGMP Membership Report Synch route MUST carry the ES-Import RT 555 for the ES on which the IGMP Membership Report was received. Thus it 556 MUST only be imported by the PEs attached to that ES and not any 557 other PEs. 559 When a PE, either DF or non-DF, receives an IGMP Membership Report 560 Synch route it installs that route and if it doesn't already have 561 IGMP Membership Request (x,G) state for that (ES,BD), it MUST 562 instantiate that IGMP Membership Request (x,G) state - i.e., IGMP 563 Membership Request (x,G) state is the union of the local IGMP 564 Membership Report (x,G) state and the installed IGMP Membership 565 Report Synch route. If the DF did not already advertise (originate) 566 a SMET route for that (x,G) group in that BD, it MUST do so now. 568 When a PE, either DF or non-DF, deletes its local IGMP Membership 569 Request (x,G) state for that (ES,BD), it MUST withdraw its BGP IGMP 570 Membership Report Synch route for that (ES,BD). 572 When a PE, either DF or non-DF, receives the withdrawal of an IGMP 573 Membership Report Synch route from another PE it MUST remove that 574 route. When a PE has no local IGMP Membership Request (x,G) state 575 and it has no installed IGMP Membership Report Synch routes, it MUST 576 remove IGMP Membership Request (x,G) state for that (ES,BD). If the 577 DF no longer has IGMP Membership Request (x,G) state for that BD on 578 any ES for which it is DF, it MUST withdraw its SMET route for that 579 (x,G) group in that BD. 581 In other words, a PE advertises an SMET route for that (x,G) group in 582 that BD when it has IGMP Membership Request (x,G) state in that BD on 583 at least one ES for which it is DF and it withdraws that SMET route 584 when it does not have IGMP Membership Request (x,G) state in that BD 585 on any ES for which it is DF. 587 6.2. Local IGMP/MLD Leave Group Synchronization 589 When a PE, either DF or non-DF, receives, on a given multihomed ES 590 operating in All-Active redundancy mode, an IGMP Leave Group message 591 for (x,G) from the attached CE, it determines the BD to which the 592 IGMPv2 Leave Group belongs. Regardless of whether it has IGMP 593 Membership Request (x,G) state for that (ES,BD), it initiates the 594 (x,G) leave group synchronization procedure, which consists of the 595 following steps: 597 1. It computes the Maximum Response Time, which is the duration of 598 (x,G) leave group synchronization procedure. This is the product 599 of two locally configured values, Last Member Query Count and 600 Last Member Query Interval (described in Section 3 of [RFC2236]), 601 plus a delta corresponding to the time it takes for a BGP 602 advertisement to propagate between the PEs attached to the 603 multihomed ES (delta is a consistently configured value on all 604 PEs attached to the multihomed ES). 606 2. It starts the Maximum Response Time timer. Note that the receipt 607 of subsequent IGMP Leave Group messages or BGP Leave Synch routes 608 for (x,G) do not change the value of a currently running Maximum 609 Response Time timer and are ignored by the PE. 611 3. It initiates the Last Member Query procedure described in 612 Section 3 of [RFC2236]; viz, it sends a number of Group-Specific 613 Query (x,G) messages (Last Member Query Count) at a fixed 614 interval (Last Member Query Interval) to the attached CE. 616 4. It advertises an IGMP Leave Synch route for that that (ES,BD). 617 This route notifies the other multihomed PEs attached to the 618 given multihomed ES that it has initiated an (x,G) leave group 619 synchronization procedure; i.e., it carries the ES-Import RT for 620 the ES on which the IGMP Leave Group was received. It also 621 contains the Maximum Response Time. 623 5. When the Maximum Response Timer expires, the PE that has 624 advertised the IGMP Leave Synch route withdraws it. 626 6.2.1. Remote Leave Group Synchronization 628 When a PE, either DF or non-DF, receives an IGMP Leave Synch route it 629 installs that route and it starts a timer for (x,G) on the specified 630 (ES,BD) whose value is set to the Maximum Response Time in the 631 received IGMP Leave Synch route. Note that the receipt of subsequent 632 IGMPv2 Leave Group messages or BGP Leave Synch routes for (x,G) do 633 not change the value of a currently running Maximum Response Time 634 timer and are ignored by the PE. 636 6.2.2. Common Leave Group Synchronization 638 If a PE attached to the multihomed ES receives an IGMP Membership 639 Report for (x,G) before the Maximum Response Time timer expires, it 640 advertises a BGP IGMP Membership Report Synch route for that (ES,BD). 641 If it doesn't already have local IGMP Membership Request (x,G) state 642 for that (ES,BD), it instantiates local IGMP Membership Request (x,G) 643 state. If the DF is not currently advertising (originating) a SMET 644 route for that (x,G) group in that BD, it does so now. 646 If a PE attached to the multihomed ES receives an IGMP Membership 647 Report Synch route for (x,G) before the Maximum Response Time timer 648 expires, it installs that route and if it doesn't already have IGMP 649 Membership Request (x,G) state for that BD on that ES, it 650 instantiates that IGMP Membership Request (x,G) state. If the DF has 651 not already advertised (originated) a SMET route for that (x,G) group 652 in that BD, it does so now. 654 When the Maximum Response Timer expires a PE that has advertised an 655 IGMP Leave Synch route, withdraws it. Any PE attached to the 656 multihomed ES, that started the Maximum Response Time and has no 657 local IGMP Membership Request (x,G) state and no installed IGMP 658 Membership Report Synch routes, it removes IGMP Membership Request 659 (x,G) state for that (ES,BD). If the DF no longer has IGMP 660 Membership Request (x,G) state for that BD on any ES for which it is 661 DF, it withdraws its SMET route for that (x,G) group in that BD. 663 6.3. Mass Withdraw of Multicast Membership Report Sync route in case of 664 failure 666 A PE which has received an IGMP Membership Request would have synced 667 the IGMP Membership Report by the procedure defined in section 6.1. 668 If a PE with local Membership Report state goes down or the PE to CE 669 link goes down, it would lead to a mass withdraw of multicast routes. 670 Remote PEs (PEs where these routes were remote IGMP Membership 671 Reports) SHOULD NOT remove the state immediately; instead General 672 Query SHOULD be generated to refresh the states. There are several 673 ways to detect failure at a peer, e.g. using IGP next hop tracking or 674 ES route withdraw. 676 7. Single-Active Multi-Homing 678 Note that to facilitate state synchronization after failover, the PEs 679 attached to a multihomed ES operating in Single-Active redundancy 680 mode SHOULD also coordinate IGMP Membership Report (x,G) state. In 681 this case all IGMP Membership Report messages are received by the DF 682 and distributed to the non-DF PEs using the procedures described 683 above. 685 8. Selective Multicast Procedures for IR tunnels 687 If an ingress PE uses ingress replication, then for a given (x,G) 688 group in a given BD: 690 1. It sends (x,G) traffic to the set of PEs not supporting IGMP or 691 MLD Proxy. This set consists of any PE that has advertised an 692 IMET route for the BD without a Multicast Flags extended 693 community or with a Multicast Flags extended community in which 694 neither the IGMP Proxy support nor the MLD Proxy support flags 695 are set. 697 2. It sends (x,G) traffic to the set of PEs supporting IGMP or MLD 698 Proxy and having listeners for that (x,G) group in that BD. This 699 set consists of any PE that has advertised an IMET route for the 700 BD with a Multicast Flags extended community in which the IGMP 701 Proxy support and/or the MLD Proxy support flags are set and that 702 has advertised a SMET route for that (x,G) group in that BD. 704 9. BGP Encoding 706 This document defines three new BGP EVPN routes to carry IGMP 707 Membership Reports. The route types are known as: 709 + 6 - Selective Multicast Ethernet Tag Route 711 + 7 - Multicast Membership Report Synch Route 713 + 8 - Multicast Leave Synch Route 715 The detailed encoding and procedures for these route types are 716 described in subsequent sections. 718 9.1. Selective Multicast Ethernet Tag Route 720 A Selective Multicast Ethernet Tag route type specific EVPN NLRI 721 consists of the following: 723 +---------------------------------------+ 724 | RD (8 octets) | 725 +---------------------------------------+ 726 | Ethernet Tag ID (4 octets) | 727 +---------------------------------------+ 728 | Multicast Source Length (1 octet) | 729 +---------------------------------------+ 730 | Multicast Source Address (variable) | 731 +---------------------------------------+ 732 | Multicast Group Length (1 octet) | 733 +---------------------------------------+ 734 | Multicast Group Address (Variable) | 735 +---------------------------------------+ 736 | Originator Router Length (1 octet) | 737 +---------------------------------------+ 738 | Originator Router Address (variable) | 739 +---------------------------------------+ 740 | Flags (1 octet) | 741 +---------------------------------------+ 743 For the purpose of BGP route key processing, all the fields are 744 considered to be part of the prefix in the NLRI except for the one- 745 octet flag field. The Flags fields are defined as follows: 747 0 1 2 3 4 5 6 7 748 +--+--+--+--+--+--+--+--+ 749 | reserved |IE|v3|v2|v1| 750 +--+--+--+--+--+--+--+--+ 752 o The least significant bit, bit 7 indicates support for IGMP 753 version 1. Since IGMP V1 is being deprecated sender MUST set it 754 as 0 for IGMP and receiver MUST ignore it. 756 o The second least significant bit, bit 6 indicates support for IGMP 757 version 2. 759 o The third least significant bit, bit 5 indicates support for IGMP 760 version 3. 762 o The fourth least significant bit, bit 4 indicates whether the 763 (S,G) information carried within the route-type is of an Include 764 Group type (bit value 0) or an Exclude Group type (bit value 1). 765 The Exclude Group type bit MUST be ignored if bit 5 is not set. 767 o This EVPN route type is used to carry tenant IGMP multicast group 768 information. The flag field assists in distributing IGMP 769 Membership Report of a given host for a given multicast route. 770 The version bits help associate IGMP version of receivers 771 participating within the EVPN domain. 773 o The include/exclude (IE) bit helps in creating filters for a given 774 multicast route. 776 o If route is used for IPv6 (MLD) then bit 7 indicates support for 777 MLD version 1. The second least significant bit, bit 6 indicates 778 support for MLD version 2. Since there is no MLD version 3, in 779 case of IPv6 route third least significant bit MUST be 0. In case 780 of IPv6 routes, the fourth least significant bit MUST be ignored 781 if bit 6 is not set. 783 o Reserved bits MUST be set to 0 by sender. And receiver MUST 784 ignore the Reserved bits. 786 9.1.1. Constructing the Selective Multicast Ethernet Tag route 788 This section describes the procedures used to construct the Selective 789 Multicast Ethernet Tag (SMET) route. 791 The Route Distinguisher (RD) SHOULD be a Type 1 RD [RFC4364]. The 792 value field comprises an IP address of the PE (typically, the 793 loopback address) followed by a number unique to the PE. 795 The Ethernet Tag ID MUST be set as procedure defined in [RFC7432]. 797 The Multicast Source Length MUST be set to length of the multicast 798 Source address in bits. If the Multicast Source Address field 799 contains an IPv4 address, then the value of the Multicast Source 800 Length field is 32. If the Multicast Source Address field contains 801 an IPv6 address, then the value of the Multicast Source Length field 802 is 128. In case of a (*,G) Membership Report, the Multicast Source 803 Length is set to 0. 805 The Multicast Source Address is the source IP address from the IGMP 806 Membership Report. In case of a (*,G), this field is not used. 808 The Multicast Group Length MUST be set to length of multicast group 809 address in bits. If the Multicast Group Address field contains an 810 IPv4 address, then the value of the Multicast Group Length field is 811 32. If the Multicast Group Address field contains an IPv6 address, 812 then the value of the Multicast Group Length field is 128. 814 The Multicast Group Address is the Group address from the IGMP or MLD 815 Membership Report. 817 The Originator Router Length is the length of the Originator Router 818 Address in bits. 820 The Originator Router Address is the IP address of router originating 821 this route. The SMET Originator Router IP address MUST match that of 822 the IMET (or S-PMSI AD) route originated for the same EVI by the same 823 downstream PE. 825 The Flags field indicates the version of IGMP protocol from which the 826 Membership Report was received. It also indicates whether the 827 multicast group had the INCLUDE or EXCLUDE bit set. 829 Reserved bits MUST be set to 0. They can be defined in future by 830 other document. 832 IGMP is used to receive group membership information from hosts by 833 TORs. Upon receiving the hosts expression of interest of a 834 particular group membership, this information is then forwarded using 835 SMET route. The NLRI also keeps track of receiver's IGMP protocol 836 version and any source filtering for a given group membership. All 837 EVPN SMET routes are announced with per- EVI Route Target extended 838 communities. 840 9.1.2. Reconstructing IGMP / MLD Membership Reports from Selective 841 Multicast Route 843 This section describes the procedures used to reconstruct IGMP / MLD 844 Membership Reports from SMET route. 846 o If multicast group length is 32, route would be translated to IGMP 847 membership request. If multicast group length is 128, route would 848 be translated to MLD membership request. 850 o Multicast group address field would be translated to IGMP / MLD 851 group address. 853 o If Multicast source length is set to zero it would be translated 854 to any source (*). If multicast source length is non zero, 855 Multicast source address field would be translated to IGMP / MLD 856 source address. 858 o If flag bit 7 is set, it translates Membership report to be IGMP 859 V1 or MLD V1. 861 o If flag bit 6 is set, it translates Membership report to be IGMP 862 V2 or MLD V2. 864 o Flag bit 5 is only valid for IGMP Membership report and if it is 865 set, it translates to IGMP V3 report. 867 o If IE flag is set, it translate to IGMP / MLD Exclude mode 868 membership report. If IE flag is not set (zero), it translates to 869 Include mode membership report. 871 9.1.3. Default Selective Multicast Route 873 If there is multicast router connected behind the EVPN domain, the PE 874 MAY originate a default SMET (*,*) to get all multicast traffic in 875 domain. 877 +--------------+ 878 | | 879 | | 880 | | +----+ 881 | | | |---- H1(*,G1)v2 882 | IP/MPLS | | PE1|---- H2(S2,G2)v3 883 | Network | | |---- S2 884 | | | | 885 | | +----+ 886 | | 887 +----+ | | 888 +----+ | | | | 889 | | S1 ---| PE2| | | 890 |PIM |----R1 ---| | | | 891 |ASM | +----+ | | 892 | | | | 893 +----+ +--------------+ 895 Figure 2: Multicast Router behind EVPN domain 897 Consider the EVPN network of Figure-2, where there is an EVPN 898 instance configured across the PEs. Let's consider that PE2 is 899 connected to multicast router R1 and there is a network running PIM 900 ASM behind R1. If there are receivers behind the PIM ASM network the 901 PIM Join would be forwarded to the PIM RP (Rendezvous Point). If 902 receivers behind PIM ASM network are interested in a multicast flow 903 originated by multicast source S2 (behind PE1), it is necessary for 904 PE2 to receive multicast traffic. In this case PE2 MUST originate a 905 (*,*) SMET route to receive all of the multicast traffic in the EVPN 906 domain. To generate Wildcards (*,*) routes, the procedure from 907 [RFC6625] MUST be used. 909 9.2. Multicast Membership Report Synch Route 911 This EVPN route type is used to coordinate IGMP Membership Report 912 (x,G) state for a given BD between the PEs attached to a given ES 913 operating in All- Active (or Single-Active) redundancy mode and it 914 consists of following: 916 +--------------------------------------------------+ 917 | RD (8 octets) | 918 +--------------------------------------------------+ 919 | Ethernet Segment Identifier (10 octets) | 920 +--------------------------------------------------+ 921 | Ethernet Tag ID (4 octets) | 922 +--------------------------------------------------+ 923 | Multicast Source Length (1 octet) | 924 +--------------------------------------------------+ 925 | Multicast Source Address (variable) | 926 +--------------------------------------------------+ 927 | Multicast Group Length (1 octet) | 928 +--------------------------------------------------+ 929 | Multicast Group Address (Variable) | 930 +--------------------------------------------------+ 931 | Originator Router Length (1 octet) | 932 +--------------------------------------------------+ 933 | Originator Router Address (variable) | 934 +--------------------------------------------------+ 935 | Flags (1 octet) | 936 +--------------------------------------------------+ 938 For the purpose of BGP route key processing, all the fields are 939 considered to be part of the prefix in the NLRI except for the one- 940 octet Flags field, whose fields are defined as follows: 942 0 1 2 3 4 5 6 7 943 +--+--+--+--+--+--+--+--+ 944 | reserved |IE|v3|v2|v1| 945 +--+--+--+--+--+--+--+--+ 947 o The least significant bit, bit 7 indicates support for IGMP 948 version 1. 950 o The second least significant bit, bit 6 indicates support for IGMP 951 version 2. 953 o The third least significant bit, bit 5 indicates support for IGMP 954 version 3. 956 o The fourth least significant bit, bit 4 indicates whether the (S, 957 G) information carried within the route-type is of Include Group 958 type (bit value 0) or an Exclude Group type (bit value 1). The 959 Exclude Group type bit MUST be ignored if bit 5 is not set. 961 o Reserved bits MUST be set to 0. 963 The Flags field assists in distributing IGMP Membership Report of a 964 given host for a given multicast route. The version bits help 965 associate IGMP version of receivers participating within the EVPN 966 domain. The include/exclude bit helps in creating filters for a 967 given multicast route. 969 If route is being prepared for IPv6 (MLD) then bit 7 indicates 970 support for MLD version 1. The second least significant bit, bit 6 971 indicates support for MLD version 2. Since there is no MLD version 972 3, in case of IPv6 route third least significant bit MUST be 0. In 973 case of IPv6 route, the fourth least significant bit MUST be ignored 974 if bit 6 is not set. 976 9.2.1. Constructing the Multicast Membership Report Synch Route 978 This section describes the procedures used to construct the IGMP 979 Membership Report Synch route. Support for these route types is 980 optional. If a PE does not support this route, then it MUST NOT 981 indicate that it supports 'IGMP proxy' in the Multicast Flag extended 982 community for the EVIs corresponding to its multi-homed Ethernet 983 Segments (ESs). 985 An IGMP Membership Report Synch route MUST carry exactly one ES- 986 Import Route Target extended community, the one that corresponds to 987 the ES on which the IGMP Membership Report was received. It MUST 988 also carry exactly one EVI-RT EC, the one that corresponds to the EVI 989 on which the IGMP Membership Report was received. See Section 9.5 990 for details on how to encode and construct the EVI-RT EC. 992 The Route Distinguisher (RD) SHOULD be a Type 1 RD [RFC4364]. The 993 value field comprises an IP address of the PE (typically, the 994 loopback address) followed by a number unique to the PE. 996 The Ethernet Segment Identifier (ESI) MUST be set to the 10-octet 997 value defined for the ES. 999 The Ethernet Tag ID MUST be set as per procedure defined in 1000 [RFC7432]. 1002 The Multicast Source length MUST be set to length of Multicast Source 1003 address in bits. If the Multicast Source field contains an IPv4 1004 address, then the value of the Multicast Source Length field is 32. 1005 If the Multicast Source field contains an IPv6 address, then the 1006 value of the Multicast Source Length field is 128. In case of a 1007 (*,G) Membership Report, the Multicast Source Length is set to 0. 1009 The Multicast Source is the Source IP address of the IGMP Membership 1010 Report. In case of a (*,G) Membership Report, this field does not 1011 exist. 1013 The Multicast Group length MUST be set to length of multicast group 1014 address in bits. If the Multicast Group field contains an IPv4 1015 address, then the value of the Multicast Group Length field is 32. 1016 If the Multicast Group field contains an IPv6 address, then the value 1017 of the Multicast Group Length field is 128. 1019 The Multicast Group is the Group address of the IGMP Membership 1020 Report. 1022 The Originator Router Length is the length of the Originator Router 1023 address in bits. 1025 The Originator Router Address is the IP address of Router Originating 1026 the prefix. 1028 The Flags field indicates the version of IGMP protocol from which the 1029 Membership Report was received. It also indicates whether the 1030 multicast group had INCLUDE or EXCLUDE bit set. 1032 Reserved bits MUST be set to 0. 1034 9.2.2. Reconstructing IGMP / MLD Membership Reports from Multicast 1035 Membership Report Sync Route 1037 This section describes the procedures used to reconstruct IGMP / MLD 1038 Membership Reports from Multicast Membership Report Sync route. 1040 o If multicast group length is 32, route would be translated to IGMP 1041 membership request. If multicast group length is 128, route would 1042 be translated to MLD membership request. 1044 o Multicast group address field would be translated to IGMP / MLD 1045 group address. 1047 o If Multicast source length is set to zero it would be translated 1048 to any source (*). If multicast source length is non zero, 1049 Multicast source address field would be translated to IGMP / MLD 1050 source address. 1052 o If flag bit 7 is set, it translates Membership report to be IGMP 1053 V1 or MLD V1. 1055 o If flag bit 6 is set, it translates Membership report to be IGMP 1056 V2 or MLD V2. 1058 o Flag bit 5 is only valid for IGMP Membership report and if it is 1059 set, it translates to IGMP V3 report. 1061 o If IE flag is set, it translate to IGMP / MLD Exclude mode 1062 membership report. If IE flag is not set (zero), it translates to 1063 Include mode membership report. 1065 9.3. Multicast Leave Synch Route 1067 This EVPN route type is used to coordinate IGMP Leave Group (x,G) 1068 state for a given BD between the PEs attached to a given ES operating 1069 in All-Active (or Single-Active) redundancy mode and it consists of 1070 following: 1072 +--------------------------------------------------+ 1073 | RD (8 octets) | 1074 +--------------------------------------------------+ 1075 | Ethernet Segment Identifier (10 octets) | 1076 +--------------------------------------------------+ 1077 | Ethernet Tag ID (4 octets) | 1078 +--------------------------------------------------+ 1079 | Multicast Source Length (1 octet) | 1080 +--------------------------------------------------+ 1081 | Multicast Source Address (variable) | 1082 +--------------------------------------------------+ 1083 | Multicast Group Length (1 octet) | 1084 +--------------------------------------------------+ 1085 | Multicast Group Address (Variable) | 1086 +--------------------------------------------------+ 1087 | Originator Router Length (1 octet) | 1088 +--------------------------------------------------+ 1089 | Originator Router Address (variable) | 1090 +--------------------------------------------------+ 1091 | Reserved (4 octet) | 1092 +--------------------------------------------------+ 1093 | Maximum Response Time (1 octet) | 1094 +--------------------------------------------------+ 1095 | Flags (1 octet) | 1096 +--------------------------------------------------+ 1098 For the purpose of BGP route key processing, all the fields are 1099 considered to be part of the prefix in the NLRI except for the 1100 Reserved, Maximum Response Time and the one-octet Flags field, whose 1101 fields are defined as follows: 1103 0 1 2 3 4 5 6 7 1104 +--+--+--+--+--+--+--+--+ 1105 | reserved |IE|v3|v2|v1| 1106 +--+--+--+--+--+--+--+--+ 1108 o The least significant bit, bit 7 indicates support for IGMP 1109 version 1. 1111 o The second least significant bit, bit 6 indicates support for IGMP 1112 version 2. 1114 o The third least significant bit, bit 5 indicates support for IGMP 1115 version 3. 1117 o The fourth least significant bit, bit 4 indicates whether the (S, 1118 G) information carried within the route-type is of Include Group 1119 type (bit value 0) or an Exclude Group type (bit value 1). The 1120 Exclude Group type bit MUST be ignored if bit 5 is not set. 1122 o Reserved bits MUST be set to 0. They can be defined in future by 1123 other document. 1125 The Flags field assists in distributing IGMP Membership Report of a 1126 given host for a given multicast route. The version bits help 1127 associate IGMP version of receivers participating within the EVPN 1128 domain. The include/exclude bit helps in creating filters for a 1129 given multicast route. 1131 If route is being prepared for IPv6 (MLD) then bit 7 indicates 1132 support for MLD version 1. The second least significant bit, bit 6 1133 indicates support for MLD version 2. Since there is no MLD version 1134 3, in case of IPv6 route third least significant bit MUST be 0. In 1135 case of IPv6 route, the fourth least significant bit MUST be ignored 1136 if bit 6 is not set. 1138 Reserved bits in flag MUST be set to 0. They can be defined in 1139 future by other document. 1141 9.3.1. Constructing the Multicast Leave Synch Route 1143 This section describes the procedures used to construct the IGMP 1144 Leave Synch route. Support for these route types is optional. If a 1145 PE does not support this route, then it MUST NOT indicate that it 1146 supports 'IGMP proxy' in Multicast Flag extended community for the 1147 EVIs corresponding to its multi-homed Ethernet Segments. 1149 An IGMP Leave Synch route MUST carry exactly one ES-Import Route 1150 Target extended community, the one that corresponds to the ES on 1151 which the IGMP Leave was received. It MUST also carry exactly one 1152 EVI-RT EC, the one that corresponds to the EVI on which the IGMP 1153 Leave was received. See Section 9.5 for details on how to form the 1154 EVI-RT EC. 1156 The Route Distinguisher (RD) SHOULD be a Type 1 RD [RFC4364]. The 1157 value field comprises an IP address of the PE (typically, the 1158 loopback address) followed by a number unique to the PE. 1160 The Ethernet Segment Identifier (ESI) MUST be set to the 10-octet 1161 value defined for the ES. 1163 The Ethernet Tag ID MUST be set as per procedure defined in 1164 [RFC7432]. 1166 The Multicast Source length MUST be set to length of multicast source 1167 address in bits. If the Multicast Source field contains an IPv4 1168 address, then the value of the Multicast Source Length field is 32. 1169 If the Multicast Source field contains an IPv6 address, then the 1170 value of the Multicast Source Length field is 128. In case of a 1171 (*,G) Membership Report, the Multicast Source Length is set to 0. 1173 The Multicast Source is the Source IP address of the IGMP Membership 1174 Report. In case of a (*,G) Membership Report, this field does not 1175 exist. 1177 The Multicast Group length MUST be set to length of multicast group 1178 address in bits. If the Multicast Group field contains an IPv4 1179 address, then the value of the Multicast Group Length field is 32. 1180 If the Multicast Group field contains an IPv6 address, then the value 1181 of the Multicast Group Length field is 128. 1183 The Multicast Group is the Group address of the IGMP Membership 1184 Report. 1186 The Originator Router Length is the length of the Originator Router 1187 address in bits. 1189 The Originator Router Address is the IP address of Router Originating 1190 the prefix. 1192 Reserved field is not part of the route key. The originator MUST set 1193 the reserved field to Zero , the receiver SHOULD ignore it and if it 1194 needs to be propagated, it MUST propagate it unchanged 1196 Maximum Response Time is value to be used while sending query as 1197 defined in [RFC2236] 1199 The Flags field indicates the version of IGMP protocol from which the 1200 Membership Report was received. It also indicates whether the 1201 multicast group had INCLUDE or EXCLUDE bit set. 1203 9.3.2. Reconstructing IGMP / MLD Leave from Multicast Leave Sync Route 1205 This section describes the procedures used to reconstruct IGMP / MLD 1206 Leave from Multicast Leave Sync route. 1208 o If multicast group length is 32, route would be translated to IGMP 1209 Leave. If multicast group length is 128, route would be 1210 translated to MLD Leave. 1212 o Multicast group address field would be translated to IGMP / MLD 1213 group address. 1215 o If Multicast source length is set to zero it would be translated 1216 to any source (*). If multicast source length is non zero, 1217 Multicast source address field would be translated to IGMP / MLD 1218 source address. 1220 o If flag bit 7 is set, it translates Membership report to be IGMP 1221 V1 or MLD V1. 1223 o If flag bit 6 is set, it translates Membership report to be IGMP 1224 V2 or MLD V2. 1226 o Flag bit 5 is only valid for IGMP Membership report and if it is 1227 set, it translates to IGMP V3 report. 1229 o If IE flag is set, it translate to IGMP / MLD Exclude mode Leave. 1230 If IE flag is not set (zero), it translates to Include mode Leave. 1232 o 1234 9.4. Multicast Flags Extended Community 1236 The 'Multicast Flags' extended community is a new EVPN extended 1237 community. EVPN extended communities are transitive extended 1238 communities with a Type field value of 6. IANA will assign a Sub- 1239 Type from the 'EVPN Extended Community Sub-Types' registry. 1241 A PE that supports IGMP and/or MLD Proxy on a given BD MUST attach 1242 this extended community to the IMET route it advertises advertises 1243 for that BD and it MUST set the IGMP and/or MLD Proxy Support flags 1244 to 1. Note that an [RFC7432] compliant PE will not advertise this 1245 extended community so its absence indicates that the advertising PE 1246 does not support either IGMP or MLD Proxy. 1248 The advertisement of this extended community enables more efficient 1249 multicast tunnel setup from the source PE specially for ingress 1250 replication - i.e., if an egress PE supports IGMP proxy but doesn't 1251 have any interest in a given (x,G), it advertises its IGMP proxy 1252 capability using this extended community but it does not advertise 1253 any SMET route for that (x,G). When the source PE (ingress PE) 1254 receives such advertisements from the egress PE, it does not 1255 replicate the multicast traffic to that egress PE; however, it does 1256 replicate the multicast traffic to the egress PEs that don't 1257 advertise such capability even if they don't have any interests in 1258 that (x,G). 1260 A Multicast Flags extended community is encoded as an 8-octet value, 1261 as follows: 1263 0 1 2 3 1264 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 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | Type=0x06 |Sub-Type=0x09 | Flags (2 Octets) |M|I| 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | Reserved=0 | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 The low-order (lease significant) two bits are defined as the "IGMP 1272 Proxy Support and MLD Proxy Support" bit. The absence of this 1273 extended community also means that the PE does not support IGMP 1274 proxy. where: 1276 o Type is 0x06 as registered with IANA for EVPN Extended 1277 Communities. 1279 o Sub-Type : 0x09 1281 o Flags are two Octets value. 1283 * Bit 15 (shown as I) defines IGMP Proxy Support. Value of 1 for 1284 bit 15 means that PE supports IGMP Proxy. Value of 0 for bit 1285 15 means that PE does not supports IGMP Proxy. 1287 * Bit 14 (shown as M) defines MLD Proxy Support. Value of 1 for 1288 bit 14 means that PE supports MLD Proxy. Value of 0 for bit 14 1289 means that PE does not support MLD proxy. 1291 * Bit 0 to 13 are reserved for future. Sender MUST set it 0 and 1292 receiver MUST ignore it. 1294 o Reserved bits are set to 0. Sender MUST set it to 0 and receiver 1295 MUST ignore it. 1297 If a router does not support this specification, it MUST NOT add 1298 Multicast Flags Extended Community in BGP route. A router receiving 1299 BGP update, if M and I both flag are zero (0), the router MUST treat 1300 this Update as malformed. Receiver of such update MUST ignore the 1301 extended community. 1303 9.5. EVI-RT Extended Community 1305 In EVPN, every EVI is associated with one or more Route Targets 1306 (RTs). These Route Targets serve two functions: 1308 1. Distribution control: RTs control the distribution of the routes. 1309 If a route carries the RT associated with a particular EVI, it 1310 will be distributed to all the PEs on which that EVI exists. 1312 2. EVI identification: Once a route has been received by a 1313 particular PE, the RT is used to identify the EVI to which it 1314 applies. 1316 An IGMP Membership Report Synch or IGMP Leave Synch route is 1317 associated with a particular combination of ES and EVI. These routes 1318 need to be distributed only to PEs that are attached to the 1319 associated ES. Therefore these routes carry the ES-Import RT for 1320 that ES. 1322 Since an IGMP Membership Report Synch or IGMP Leave Synch route does 1323 not need to be distributed to all the PEs on which the associated EVI 1324 exists, these routes cannot carry the RT associated with that EVI. 1325 Therefore, when such a route arrives at a particular PE, the route's 1326 RTs cannot be used to identify the EVI to which the route applies. 1327 Some other means of associating the route with an EVI must be used. 1329 This document specifies four new Extended Communities (EC) that can 1330 be used to identify the EVI with which a route is associated, but 1331 which do not have any effect on the distribution of the route. These 1332 new ECs are known as the "Type 0 EVI-RT EC", the "Type 1 EVI-RT EC", 1333 the "Type 2 EVI-RT EC", and the "Type 3 EVI-RT EC". 1335 1. A Type 0 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xA. 1337 2. A Type 1 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xB. 1339 3. A Type 2 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xC. 1341 4. A Type 3 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xD 1343 Each IGMP Membership Report Synch or IGMP Leave Synch route MUST 1344 carry exactly one EVI-RT EC. The EVI-RT EC carried by a particular 1345 route is constructed as follows. Each such route is the result of 1346 having received an IGMP Membership Report or an IGMP Leave message 1347 from a particular BD. The route is said to be associated with that 1348 BD. For each BD, there is a corresponding RT that is used to ensure 1349 that routes "about" that BD are distributed to all PEs attached to 1350 that BD. So suppose a given IGMP Membership Report Synch or Leave 1351 Synch route is associated with a given BD, say BD1, and suppose that 1352 the corresponding RT for BD1 is RT1. Then: 1354 o 0. If RT1 is a Transitive Two-Octet AS-specific EC, then the EVI- 1355 RT EC carried by the route is a Type 0 EVI-RT EC. The value field 1356 of the Type 0 EVI-RT EC is identical to the value field of RT1. 1358 o 1. If RT1 is a Transitive IPv4-Address-specific EC, then the EVI- 1359 RT EC carried by the route is a Type 1 EVI-RT EC. The value field 1360 of the Type 1 EVI-RT EC is identical to the value field of RT1. 1362 o 2. If RT1 is a Transitive Four-Octet-specific EC, then the EVI-RT 1363 EC carried by the route is a Type 2 EVI-RT EC. The value field of 1364 the Type 2 EVI-RT EC is identical to the value field of RT1. 1366 o 3. If RT1 is a Transitive IPv6-Address-specific EC, then the EVI- 1367 RT EC carried by the route is a Type 3 EVI-RT EC. The value field 1368 of the Type 3 EVI-RT EC is identical to the value field of RT1. 1370 An IGMP Membership Report Synch or Leave Synch route MUST carry 1371 exactly one EVI-RT EC. 1373 Suppose a PE receives a particular IGMP Membership Report Synch or 1374 IGMP Leave Synch route, say R1, and suppose that R1 carries an ES- 1375 Import RT that is one of the PE's Import RTs. If R1 has no EVI-RT 1376 EC, or has more than one EVI-RT EC, the PE MUST apply the "treat-as- 1377 withdraw" procedure of [RFC7606]. 1379 Note that an EVI-RT EC is not a Route Target Extended Community, is 1380 not visible to the RT Constrain mechanism [RFC4684], and is not 1381 intended to influence the propagation of routes by BGP. 1383 1 2 3 1384 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 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 | Type=0x06 | Sub-Type=n | RT associated with EVI | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 | RT associated with the EVI (cont.) | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 Where the value of 'n' is 0x0A, 0x0B, 0x0C, or 0x0D corresponding to 1392 EVI-RT type 0, 1, 2, or 3 respectively. 1394 9.6. Rewriting of RT ECs and EVI-RT ECs by ASBRs 1396 There are certain situations in which an ES is attached to a set of 1397 PEs that are not all in the same AS, or not all operated by the same 1398 provider. In some such situations, the RT that corresponds to a 1399 particular EVI may be different in each AS. If a route is propagated 1400 from AS1 to AS2, an ASBR at the AS1/AS2 border may be provisioned 1401 with a policy that removes the RTs that are meaningful in AS1 and 1402 replaces them with the corresponding (i.e., RTs corresponding to the 1403 same EVIs) RTs that are meaningful in AS2. This is known as RT- 1404 rewriting. 1406 Note that if a given route's RTs are rewritten, and the route carries 1407 an EVI-RT EC, the EVI-RT EC needs to be rewritten as well. 1409 9.7. BGP Error Handling 1411 If a received BGP update contains Flags not in accordance with IGMP/ 1412 MLD version-X expectation, the PE MUST apply the "treat-as-withdraw" 1413 procedure as per [RFC7606] 1415 If a received BGP update is malformed such that BGP route keys cannot 1416 be extracted, then BGP update MUST be considered as invalid. 1417 Receiving PE MUST apply the "Session reset" procedure of [RFC7606]. 1419 10. IGMP Version 1 Membership Report 1421 This document does not provide any detail about IGMPv1 processing. 1422 Implementations are expected to only use IGMPv2 and above for IPv4 1423 and MLDv1 and above for IPv6. IGMPv1 routes are considered invalid 1424 and the PE MUST apply the "treat-as-withdraw" procedure as per 1425 [RFC7606]. 1427 11. Security Considerations 1429 This document describes a means to efficiently operate IGMP and MLD 1430 on a subnet constructed across multiple PODs or DCs via an EVPN 1431 solution. The security considerations for the operation of the 1432 underlying EVPN and BGP substrate are described in [RFC7432], and 1433 specific multicast considerations are outlined in [RFC6513] and 1434 [RFC6514]. The EVPN and associated IGMP proxy provides a single 1435 broadcast domain so the same security considerations of IGMPv2 1436 [RFC2236], [RFC3376], MLD [RFC2710], or MLDv2 [RFC3810] apply. 1438 12. IANA Considerations 1440 12.1. EVPN Extended Community Sub-Types Registrations 1442 IANA has allocated the following codepoints from the EVPN Extended 1443 Community Sub-Types sub-registry of the BGP Extended Communities 1444 registry. 1446 0x09 Multicast Flags Extended Community [this document] 1447 0x0A EVI-RT Type 0 [this document] 1448 0x0B EVI-RT Type 1 [this document] 1449 0x0C EVI-RT Type 2 [this document] 1451 IANA is requested to allocate a new codepoint from the EVPN Extended 1452 Community sub-types registry for the following. 1454 0x0D EVI-RT Type 3 [this document] 1456 12.2. EVPN Route Type Registration 1458 IANA has allocated the following EVPN route types from the EVPN Route 1459 Type registry. 1461 6 - Selective Multicast Ethernet Tag Route 1462 7 - Multicast Membership Report Synch Route 1463 8 - Multicast Leave Synch Route 1465 12.3. Multicast Flags Extended Community Registry 1467 The Multicast Flags Extended Community contains a 16-bit Flags field. 1468 The bits are numbered 0-15, from high-order to low-order. 1470 The registry should be initialized as follows: 1472 Bit Name Reference Change Controller 1473 ---- -------------- ------------- ------------------ 1474 0 - 13 Unassigned 1475 14 MLD Proxy Support This document. IETF 1476 15 IGMP Proxy Support This document IETF 1478 The registration policy should be "First Come First Served". 1480 13. Acknowledgement 1482 The authors would like to thank Stephane Litkowski, Jorge Rabadan, 1483 Anoop Ghanwani, Jeffrey Haas, Krishna Muddenahally Ananthamurthy, 1484 Swadesh Agrawal for reviewing and providing valuable comment. 1486 14. Contributors 1488 Derek Yeung 1490 Arrcus 1492 Email: derek@arrcus.com 1494 15. References 1496 15.1. Normative References 1498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1499 Requirement Levels", BCP 14, RFC 2119, 1500 DOI 10.17487/RFC2119, March 1997, 1501 . 1503 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 1504 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 1505 . 1507 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1508 Listener Discovery (MLD) for IPv6", RFC 2710, 1509 DOI 10.17487/RFC2710, October 1999, 1510 . 1512 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1513 Thyagarajan, "Internet Group Management Protocol, Version 1514 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 1515 . 1517 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1518 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1519 DOI 10.17487/RFC3810, June 2004, 1520 . 1522 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1523 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1524 2006, . 1526 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 1527 R., Patel, K., and J. Guichard, "Constrained Route 1528 Distribution for Border Gateway Protocol/MultiProtocol 1529 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 1530 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 1531 November 2006, . 1533 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 1534 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 1535 2012, . 1537 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1538 Encodings and Procedures for Multicast in MPLS/BGP IP 1539 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 1540 . 1542 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 1543 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 1544 RFC 6625, DOI 10.17487/RFC6625, May 2012, 1545 . 1547 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1548 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1549 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1550 2015, . 1552 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1553 Patel, "Revised Error Handling for BGP UPDATE Messages", 1554 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1555 . 1557 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1558 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1559 May 2017, . 1561 15.2. Informative References 1563 [I-D.ietf-bess-evpn-bum-procedure-updates] 1564 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 1565 Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- 1566 bess-evpn-bum-procedure-updates-14 (work in progress), 1567 November 2021. 1569 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 1570 "Considerations for Internet Group Management Protocol 1571 (IGMP) and Multicast Listener Discovery (MLD) Snooping 1572 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 1573 . 1575 Authors' Addresses 1576 Ali Sajassi 1577 Cisco Systems 1578 821 Alder Drive, 1579 MILPITAS, CALIFORNIA 95035 1580 UNITED STATES 1582 Email: sajassi@cisco.com 1584 Samir Thoria 1585 Cisco Systems 1586 821 Alder Drive, 1587 MILPITAS, CALIFORNIA 95035 1588 UNITED STATES 1590 Email: sthoria@cisco.com 1592 Mankamana Mishra 1593 Cisco Systems 1594 821 Alder Drive, 1595 MILPITAS, CALIFORNIA 95035 1596 UNITED STATES 1598 Email: mankamis@cisco.com 1600 Keyur PAtel 1601 Arrcus 1602 UNITED STATES 1604 Email: keyur@arrcus.com 1606 John Drake 1607 Juniper Networks 1609 Email: jdrake@juniper.net 1611 Wen Lin 1612 Juniper Networks 1614 Email: wlin@juniper.net