idnits 2.17.1 draft-ietf-bess-evpn-igmp-mld-proxy-02.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 3 instances of lines with control characters in the document. ** The abstract seems to contain references ([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 == Line 1084 has weird spacing: '... is one of ...' == Line 1112 has weird spacing: '...Is) RTs that ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This section describes the procedures used to construct the IGMP Join Synch route. Support for this route type is optional. If a PE does not support this route, then it MUST not indicate that it supports 'IGMP proxy' in Multicast Flag extended community for the EVIs corresponding to its multi-homed Ethernet Segments. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This section describes the procedures used to construct the IGMP Leave Synch route. Support for this route type is optional. If a PE does not support this route, then it MUST not indicate that it supports 'IGMP proxy' in Multicast Flag extended community for the EVIs corresponding to its multi-homed Ethernet Segments. -- The document date (June 24, 2018) is 2130 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) == Missing Reference: 'RFC 7432' is mentioned on line 107, but not defined == Missing Reference: 'RFC2119' is mentioned on line 166, but not defined == Missing Reference: 'RFC8174' is mentioned on line 166, but not defined == Missing Reference: 'ES' is mentioned on line 599, but not defined == Missing Reference: 'BD' is mentioned on line 599, but not defined == Missing Reference: 'RFC2236' is mentioned on line 551, but not defined == Missing Reference: 'RFC4364' is mentioned on line 933, but not defined == Missing Reference: 'RFC7606' is mentioned on line 1086, but not defined == Missing Reference: 'RFC4684' is mentioned on line 1089, but not defined == Unused Reference: 'KEYWORDS' is defined on line 1163, but no explicit reference was found in the text == Unused Reference: 'RFC4360' is defined on line 1166, but no explicit reference was found in the text == Unused Reference: 'ETREE-FMWK' is defined on line 1174, but no explicit reference was found in the text == Unused Reference: 'PBB-EVPN' is defined on line 1178, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-l2vpn-etree-frwk-03 == Outdated reference: A later version (-10) exists of draft-ietf-l2vpn-pbb-evpn-05 Summary: 2 errors (**), 0 flaws (~~), 21 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group Ali Sajassi 3 Internet-Draft Samir Thoria 4 Intended Status: Standards Track Cisco 5 Keyur Patel 6 Derek Yeung 7 Arrcus 8 John Drake 9 Wen Lin 10 Juniper 12 Expires: December 24, 2018 June 24, 2018 14 IGMP and MLD Proxy for EVPN 15 draft-ietf-bess-evpn-igmp-mld-proxy-02 17 Abstract 19 Ethernet Virtual Private Network (EVPN) solution [RFC 7432] is 20 becoming pervasive in data center (DC) applications for Network 21 Virtualization Overlay (NVO) and DC interconnect (DCI) services, and 22 in service provider (SP) applications for next generation virtual 23 private LAN services. 25 This draft describes how to support efficiently endpoints running 26 IGMP for the above services over an EVPN network by incorporating 27 IGMP proxy procedures on EVPN PEs. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as 37 Internet-Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/1id-abstracts.html 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 Copyright and License Notice 51 Copyright (c) 2018 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2 IGMP Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.1 Proxy Reporting . . . . . . . . . . . . . . . . . . . . . . 6 70 2.1.1 IGMP Membership Report Advertisement in BGP . . . . . . 6 71 2.1.1 IGMP Leave Group Advertisement in BGP . . . . . . . . . 8 72 2.2 Proxy Querier . . . . . . . . . . . . . . . . . . . . . . . 9 73 3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 3.1 PE with only attached hosts/VMs for a given subnet . . . . . 10 75 3.2 PE with mixed of attached hosts/VMs and multicast source . . 11 76 3.3 PE with mixed of attached hosts/VMs, multicast source and 77 router . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 4 All-Active Multi-Homing . . . . . . . . . . . . . . . . . . . . 11 79 4.1 Local IGMP Join Synchronization . . . . . . . . . . . . . . 12 80 4.2 Local IGMP Leave Group Synchronization . . . . . . . . . . . 13 81 4.2.1 Remote Leave Group Synchronization . . . . . . . . . . . 13 82 4.2.2 Common Leave Group Synchronization . . . . . . . . . . . 14 83 5 Single-Active Multi-Homing . . . . . . . . . . . . . . . . . . . 14 84 6 Selective Multicast Procedures for IR tunnels . . . . . . . . . 14 85 7 BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 7.1 Selective Multicast Ethernet Tag Route . . . . . . . . . . . 15 87 7.1.1 Constructing the Selective Multicast Ethernet Tag 88 route . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 7.2 IGMP Join Synch Route . . . . . . . . . . . . . . . . . . . 18 90 7.2.1 Constructing the IGMP Join Synch Route . . . . . . . . 19 92 7.3 IGMP Leave Synch Route . . . . . . . . . . . . . . . . . . . 20 93 7.3.1 Constructing the IGMP Leave Synch Route . . . . . . . . 22 94 7.4 Multicast Flags Extended Community . . . . . . . . . . . . . 23 95 7.5 EVI-RT Extended Community . . . . . . . . . . . . . . . . . 24 96 7.6 Rewriting of RT ECs and EVI-RT ECs by ASBRs . . . . . . . . 26 97 8 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 26 98 9 Security Considerations . . . . . . . . . . . . . . . . . . . . 26 99 10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 100 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 101 11.1 Normative References . . . . . . . . . . . . . . . . . . . 27 102 11.2 Informative References . . . . . . . . . . . . . . . . . . 27 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 105 1 Introduction 107 Ethernet Virtual Private Network (EVPN) solution [RFC 7432] is 108 becoming pervasive in data center (DC) applications for Network 109 Virtualization Overlay (NVO) and DC interconnect (DCI) services, and 110 in service provider (SP) applications for next generation virtual 111 private LAN services. 113 In DC applications, a POD can consist of a collection of servers 114 supported by several TOR and Spine switches. This collection of 115 servers and switches are self contained and may have their own 116 control protocol for intra-POD communication and orchestration. 117 However, EVPN is used as way of standard inter-POD communication for 118 both intra-DC and inter-DC. A subnet can span across multiple PODs 119 and DCs. EVPN provides robust multi-tenant solution with extensive 120 multi-homing capabilities to stretch a subnet (e.g., VLAN) across 121 multiple PODs and DCs. There can be many hosts/VMs (e.g., several 122 hundreds) attached to a subnet that is stretched across several PODs 123 and DCs. 125 These hosts/VMs express their interests in multicast groups on a 126 given subnet/VLAN by sending IGMP membership reports (Joins) for 127 their interested multicast group(s). Furthermore, an IGMP router 128 (e.g., IGMPv1) periodically sends membership queries to find out if 129 there are hosts on that subnet still interested in receiving 130 multicast traffic for that group. The IGMP/MLD Proxy solution 131 described in this draft has three objectives to accomplish: 133 1) Reduce flooding of IGMP messages: just like ARP/ND suppression 134 mechanism in EVPN to reduce the flooding of ARP messages over EVPN, 135 it is also desired to have a mechanism to reduce the flood of IGMP 136 messages (both Queries and Reports) in EVPN. 138 2) Distributed anycast multicast proxy: it is desired for the EVPN 139 network to act as a distributed anycast multicast router with respect 140 to IGMP/MLD proxy function for all the hosts attached to that 141 subnet. 143 3) Selective Multicast: to forward multicast traffic over EVPN 144 network such that it only gets forwarded to the PEs that have 145 interest in the multicast group(s) - i.e., multicast traffic will not 146 be forwarded to the PEs that have no receivers attached to them for 147 that multicast group. This draft shows how this objective may be 148 achieved when Ingress Replication is used to distribute the multicast 149 traffic among the PEs. Procedures for supporting selective multicast 150 using P2MP tunnels can be found in [bum-procedure-updates] 152 The first two objectives are achieved by using IGMP/MLD proxy on the 153 PE and the third objective is achieved by setting up a multicast 154 tunnel (e.g., ingress replication) only among the PEs that have 155 interest in that multicast group(s) based on the trigger from 156 IGMP/MLD proxy processes. The proposed solutions for each of these 157 objectives are discussed in the following sections. 159 1.1 Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 162 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 163 and "OPTIONAL" in this document are to be interpreted as described in 164 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. 167 POD: Point of Delivery 169 ToR: Top of Rack 171 NV: Network Virtualization 173 NVO: Network Virtualization Overlay 175 VNI: Virtual Network Identifier (for VXLAN) 177 EVPN: Ethernet Virtual Private Network 179 IGMP: Internet Group Management Protocol 181 MLD: Multicast Listener Discovery 183 EVI: An EVPN instance spanning the Provider Edge (PE) devices 184 participating in that EVPN 186 MAC-VRF: A Virtual Routing and Forwarding table for Media Access 187 Control (MAC) addresses on a PE 189 Ethernet Segment (ES): When a customer site (device or network) is 190 connected to one or more PEs via a set of Ethernet links, then that 191 set of links is referred to as an 'Ethernet segment'. 193 Ethernet Segment Identifier (ESI): A unique non-zero identifier that 194 identifies an Ethernet segment is called an 'Ethernet Segment 195 Identifier'. 197 PE: Provider Edge device. 199 BD: Broadcast Domain. As per [RFC7432], an EVI consists of a single 200 or multiple BDs. In case of VLAN-bundle and VLAN-based service models 201 VLAN-aware bundle service model, an EVI contains multiple BDs. Also, 202 in this document, BD and subnet are equivalent terms. 204 Ethernet Tag: An Ethernet tag identifies a particular broadcast 205 domain, e.g., a VLAN. An EVPN instance consists of one or more 206 broadcast domains. 208 Single-Active Redundancy Mode: When only a single PE, among all the 209 PEs attached to an Ethernet segment, is allowed to forward traffic 210 to/from that Ethernet segment for a given VLAN, then the Ethernet 211 segment is defined to be operating in Single-Active redundancy mode. 213 All-Active Redundancy Mode: When all PEs attached to an Ethernet 214 segment are allowed to forward known unicast traffic to/from that 215 Ethernet segment for a given VLAN, then the Ethernet segment is 216 defined to be operating in All-Active redundancy mode. 218 2 IGMP Proxy 220 IGMP Proxy mechanism is used to reduce the flooding of IGMP messages 221 over EVPN network similar to ARP proxy used in reducing the flooding 222 of ARP messages over EVPN. It also provides triggering mechanism for 223 the PEs to setup their underlay multicast tunnels. IGMP Proxy 224 mechanism consist of two components: a) Proxy for IGMP Reports and b) 225 Proxy for IGMP Queries. 227 2.1 Proxy Reporting 229 When IGMP protocol is used between host/VMs and its first hop EVPN 230 router (EVPN PE), Proxy-reporting is used by the EVPN PE to summarize 231 (when possible) reports received from downstream hosts and propagate 232 it in BGP to other PEs that are interested in the info. This is done 233 by terminating IGMP Reports in the first hop PE, translating and 234 exchanging the relevant information among EVPN BGP speakers. The 235 information is again translated back to IGMP message at the recipient 236 EVPN speaker. Thus it helps create an IGMP overlay subnet using BGP. 237 In order to facilitate such an overlay, this document also defines a 238 new EVPN route type NLRI, EVPN Selective Multicast Ethernet Tag 239 route, along with its procedures to help exchange and register IGMP 240 multicast groups [section 5]. 242 2.1.1 IGMP Membership Report Advertisement in BGP 244 When a PE wants to advertise an IGMP membership report (Join) using 245 the BGP EVPN route, it follows the following rules: 247 1) When the first hop PE receives several IGMP membership reports 248 (Joins) , belonging to the same IGMP version, from different attached 249 hosts/VMs for the same (*,G) or (S,G), it only sends a single BGP 250 message corresponding to the very first IGMP Join. This is because 251 BGP is a statefull protocol and no further transmission of the same 252 report is needed. If the IGMP Join is for (*,G), then multicast group 253 address along with the corresponding version flag (v1, v2, or v3) are 254 set. In case of IGMPv3, exclude flag also needs to be set to indicate 255 that no source IP address to be excluded (e.g., include all sources 256 "*"). If the IGMP Join is for (S,G), then besides setting multicast 257 group address along with the version flag v3, the source IP address 258 and the include/exclude flag must be set. It should be noted that 259 when advertising the EVPN route for (S,G), the only valid version 260 flag is v3 (i.e., v1 and v2 flags must be set to zero). 262 2) When the first hop PE receives an IGMPv3 Join for (S,G) on a given 263 BD, it advertises the corresponding EVPN Selective Multicast Ethernet 264 Tag (SMET) route regardless of whether the source (S) is attached to 265 itself or not in order to facilitate the source move in the future. 267 3) When the first hop PE receives an IGMP version-X Join first for 268 (*,G) and then later it receives an IGMP version-Y Join for the same 269 (*,G), then it will re-advertise the same EVPN SMET route with flag 270 for version-Y set in addition to any previously-set version flag(s). 271 In other words, the first hop PE does not withdraw the EVPN route 272 before sending the new route because the flag field is not part of 273 BGP route key processing. 275 4) When the first hop PE receives an IGMP version-X Join first for 276 (*,G) and then later it receives an IGMPv3 Join for the same 277 multicast group address but for a specific source address S, then the 278 PE will advertise a new EVPN SMET route with v3 flag set (and v1 and 279 v2 reset). Include/exclude flag also need to be set accordingly. 280 Since source IP address is used as part of BGP route key processing, 281 it is considered as a new BGP route advertisement. 283 5) When a PE receives an EVPN SMET route with more than one version 284 flag set, it will generate the corresponding IGMP report for (*,G) 285 for each version specified in the flag field. With multiple version 286 flags set, there should be no source IP address in the receive EVPN 287 route. If there is, then an error should be logged. If v3 flag is set 288 (in addition to v1 or v2), then the include/exclude flag needs to 289 indicate "exclude". If not, then an error should be logged. The PE 290 MUST generate an IGMP membership report (Join) for that (*,G) and 291 each IGMP version in the version flag. 293 6) When a PE receives a list of EVPN SMET NLRIs in its BGP update 294 message, each with a different source IP address and the multicast 295 group address, and the version flag is set to v3, then the PE 296 generates an IGMPv3 membership report with a record corresponding to 297 the list of source IP addresses and the group address along with the 298 proper indication of inclusion/exclusion. 300 7) Upon receiving EVPN SMET route(s) and before generating the 301 corresponding IGMP Join(s), the PE checks to see whether it has any 302 CE multicast router for that BD on any of its ES's . The PE provides 303 such check by listening for PIM hellos on that AC (i.e, ). If 304 it has router's ACs, then the generated IGMP Join(s) are sent to 305 those ACs. If it doesn't have any router's AC, then no IGMP Join(s) 306 needs to be generated because sending IGMP Joins to other hosts can 307 result in unintentionally preventing a host from joining a specific 308 multicast group for IGMPv1 and IGMPv2 - i.e., if the PE does not 309 receive a join from the host it will not forward multicast data to 310 it. Per [RFC4541], when an IGMPv1 or IGMPv2 host receives a 311 membership report for a group address that it intends to join, the 312 host will suppress its own membership report for the same group. In 313 other words, an IGMPv1 or IGMPv2 Join MUST NOT be sent on an AC that 314 does not lead to a CE multicast router. This message suppression is a 315 requirement for IGMPv1 and IGMPv2 hosts. This is not a problem for 316 hosts running IGMPv3 because there is no suppression of IGMP 317 Membership reports. 319 2.1.1 IGMP Leave Group Advertisement in BGP 321 When a PE wants to withdraw an EVPN SMET route corresponding to an 322 IGMPv2 Leave Group (Leave) or IGMPv3 "Leave" equivalent message, it 323 follows the following rules: 325 1) For IGMPv1, there is no explicit membership leave; therefore, the 326 PE needs to periodically send out an IGMP membership query to 327 determine whether there is any host left who is interested in 328 receiving traffic directed to this multicast group (this proxy query 329 function will be described in more details in section 2.2). If there 330 is no host left, then the PE re-advertises EVPN SMET route with the 331 v1 version flag reset. If this is the last version flag to be reset, 332 then instead of re-advertising the EVPN route with all version flags 333 reset, the PE withdraws the EVPN route for that (*,G). 335 2) When a PE receives an IGMPv2 Leave Group or its "Leave" equivalent 336 message for IGMPv3 from its attached host, it checks to see if this 337 host is the last host who is interested in this multicast group by 338 sending a query for the multicast group. If the host was indeed the 339 last one, then the PE re-advertises EVPN SMET Multicast route with 340 the corresponding version flag reset. If this is the last version 341 flag to be reset, then instead of re-advertising the EVPN route with 342 all version flags reset, the PE withdraws the EVPN route for that 343 (*,G). 345 3) When a PE receives an EVPN SMET route for a given (*,G), it 346 compares the received version flags from the route with its per-PE 347 stored version flags. If the PE finds that a version flag associated 348 with the (*,G) for the remote PE is reset, then the PE generates IGMP 349 Leave for that (*,G) toward its local interface (if any) attached to 350 the multicast router for that multicast group. It should be noted 351 that the received EVPN route should at least have one version flag 352 set. If all version flags are reset, it is an error because the PE 353 should have received an EVPN route withdraw for the last version 354 flag. If the PE receives an EVPN SMET route withdraw, then it must 355 remove the remote PE from the OIF list associated with that multicast 356 group. 358 4) When a PE receives an EVPN SMET route withdraw, it removes the 359 remote PE from its OIF list for that multicast group and if there are 360 no more OIF entries for that multicast group (either locally or 361 remotely), then the PE MUST stop responding to queries from the 362 locally attached router (if any). If there is a source for that 363 multicast group, the PE stops sending multicast traffic for that 364 source. 366 2.2 Proxy Querier 368 As mentioned in the previous sections, each PE need to have proxy 369 querier functionality for the following reasons: 371 1) To enable the collection of EVPN PEs providing L2VPN service to 372 act as distributed multicast router with Anycast IP address for all 373 attached hosts/VMs in that subnet. 375 2) To enable suppression of IGMP membership reports and queries over 376 MPLS/IP core. 378 3) To enable generation of query messages locally to their attached 379 host. In case of IGMPv1, the PE needs to send out an IGMP membership 380 query to verify that at least one host on the subnet is still 381 interested in receiving traffic directed to that group. When there is 382 no reply to three consecutive IGMP membership queries, the PE times 383 out the group, stops forwarding multicast traffic to the attached 384 hosts for that (*,G), and sends a EVPN SMET route associated with 385 that (*,G) with the version-1 flag reset or withdraws that route. 387 3 Operation 389 Consider the EVPN network of figure-1, where there is an EVPN 390 instance configured across the PEs shown in this figure (namely PE1, 391 PE2, and PE3). Lets consider that this EVPN instance consist of a 392 single bridge domain (single subnet) with all the hosts, sources and 393 the multicast router shown in this figure connected to this subnet. 394 PE1 only has hosts connected to it. PE2 has a mix of hosts and 395 multicast source. PE3 has a mix of hosts, multicast source, and 396 multicast router. Further more, lets consider that for (S1,G1), R1 is 397 used as the multicast router. The following subsections describe the 398 IGMP proxy operation in different PEs with regard to whether the 399 locally attached devices for that subnet are: 401 - only hosts/VMs 402 - mix of hosts/VMs and multicast source 403 - mix of hosts/VMs, multicast source, and multicast router 405 +--------------+ 406 | | 407 | | 408 +----+ | | +----+ 409 H1:(*,G1)v1 ---| | | | | |---- H6(*,G1)v2 410 H2:(*,G1)v1 ---| PE1| | IP/MPLS | | PE2|---- H7(S2,G2)v3 411 H3:(*,G1)v2 ---| | | Network | | |---- S2 412 H4:(S2,G2)v3 --| | | | | | 413 +----+ | | +----+ 414 | | 415 +----+ | | 416 H5:(S1,G1)v3 --| | | | 417 S1 ---| PE3| | | 418 R1 ---| | | | 419 +----+ | | 420 | | 421 +--------------+ 423 Figure 1: 425 3.1 PE with only attached hosts/VMs for a given subnet 427 When PE1 receives an IGMPv1 Join Report from H1, it does not forward 428 this join to any of its other ports (for this subnet) because all 429 these local ports are associated with the hosts/VMs. PE1 sends an 430 EVPN Multicast Group route corresponding to this join for (*,G1) and 431 setting v1 flag. This EVPN route is received by PE2 and PE3 that are 432 the member of the same BD (i.e., same EVI in case of VLAN-based 433 service or in case of VLAN-aware bundle service). PE3 434 reconstructs IGMPv1 Join Report from this EVPN BGP route and only 435 sends it to the port(s) with multicast routers attached to it (for 436 that subnet). In this example, PE3 sends the reconstructed IGMPv1 437 Join Report for (*,G1) to only R1. Furthermore, PE2 although receives 438 the EVPN BGP route, it does not send it to any of its port for that 439 subnet - namely ports associated with H6 and H7. 441 When PE1 receives the second IGMPv1 Join from H2 for the same 442 multicast group (*,G1), it only adds that port to its OIF list but it 443 doesn't send any EVPN BGP route because there is no change in 444 information. However, when it receives the IGMPv2 Join from H3 for 445 the same (*,G1), besides adding the corresponding port to its OIF 446 list, it re-advertises the previously sent EVPN SMET route with the 447 version-2 flag set. 449 Finally when PE1 receives the IMGMPv3 Join from H4 for (S2,G2), it 450 advertises a new EVPN SMET route corresponding to it. 452 3.2 PE with mixed of attached hosts/VMs and multicast source 454 The main difference in here is that when PE2 receives IGMPv3 Join 455 from H7 for (S2,G2), it does not advertises it in BGP because PE2 456 knows that S2 is attached to its local AC. PE2 adds the port 457 associated with H7 to its OIF list for (S2,G2). The processing for 458 IGMPv2 received from H6 is the same as the v2 Join described in 459 previous section. 461 3.3 PE with mixed of attached hosts/VMs, multicast source and router 463 The main difference in here relative to the previous two sections is 464 that Join messages received locally needs to be sent to the port 465 associated with router R1. Furthermore, the Joins received via BGP 466 need to be passed to the R1 port but filtered for all other ports. 468 4 All-Active Multi-Homing 470 Because a CE's LAG flow hashing algorithm is unknown, in an All- 471 Active redundancy mode it must be assumed that the CE can send a 472 given IGMP message to any one of the multi-homed PEs, either DF or 473 non-DF - i.e., different IGMP Join messages can arrive at different 474 PEs in the redundancy group and furthermore their corresponding Leave 475 messages can arrive at PEs that are different from the ones received 476 the Join messages. Therefore, all PEs attached to a given ES must 477 coordinate IGMP Join and Leave Group (x, G) state, where x may be 478 either '*' or a particular source S, for each BD on that ES. This 479 allows the DF for that [ES, BD] to correctly advertise or withdraw a 480 Selective Multicast Ethernet Tag (SMET) route for that (x, G) group 481 in that BD when needed. 483 All-Active multihoming PEs for a given ES MUST support IGMP synch 484 procedures described in this section if they want to perform IGMP 485 proxy for hosts connects to that ES. 487 4.1 Local IGMP Join Synchronization 489 When a PE, either DF or non-DF, receives, on a given multihomed ES 490 operating in All-Active redundancy mode, an IGMP Membership Report 491 for (x, G), it determines the BD to which the IGMP Membership Report 492 belongs. If the PE doesn't already have local IGMP Join (x, G) state 493 for that BD on that ES, it instantiates local IGMP Join (x, G) state 494 and advertises a BGP IGMP Join Synch route for that [ES, BD]. Local 495 IGMP Join (x, G) state refers to IGMP Join (x, G) state that is 496 created as the result of processing an IGMP Membership Report for (x, 497 G). 499 The IGMP Join Synch route carries the ES-Import RT for the ES on 500 which the IGMP Membership Report was received. Thus it may only go 501 to the PEs attached to that ES (and not any other PEs). 503 When a PE, either DF or non-DF, receives an IGMP Join Synch route it 504 installs that route and if it doesn't already have IGMP Join (x, G) 505 state for that [ES, BD], it instantiates that IGMP Join (x,G) state - 506 i.e., IGMP Join (x, G) state is the union of local IGMP Join (x, G) 507 state and installed IGMP Join Synch route. If the DF is not currently 508 advertising (originating) a SMET route for that (x, G) group in that 509 BD, it does so now. 511 When a PE, either DF or non-DF, deletes its local IGMP Join (x, G) 512 state for that [ES, BD], it withdraws its BGP IGMP Join Synch route 513 for that [ES, BD]. 515 When a PE, either DF or non-DF, receives the withdrawal of an IGMP 516 Join Synch route from another PE it removes that route. When a PE 517 has no local IGMP Join (x, G) state and it has no installed IGMP Join 518 Synch routes, it removes IGMP Join (x, G) state for that [ES, BD]. 519 If the DF no longer has IGMP Join (x, G) state for that BD on any ES 520 for which it is DF, it withdraws its SMET route for that (x, G) group 521 in that BD. 523 I.e., A PE advertises an SMET route for that (x, G) group in that BD 524 when it has IGMP Join (x, G) state in that BD on at least one ES for 525 which it is DF and it withdraws that SMET route when it does not have 526 IGMP Join (x, G) state in that BD on any ES for which it is DF. 528 4.2 Local IGMP Leave Group Synchronization 530 When a PE, either DF or non-DF, receives, on a given multihomed ES 531 operating in All-Active redundancy mode, an IGMP Leave Group message 532 for (x, G) from the attached CE, it determines the BD to which the 533 IGMPv2 Leave Group belongs. Regardless of whether it has IGMP Join 534 (x, G) state for that [ES, BD], it initiates the (x, G) leave group 535 synchronization procedure, which consists of the following steps: 537 1) It computes the Maximum Response Time, which is the duration of 538 (x, G) leave group synchronization procedure. This is the product of 539 two locally configured values, Last Member Query Count and Last 540 Member Query Interval (described in Section 3 of [RFC2236]), plus 541 delta, the time it takes for a BGP advertisement to propagate between 542 the PEs attached to the multihomed ES (delta is a consistently 543 configured value on all PEs attached to the multihomed ES). 545 2) It starts the Maximum Response Time timer. Note that the receipt 546 of subsequent IGMP Leave Group messages or BGP Leave Synch routes for 547 (x, G) do not change the value of a currently running Maximum 548 Response Time timer and are ignored by the PE. 550 3) It initiates the Last Member Query procedure described in Section 551 3 of [RFC2236]; viz, it sends a number of Group-Specific Query (x, G) 552 messages (Last Member Query Count) at a fixed interval (Last Member 553 Query Interval) to the attached CE. 555 4) It advertises an IGMP Leave Synch route for that that [ES, BD]. 556 This route notifies the other multihomed PEs attached to the given 557 multihomed ES that it has initiated an (x, G) leave group 558 synchronization procedure; i.e., it carries the ES-Import RT for the 559 ES on which the IGMP Leave Group was received. It also contains the 560 Maximum Response Time and the Leave Group Synchronization Procedure 561 Sequence number. The latter identifies the specific (x, G) leave 562 group synchronization procedure initiated by the advertising PE, 563 which increments the value whenever it initiates a procedure. 565 5) When the Maximum Response Timer expires, the PE that has 566 advertised the IGMP Leave Synch route withdraws it. 568 4.2.1 Remote Leave Group Synchronization 570 When a PE, either DF or non-DF, receives an IGMP Leave Synch route it 571 installs that route and it starts a timer for (x, G) on the specified 572 [ES, BD] whose value is set to the Maximum Response Time in the 573 received IGMP Leave Synch route. Note that the receipt of subsequent 574 IGMPv2 Leave Group messages or BGP Leave Synch routes for (x, G) do 575 not change the value of a currently running Maximum Response Time 576 timer and are ignored by the PE. 578 4.2.2 Common Leave Group Synchronization 580 If a PE attached to the multihomed ES receives an IGMP Membership 581 Report for (x, G) before the Maximum Response Time timer expires, it 582 advertises a BGP IGMP Join Synch route for that [ES, BD]. If it 583 doesn't already have local IGMP Join (x, G) state for that [ES, BD], 584 it instantiates local IGMP Join (x, G) state. If the DF is not 585 currently advertising (originating) a SMET route for that (x, G) 586 group in that BD, it does so now. 588 If a PE attached to the multihomed ES receives an IGMP Join Synch 589 route for (x, G) before the Maximum Response Time timer expires, it 590 installs that route and if it doesn't already have IGMP Join (x, G) 591 state for that BD on that ES, it instantiates that IGMP Join (x,G) 592 state. If the DF is not currently advertising (originating) a SMET 593 route for that (x, G) group in that BD, it does so now. 595 When the Maximum Response Timer expires a PE that has advertised an 596 IGMP Leave Synch route, withdraws it. Any PE attached to the 597 multihomed ES, that started the Maximum Response Time and has no 598 local IGMP Join (x, G) state and no installed IGMP Join Synch routes, 599 it removes IGMP Join (x, G) state for that [ES, BD]. If the DF no 600 longer has IGMP Join (x, G) state for that BD on any ES for which it 601 is DF, it withdraws its SMET route for that (x, G) group in that BD. 603 5 Single-Active Multi-Homing 605 Note that to facilitate state synchronization after failover, the PEs 606 attached to a multihomed ES operating in Single-Active redundancy 607 mode should also coordinate IGMP Join (x, G) state. In this case all 608 IGMP Join messages are received by the DF and distributed to the non- 609 DF PEs using the procedures described above. 611 6 Selective Multicast Procedures for IR tunnels 613 If an ingress PE uses ingress replication, then for a given (x, G) 614 group in a given BD: 616 1) It sends (x, G) traffic to the set of PEs not supporting IGMP 617 Proxy. This set consists of any PE that has advertised an Inclusive 618 Multicast Tag route for the BD without the "IGMP Proxy Support" flag. 620 2) It sends (x, G) traffic to the set of PEs supporting IGMP Proxy 621 and having listeners for that (x, G) group in that BD. This set 622 consists of any PE that has advertised an Inclusive Multicast Tag 623 route for the BD with the "IGMP Proxy Support" flag and that has 624 advertised an SMET route for that (x, G) group in that BD. 626 If an ingress PE's Selective P-Tunnel for a given BD uses P2MP and 627 all of the PEs in the BD support that tunnel type and IGMP, then for 628 a given (x, G) group in a given BD it sends (x, G) traffic using the 629 Selective P-Tunnel for that (x, G) group in that BD. This tunnel 630 will include those PEs that have advertised an SMET route for that 631 (x, G) group on that BD (for Selective P-tunnel) but it may include 632 other PEs as well (for Aggregate Selective P-tunnel). 634 7 BGP Encoding 636 This document defines three new BGP EVPN routes to carry IGMP 637 membership reports. This route type is known as: 639 + 6 - Selective Multicast Ethernet Tag Route 640 + 7 - IGMP Join Synch Route 641 + 8 - IGMP Leave Synch Route 643 The detailed encoding and procedures for this route type is described 644 in subsequent section. 646 7.1 Selective Multicast Ethernet Tag Route 648 An Selective Multicast Ethernet Tag route type specific EVPN NLRI 649 consists of the following: 651 +---------------------------------------+ 652 | RD (8 octets) | 653 +---------------------------------------+ 654 | Ethernet Tag ID (4 octets) | 655 +---------------------------------------+ 656 | Multicast Source Length (1 octet) | 657 +---------------------------------------+ 658 | Multicast Source Address (variable) | 659 +---------------------------------------+ 660 | Multicast Group Length (1 octet) | 661 +---------------------------------------+ 662 | Multicast Group Address (Variable) | 663 +---------------------------------------+ 664 | Originator Router Length (1 octet) | 665 +---------------------------------------+ 666 | Originator Router Address (variable) | 667 +---------------------------------------+ 668 | Flags (1 octets) (optional) | 669 +---------------------------------------+ 671 For the purpose of BGP route key processing, all the fields are 672 considered to be part of the prefix in the NLRI except for the one- 673 octet optional flag field (if included). The Flags fields are defined 674 as follows: 676 0 1 2 3 4 5 6 7 677 +--+--+--+--+--+--+--+--+ 678 | reserved |IE|v3|v2|v1| 679 +--+--+--+--+--+--+--+--+ 681 The least significant bit, bit 7 indicates support for IGMP version 682 1. 684 The second least significant bit, bit 6 indicates support for IGMP 685 version 2. 687 The third least significant bit, bit 5 indicates support for IGMP 688 version 3. 690 The forth least significant bit, bit 4 indicates whether the (S, G) 691 information carried within the route-type is of Include Group type 692 (bit value 0) or an Exclude Group type (bit value 1). The Exclude 693 Group type bit MUST be ignored if bit 5 is not set. 695 This EVPN route type is used to carry tenant IGMP multicast group 696 information. The flag field assists in distributing IGMP membership 697 interest of a given host/VM for a given multicast route. The version 698 bits help associate IGMP version of receivers participating within 699 the EVPN domain. 701 The include/exclude bit helps in creating filters for a given 702 multicast route. 704 7.1.1 Constructing the Selective Multicast Ethernet Tag route 706 This section describes the procedures used to construct the Selective 707 Multicast Ethernet Tag (SMET) route. Support for this route type is 708 optional. 710 The Route Distinguisher (RD) SHOULD be a Type 1 RD [RFC4364]. The 711 value field comprises an IP address of the PE (typically, the 712 loopback address) followed by a number unique to the PE. 714 The Ethernet Tag ID MUST be set as follows: 716 EVI is VLAN-Based or VLAN Bundle service - set to 0 717 EVI is VLAN-Aware Bundle service without translation - set to 718 the customer VID for that BD 719 EVI is VLAN-Aware Bundle service with translation - set to the 720 normalized Ethernet Tag ID - e.g., normalized VID 722 The Multicast Source length MUST be set to length of multicast source 723 address in bits. In case of a (*, G) Join, the Multicast Source 724 Length is set to 0. 726 The Multicast Source is the Source IP address of the IGMP membership 727 report. In case of a (*, G) Join, this field does not exist. 729 The Multicast Group length MUST be set to length of multicast group 730 address in bits. 732 The Multicast Group is the Group address of the IGMP membership 733 report. 735 The Originator Router Length is the length of the Originator Router 736 address in bits. 738 The Originator Router Address is the IP address of Router Originating 739 the prefix. It should be noted that using the "Originating Router's 740 IP address" field is needed for local-bias procedures and may be 741 needed for building inter-AS multicast underlay tunnels where BGP 742 next hop can get over written. 744 The Flags field indicates the version of IGMP protocol from which the 745 membership report was received. It also indicates whether the 746 multicast group had INCLUDE or EXCLUDE bit set. 748 IGMP protocol is used to receive group membership information from 749 hosts/VMs by TORs. Upon receiving the hosts/VMs expression of 750 interest of a particular group membership, this information is then 751 forwarded using Ethernet Multicast Source Group Route NLRI. The NLRI 752 also keeps track of receiver's IGMP protocol version and any "source 753 filtering" for a given group membership. All EVPN SMET routes are 754 announced with per-EVI Route Target extended communities. 756 7.2 IGMP Join Synch Route 758 This EVPN route type is used to coordinate IGMP Join (x,G) state for 759 a given BD between the PEs attached to a given ES operating in All- 760 Active (or Single-Active) redundancy mode and it consists of 761 following: 763 +--------------------------------------------------+ 764 | RD (8 octets) | 765 +--------------------------------------------------+ 766 | Ethernet Segment Identifier (10 octets) | 767 +--------------------------------------------------+ 768 | Ethernet Tag ID (4 octets) | 769 +--------------------------------------------------+ 770 | Multicast Source Length (1 octet) | 771 +--------------------------------------------------+ 772 | Multicast Source Address (variable) | 773 +--------------------------------------------------+ 774 | Multicast Group Length (1 octet) | 775 +--------------------------------------------------+ 776 | Multicast Group Address (Variable) | 777 +--------------------------------------------------+ 778 | Originator Router Length (1 octet) | 779 +--------------------------------------------------+ 780 | Originator Router Address (variable) | 781 +--------------------------------------------------+ 782 | Flags (1 octet) | 783 +--------------------------------------------------+ 785 For the purpose of BGP route key processing, all the fields are 786 considered to be part of the prefix in the NLRI except for the one- 787 octet Flags field, whose fields are defined as follows: 789 0 1 2 3 4 5 6 7 790 +--+--+--+--+--+--+--+--+ 791 | reserved |IE|v3|v2|v1| 792 +--+--+--+--+--+--+--+--+ 794 The least significant bit, bit 7 indicates support for IGMP version 795 1. The second least significant bit, bit 6 indicates support for 796 IGMP version 2. The third least significant bit, bit 5 indicates 797 support for IGMP version 3. The fourth least significant bit, bit 4 798 indicates whether the (S, G) information carried within the route- 799 type is of Include Group type (bit value 0) or an Exclude Group type 800 (bit value 1). The Exclude Group type bit MUST be ignored if bit 5 is 801 not set. 803 The Flags field assists in distributing IGMP membership interest of a 804 given host/VM for a given multicast route. The version bits help 805 associate IGMP version of receivers participating within the EVPN 806 domain. The include/exclude bit helps in creating filters for a 807 given multicast route. 809 7.2.1 Constructing the IGMP Join Synch Route 811 This section describes the procedures used to construct the IGMP Join 812 Synch route. Support for this route type is optional. If a PE does 813 not support this route, then it MUST not indicate that it supports 814 'IGMP proxy' in Multicast Flag extended community for the EVIs 815 corresponding to its multi-homed Ethernet Segments. 817 An IGMP Join Synch route MUST carry exactly one ES-Import Route 818 Target extended community, the one that corresponds to the ES on 819 which the IGMP Join was received. It MUST also carry exactly one 820 EVI-RT EC, the one that corresponds to the EVI on which the IGMP Join 821 was received. See Section 7.5 for details on how to form the EVI-RT 822 EC. 824 The Route Distinguisher (RD) SHOULD be a Type 1 RD [RFC4364]. The 825 value field comprises an IP address of the PE (typically, the 826 loopback address) followed by a number unique to the PE. 828 The Ethernet Segment Identifier (ESI) MUST be set to the 10-octet 829 value defined for the ES. 831 The Ethernet Tag ID MUST be set as follows: 833 EVI is VLAN-Based or VLAN Bundle service - set to 0 834 EVI is VLAN-Aware Bundle service without translation - set to 835 the customer VID for the BD 836 EVI is VLAN-Aware Bundle service with translation - set to the 837 normalized Ethernet Tag ID - e.g., normalized VID 839 The Multicast Source length MUST be set to length of multicast source 840 address in bits. In case of a (*, G) Join, the Multicast Source 841 Length is set to 0. 843 The Multicast Source is the Source IP address of the IGMP membership 844 report. In case of a (*, G) Join, this field does not exist. 846 The Multicast Group length MUST be set to length of multicast group 847 address in bits. 849 The Multicast Group is the Group address of the IGMP membership 850 report. 852 The Originator Router Length is the length of the Originator Router 853 address in bits. 855 The Originator Router Address is the IP address of Router Originating 856 the prefix. 858 The Flags field indicates the version of IGMP protocol from which the 859 membership report was received. It also indicates whether the 860 multicast group had INCLUDE or EXCLUDE bit set. 862 7.3 IGMP Leave Synch Route This EVPN route type is used to coordinate 863 IGMP Leave Group (x,G) state for a given BD between the PEs attached 864 to a given ES operating in All-Active (or Single-Active) redundancy 865 mode and it consists of following: 867 +--------------------------------------------------+ 868 | RD (8 octets) | 869 +--------------------------------------------------+ 870 | Ethernet Segment Identifier (10 octets) | 871 +--------------------------------------------------+ 872 | Ethernet Tag ID (4 octets) | 873 +--------------------------------------------------+ 874 | Multicast Source Length (1 octet) | 875 +--------------------------------------------------+ 876 | Multicast Source Address (variable) | 877 +--------------------------------------------------+ 878 | Multicast Group Length (1 octet) | 879 +--------------------------------------------------+ 880 | Multicast Group Address (Variable) | 881 +--------------------------------------------------+ 882 | Originator Router Length (1 octet) | 883 +--------------------------------------------------+ 884 | Originator Router Address (variable) | 885 +--------------------------------------------------+ 886 | Leave Group Synchronization # (4 octets) | 887 +--------------------------------------------------+ 888 | Maximum Response Time (1 octet) | 889 +--------------------------------------------------+ 890 | Flags (1 octet) | 891 +--------------------------------------------------+ 893 For the purpose of BGP route key processing, all the fields are 894 considered to be part of the prefix in the NLRI except for the 895 Maximum Response Time and the one-octet Flags field, whose fields are 896 defined as follows: 898 0 1 2 3 4 5 6 7 899 +--+--+--+--+--+--+--+--+ 900 | reserved |IE|v3|v2|v1| 901 +--+--+--+--+--+--+--+--+ 903 The least significant bit, bit 7 indicates support for IGMP version 904 1. The second least significant bit, bit 6 indicates support for 905 IGMP version 2. The third least significant bit, bit 5 indicates 906 support for IGMP version 3. The fourth least significant bit, bit 4 907 indicates whether the (S, G) information carried within the route- 908 type is of Include Group type (bit value 0) or an Exclude Group type 909 (bit value 1). The Exclude Group type bit MUST be ignored if bit 5 is 910 not set. 912 The Flags field assists in distributing IGMP membership interest of a 913 given host/VM for a given multicast route. The version bits help 914 associate IGMP version of receivers participating within the EVPN 915 domain. The include/exclude bit helps in creating filters for a 916 given multicast route. 918 7.3.1 Constructing the IGMP Leave Synch Route 920 This section describes the procedures used to construct the IGMP 921 Leave Synch route. Support for this route type is optional. If a PE 922 does not support this route, then it MUST not indicate that it 923 supports 'IGMP proxy' in Multicast Flag extended community for the 924 EVIs corresponding to its multi-homed Ethernet Segments. 926 An IGMP Leave Synch route MUST carry exactly one ES-Import Route 927 Target extended community, the one that corresponds to the ES on 928 which the IGMP Leave was received. It MUST also carry exactly one 929 EVI-RT EC, the one that corresponds to the EVI on which the IGMP 930 Leave was received. See Section 7.5 for details on how to form the 931 EVI-RT EC. 933 The Route Distinguisher (RD) SHOULD be a Type 1 RD [RFC4364]. The 934 value field comprises an IP address of the PE (typically, the 935 loopback address) followed by a number unique to the PE. 937 The Ethernet Segment Identifier (ESI) MUST be set to the 10-octet 938 value defined for the ES. 940 The Ethernet Tag ID MUST be set as follows: 942 EVI is VLAN-Based or VLAN Bundle service - set to 0 943 EVI is VLAN-Aware Bundle service without translation - set to 944 the customer VID for the BD 945 EVI is VLAN-Aware Bundle service with translation - set to the 946 normalized Ethernet Tag ID - e.g., normalized VID 948 The Multicast Source length MUST be set to length of multicast source 949 address in bits. In case of a (*, G) Join, the Multicast Source 950 Length is set to 0. 952 The Multicast Source is the Source IP address of the IGMP membership 953 report. In case of a (*, G) Join, this field does not exist. 955 The Multicast Group length MUST be set to length of multicast group 956 address in bits. 958 The Multicast Group is the Group address of the IGMP membership 959 report. 961 The Originator Router Length is the length of the Originator Router 962 address in bits. 964 The Originator Router Address is the IP address of Router Originating 965 the prefix. 967 The Flags field indicates the version of IGMP protocol from which the 968 membership report was received. It also indicates whether the 969 multicast group had INCLUDE or EXCLUDE bit set. 971 7.4 Multicast Flags Extended Community 973 The 'Multicast Flags' extended community is a new EVPN extended 974 community. EVPN extended communities are transitive extended 975 communities with a Type field value of 6. IANA will assign a Sub- 976 Type from the 'EVPN Extended Community Sub-Types' registry. 978 A PE that supports IGMP proxy on a given BD MUST attach this extended 979 community to the Inclusive Multicast Ethernet Tag (IMET) route it 980 advertises for that BD and it Must set the IGMP Proxy Support flag to 981 1. Note that an [RFC7432] compliant PE will not advertise this 982 extended community so its absence indicates that the advertising PE 983 does not support IGMP Proxy. 985 The advertisement of this extended community enables more efficient 986 multicast tunnel setup from the source PE specially for ingress 987 replication - i.e., if an egress PE supports IGMP proxy but doesn't 988 have any interest in a given (x, G), it advertises its IGMP proxy 989 capability using this extended community but it does not advertise 990 any SMET route for that (x, G). When the source PE (ingress PE) 991 receives such advertisements from the egress PE, it does not 992 replicate the multicast traffic to that egress PE; however, it does 993 replicate the multicast traffic to the egress PEs that don't 994 advertise such capability even if they don't have any interests in 995 that (x, G). 997 A Multicast Flags extended community is encoded as an 8-octet value, 998 as follows: 1000 1 2 3 1001 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 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | Type=0x06 | Sub-Type=TBD | Flags (2 Octets) | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | Reserved=0 | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 The low-order bit of the Flags is defined as the "IGMP Proxy Support" 1009 bit. A value of 1 means that the PE supports IGMP Proxy as defined 1010 in this document, and a value of 0 means that the PE does not support 1011 IGMP proxy. The absence of this extended community also means that 1012 the PE doesn not support IGMP proxy. 1014 7.5 EVI-RT Extended Community 1016 In EVPN, every EVI is associated with one or more Route Targets 1017 (RTs). These Route Targets serve two functions: 1019 - Distribution control: RTs control the distribution of the routes. 1020 If a route carries the RT associated with a particular EVI, it will 1021 be distributed to all the PEs on which that EVI exists. 1023 - EVI Identification: Once a route has been received by a particular 1024 PE, the RT is used to identify the EVI to which it applies. 1026 An IGMP Join Synch or IGMP Leave Synch route is associated with a 1027 particular combination of ES and EVI. These routes need to be 1028 distributed only to PEs that are attached to the associated ES. 1029 Therefore these routes carry the ES-Import RT for that ES. 1031 Since an IGMP Join Synch or IGMP Leave Synch route does not need to 1032 be distributed to all the PEs on which the associated EVI exists, 1033 these routes cannot carry the RT associated with that EVI. Therefore, 1034 when such a route arrives at a particular PE, the route's RTs cannot 1035 be used to identify the EVI to which the route applies. Some other 1036 means of associating the route with an EVI must be used. 1038 This document specifies four new Extended Communities (EC) that can 1039 be used to identify the EVI with which a route is associated, but 1040 which do not have any effect on the distribution of the route. These 1041 new ECs are are known as the "Type 0 EVI-RT EC", the "Type 1 EVI-RT 1042 EC", the "Type 2 EVI-RT EC", and the "Type 3 EVI-RT EC". 1044 A Type 0 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xA. 1046 A Type 1 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xB. 1048 A Type 2 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xC. 1050 A Type 3 EVI-RT EC is an EVPN EC (type 6) of sub-type TBD. 1052 Each IGMP Join Synch or IGMP Leave Synch route MUST carry exactly one 1053 EVI-RT EC. The EVI-RT EC carried by a particular route is 1054 constructed as follows. Each such route is the result of having 1055 received an IGMP Join or an IGMP Leave message from a particular BD. 1056 We will say that the route is associated with that BD. For each BD, 1057 there is a corresponding RT that is used to ensure that routes 1058 "about" that BD are distributed to all PEs attached to that BD. So 1059 suppose a given IGMP Join Synch or Leave Synch route is associated 1060 with a given BD, say BD1, and suppose that the corresponding RT for 1061 BD1 is RT1. Then: 1063 0. If RT1 is a Transitive Two-Octet AS-specific EC, then the EVI-RT 1064 EC carried by the route is a Type 0 EVI-RT EC. The value field of 1065 the Type 0 EVI-RT EC is identical to the value field of RT1. 1067 1. If RT1 is a Transitive IPv4-Address-specific EC, then the EVI-RT 1068 EC carried by the route is a Type 1 EVI-RT EC. The value field of 1069 the Type 1 EVI-RT EC is identical to the value field of RT1. 1071 2. If RT1 is a Transitive Four-Octet-specific EC, then the EVI-RT EC 1072 carried by the route is a Type 2 EVI-RT EC. The value field of the 1073 Type 2 EVI-RT EC is identical to the value field of RT1. 1075 3. If RT1 is a Transitive IPv6-Address-specific EC, then the EVI-RT 1076 EC carried by the route is a Type 3 EVI-RT EC. The value field of 1077 the Type 3 EVI-RT EC is identical to the value field of RT1. 1079 An IGMP Join Synch or Leave Synch route MUST carry exactly one EVI- 1080 RT EC. 1082 Suppose a PE receives a particular IGMP Join Synch or IGMP Leave 1083 Synch route, say R1, and suppose that R1 carries an ES-Import RT that 1084 is one of the PE's Import RTs. If R1 has no EVI-RT EC, or has more 1085 than one EVI-RT EC, the PE MUST apply the "treat-as-withdraw" 1086 procedure of [RFC7606]. 1088 Note that an EVI-RT EC is not a Route Target Extended Community, is 1089 not visible to the RT Constrain mechanism [RFC4684], and is not 1090 intended to influence the propagation of routes by BGP. 1092 1 2 3 1093 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 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Type=0x06 | Sub-Type=n | RT associated with EVI | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | RT associated with the EVI (cont.) | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 Where the value of 'n' is 0x0A, 0x0B, 0x0C, or 0x0D corresponding to 1101 EVI-RT type 0, 1, 2, or 3 respectively. 1103 7.6 Rewriting of RT ECs and EVI-RT ECs by ASBRs 1105 There are certain situations in which an ES is attached to a set of 1106 PEs that are not all in the same AS, or not all operated by the same 1107 provider. In some such situations, the RT that corresponds to a 1108 particular EVI may be different in each AS. If a route is propagated 1109 from AS1 to AS2, an ASBR at the AS1/AS2 border may be provisioned 1110 with a policy that removes the RTs that are meaningful in AS1 and 1111 replaces them with the corresponding (i.e., RTs corresponding to the 1112 same EVIs) RTs that are meaningful in AS2. This is known as RT- 1113 rewriting. 1115 Note that if a given route's RTs are rewritten, and the route carries 1116 an EVI-RT EC, the EVI-RT EC needs to be rewritten as well. 1118 8 Acknowledgement 1120 9 Security Considerations 1122 Same security considerations as [RFC7432]. 1124 10 IANA Considerations 1126 IANA has allocated the following codepoints from the EVPN Extended 1127 Community sub-types registry. 1129 0x09 Multicast Flags Extended Community [this document] 1130 0x0A EVI-RT Type 0 [this document] 1131 0x0B EVI-RT Type 1 [this document] 1132 0x0C EVI-RT Type 2 [this document] 1134 IANA is requested to allocate a new codepoint from the EVPN Extended 1135 Community sub-types registry for the following. 1137 0x0D EVI-RT Type 3 [this document] 1139 IANA has allocated the following EVPN route types from the EVPN Route 1140 Type registry. 1142 6 - Selective Multicast Ethernet Tag Route 1143 7 - IGMP Join Synch Route 1144 8 - IGMP Leave Synch Route 1146 IANA is requested to create a registry, "Multicast Flags Extended 1147 Community Flags", in the BGP registry. 1149 The Multicast Flags Extended Community contains a 16-bit Flags field. 1150 The bits are numbered 0-15, from low-order to high-order. 1152 The registry should be initialized as follows: 1154 0 : IGMP Proxy Support [this document] 1155 1-15 : unassigned 1157 The registration policy should be "Standards Action". 1159 11 References 1161 11.1 Normative References 1163 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1164 Requirement Levels", BCP 14, RFC 2119, March 1997. 1166 [RFC4360] S. Sangli et al, ""BGP Extended Communities Attribute", 1167 February, 2006. 1169 [RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", February, 1170 2015. 1172 11.2 Informative References 1174 [ETREE-FMWK] Key et al., "A Framework for E-Tree Service over MPLS 1175 Network", draft-ietf-l2vpn-etree-frwk-03, work in progress, September 1176 2013. 1178 [PBB-EVPN] Sajassi et al., "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn- 1179 05.txt, work in progress, October, 2013. 1181 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 1182 "Considerations for IGMP and MLD snooping PEs", RFC 4541, 2006. 1184 Authors' Addresses 1186 Ali Sajassi 1187 Cisco 1188 Email: sajassi@cisco.com 1190 Samir Thoria 1191 Cisco 1192 Email: sthoria@cisco.com 1194 Keyur Patel 1195 Arrcus 1196 Email: keyur@arrcus.com 1198 Derek Yeung 1199 Arrcus 1200 Email: derek@arrcus.com 1202 John Drake 1203 Juniper 1204 Email: jdrake@juniper.net 1206 Wen Lin 1207 Juniper 1208 Email: wlin@juniper.net