idnits 2.17.1 draft-ietf-bess-evpn-igmp-mld-proxy-00.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 == 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. An IGMP Join Synch route is advertised with an ES-Import Route Target extended community whose value is set to the ESI for the ES on which the IGMP Join was received. == 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. An IGMP Join Synch route is advertised with an ES-Import Route Target extended community whose value is set to the ESI for the ES on which the IGMP Join was received. -- The document date (March 27, 2017) is 2584 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 104, but not defined == Missing Reference: 'ES' is mentioned on line 539, but not defined == Missing Reference: 'EVI' is mentioned on line 947, but not defined == Missing Reference: 'BD' is mentioned on line 947, but not defined == Missing Reference: 'RFC2236' is mentioned on line 491, but not defined == Missing Reference: 'RFC4364' is mentioned on line 901, but not defined == Unused Reference: 'RFC4360' is defined on line 1031, but no explicit reference was found in the text == Unused Reference: 'ETREE-FMWK' is defined on line 1039, but no explicit reference was found in the text == Unused Reference: 'PBB-EVPN' is defined on line 1043, 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 (~~), 14 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: September 27, 2017 March 27, 2017 14 IGMP and MLD Proxy for EVPN 15 draft-ietf-bess-evpn-igmp-mld-proxy-00 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) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.1 Proxy Reporting . . . . . . . . . . . . . . . . . . . . . . 5 70 2.1.1 IGMP Membership Report Advertisement in BGP . . . . . . 5 71 2.1.1 IGMP Leave Group Advertisement in BGP . . . . . . . . . 7 72 2.2 Proxy Querier . . . . . . . . . . . . . . . . . . . . . . . 8 73 3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.1 PE with only attached hosts/VMs for a given subnet . . . . . 9 75 3.2 PE with mixed of attached hosts/VMs and multicast source . . 10 76 3.3 PE with mixed of attached hosts/VMs, multicast source and 77 router . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 4 All-Active Multi-Homing . . . . . . . . . . . . . . . . . . . . 10 79 4.1 Local IGMP Join Synchronization . . . . . . . . . . . . . . 11 80 4.2 Local IGMP Leave Group Synchronization . . . . . . . . . . . 11 81 4.2.1 Remote Leave Group Synchronization . . . . . . . . . . . 12 82 4.2.2 Common Leave Group Synchronization . . . . . . . . . . . 13 83 5 Single-Active Multi-Homing . . . . . . . . . . . . . . . . . . . 13 84 6 Discovery of Selective P-Tunnel Types . . . . . . . . . . . . . 13 85 7 BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 7.1 Selective Multicast Ethernet Tag Route . . . . . . . . . . . 15 87 7.1.1 Constructing the Selective Multicast route . . . . . . . 16 88 7.2 IGMP Join Synch Route . . . . . . . . . . . . . . . . . . . 17 89 7.2.1 Constructing the IGMP Join Synch Route . . . . . . . . 19 90 7.3 IGMP Leave Synch Route . . . . . . . . . . . . . . . . . . . 20 91 7.3.1 Constructing the IGMP Leave Synch Route . . . . . . . . 21 92 7.4 Multicast Flags Extended Community . . . . . . . . . . . . . 22 93 7.5 EVI-RT Extended Community . . . . . . . . . . . . . . . . . 23 94 8 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 24 95 9 Security Considerations . . . . . . . . . . . . . . . . . . . . 24 96 10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 97 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 98 11.1 Normative References . . . . . . . . . . . . . . . . . . . 24 99 11.2 Informative References . . . . . . . . . . . . . . . . . . 24 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 102 1 Introduction 104 Ethernet Virtual Private Network (EVPN) solution [RFC 7432] is 105 becoming pervasive in data center (DC) applications for Network 106 Virtualization Overlay (NVO) and DC interconnect (DCI) services, and 107 in service provider (SP) applications for next generation virtual 108 private LAN services. 110 In DC applications, a POD can consist of a collection of servers 111 supported by several TOR and Spine switches. This collection of 112 servers and switches are self contained and may have their own 113 control protocol for intra-POD communication and orchestration. 114 However, EVPN is used as way of standard inter-POD communication for 115 both intra-DC and inter-DC. A subnet can span across multiple PODs 116 and DCs. EVPN provides robust multi-tenant solution with extensive 117 multi-homing capabilities to stretch a subnet (e.g., VLAN) across 118 multiple PODs and DCs. There can be many hosts/VMs (e.g., several 119 hundreds) attached to a subnet that is stretched across several PODs 120 and DCs. 122 These hosts/VMs express their interests in multicast groups on a 123 given subnet/VLAN by sending IGMP membership reports (Joins) for 124 their interested multicast group(s). Furthermore, an IGMP router 125 (e.g., IGMPv1) periodically sends membership queries to find out if 126 there are hosts on that subnet still interested in receiving 127 multicast traffic for that group. The IGMP/MLD Proxy solution 128 described in this draft has three objectives to accomplish: 130 1) Just like ARP/ND suppression mechanism in EVPN to reduce the 131 flooding of ARP messages over EVPN, it is also desired to have a 132 mechanism to reduce the flood of IGMP messages (both Queries and 133 Reports) in EVPN. 135 2) If there is no physical/virtual multicast router attached to the 136 EVPN network for a given (*,G) or (S,G), it is desired for the EVPN 137 network to act as a distributed anycast multicast router for all the 138 hosts attached to that subnet. 140 3) To forward multicast traffic efficiently over EVPN network such 141 that it only gets forwarded to the PEs that have interest in the 142 multicast group(s) - i.e., multicast traffic will not be forwarded to 143 the PEs that have no receivers attached to them for that multicast 144 group. This draft shows how the above objectives are achieved. 146 The first two objectives are achieved by using IGMP/MLD proxy on the 147 PE and the third objective is achieved by setting up a multicast 148 tunnel (ingress replication or P2MP) only among the PEs that have 149 interest in that multicast group(s) based on the trigger from 150 IGMP/MLD proxy processes. The proposed solutions for each of these 151 objectives are discussed in the following sections. 153 1.1 Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 159 2 IGMP Proxy 161 IGMP Proxy mechanism is used to reduce the flooding of IGMP messages 162 over EVPN network similar to ARP proxy used in reducing the flooding 163 of ARP messages over EVPN. It also provides triggering mechanism for 164 the PEs to setup their underlay multicast tunnels. IGMP Proxy 165 mechanism consist of two components: a) Proxy for IGMP Reports and b) 166 Proxy for IGMP Queries. 168 2.1 Proxy Reporting 170 When IGMP protocol is used between host/VMs and its first hop EVPN 171 router (EVPN PE), Proxy-reporting is used by the EVPN PE to summarize 172 (when possible) reports received from downstream hosts and propagate 173 it in BGP to other PEs that are interested in the info. This is done 174 by terminating IGMP Reports in the first hop PE, translating and 175 exchanging the relevant information among EVPN BGP speakers. The 176 information is again translated back to IGMP message at the recipient 177 EVPN speaker. Thus it helps create an IGMP overlay subnet using BGP. 178 In order to facilitate such an overlay, this document also defines a 179 new EVPN route type NLRI (EVPN Selective Multicast Ethernet Tag 180 route) along with its procedures to help exchange and register IGMP 181 multicast groups [section 5]. 183 2.1.1 IGMP Membership Report Advertisement in BGP 185 When a PE wants to advertise an IGMP membership report (Join) using 186 the BGP EVPN route, it follows the following rules: 188 1) When the first hop PE receives several IGMP membership reports 189 (Joins) , belonging to the same IGMP version, from different attached 190 hosts/VMs for the same (*,G) or (S,G), it only sends a single BGP 191 message corresponding to the very first IGMP Join. This is because 192 BGP is a statefull protocol and no further transmission of the same 193 report is needed. If the IGMP Join is for (*,G), then multicast group 194 address along with the corresponding version flag (v1, v2, or v3) are 195 set. In case of IGMPv3, exclude flag also needs to be set to indicate 196 that no source IP address to be excluded (e.g., include all sources 197 "*"). If the IGMP Join is for (S,G), then besides setting multicast 198 group address along with the version flag v3, the source IP address 199 and the include/exclude flag must be set. It should be noted that 200 when advertising the EVPN route for (S,G), the only valid version 201 flag is v3 (i.e., v1 and v2 flags must be set to zero). 203 2) When the first hop PE receives an IGMPv3 Join for (S,G), then the 204 PE checks to see if the source (S) is attached to self. If so, it 205 does not send the corresponding BGP EVPN route advertisement. 207 3) When the first hop PE receives an IGMP version-X Join first for 208 (*,G) and then later it receives an IGMP version-Y Join for the same 209 (*,G), then it will readvertise the same EVPN Selective Multicast 210 route with flag for version-Y set in addition to any previously-set 211 version flag(s). In other words, the first hop PE does not withdraw 212 the EVPN route before sending the new route because the flag field is 213 not part of BGP route key processing. 215 4) When the first hop PE receives an IGMP version-X Join first for 216 (*,G) and then later it receives an IGMPv3 Join for the same 217 multicast group address but for a specific source address S, then the 218 PE will advertise a new EVPN Selective Multicast route with v3 flag 219 set (and v1 and v2 reset). Include/exclude flag also need to be set 220 accordingly. Since source IP address is used as part of BGP route key 221 processing, it is considered as a new BGP route advertisement. 223 5) When a PE receives an EVPN Selective Multicast route with more 224 than one version flag set, it will generate the corresponding IGMP 225 report for (*,G) for each version specified in the flag field. With 226 multiple version flags set, there should be no source IP address in 227 the receive EVPN route. If there is, then an error should be logged. 228 If v3 flag is set (in addition to v1 or v2), then the include/exclude 229 flag needs to indicate "exclude". If not, then an error should be 230 logged. The PE MUST generate an IGMP membership report (Join) for 231 that (*,G) and each IGMP version in the version flag. 233 6) When a PE receives a list of EVPN Selective Multicast NLRIs in its 234 BGP update message, each with a different source IP address and the 235 multicast group address, and the version flag is set to v3, then the 236 PE generates an IGMPv3 membership report with a record corresponding 237 to the list of source IP addresses and the group address along with 238 the proper indication of inclusion/exclusion. 240 7) Upon receiving EVPN Selective Multicast route(s) and before 241 generating the corresponding IGMP Join(s), the PE checks to see 242 whether it has any multicast router's AC(s) (Attachment Circuits 243 connected to multicast routers). If it has router's ACs, then the 244 generated IGMP Join(s) are sent to those ACs. If it doesn't have any 245 router's AC, then no IGMP Join(s) needs to be generated because 246 sending IGMP Joins to other hosts can result in unintentionally 247 preventing a host from joining a specific multicast group for IGMPv1 248 and IGMPv2 - i.e., if the PE does not receive a join from the host it 249 will not forward multicast data to it. Per [RFC4541], when an IGMPv1 250 or IGMPv2 host receives a membership report for a group address that 251 it intends to join, the host will suppress its own membership report 252 for the same group. This message suppression is a requirement for 253 IGMPv1 and IGMPv2 hosts. This is not a problem for hosts running 254 IGMPv3 because there is no suppression of IGMP Membership reports. 256 2.1.1 IGMP Leave Group Advertisement in BGP 258 When a PE wants to withdraw an EVPN Selective Multicast route 259 corresponding to an IGMPv2 Leave Group (Leave) or IGMPv3 "Leave" 260 equivalent message, it follows the following rules: 262 1) For IGMPv1, there is no explicit membership leave; therefore, the 263 PE needs to periodically send out an IGMP membership query to 264 determine whether there is any host left who is interested in 265 receiving traffic directed to this multicast group (this proxy query 266 function will be described in more details in section 2.2). If there 267 is no host left, then the PE re-advertises EVPN Selective Multicast 268 route with the v1 version flag reset. If this is the last version 269 flag to be reset, then instead of re-advertising the EVPN route with 270 all version flags reset, the PE withdraws the EVPN route for that 271 (*,G). 273 2) When a PE receives an IGMPv2 Leave Group or its "Leave" equivalent 274 message for IGMPv3 from its attached host, it checks to see if this 275 host is the last host who is interested in this multicast group by 276 sending a query for the multicast group. If the host was indeed the 277 last one, then the PE re-advertises EVPN Selective Multicast route 278 with the corresponding version flag reset. If this is the last 279 version flag to be reset, then instead of re-advertising the EVPN 280 route with all version flags reset, the PE withdraws the EVPN route 281 for that (*,G). 283 3) When a PE receives an EVPN Selective Multicast route for a given 284 (*,G), it compares the received version flags from the route with its 285 per-PE stored version flags. If the PE finds that a version flag 286 associated with the (*,G) for the remote PE is reset, then the PE 287 generates IGMP Leave for that (*,G) toward its local interface (if 288 any) attached to the multicast router for that multicast group. It 289 should be noted that the received EVPN route should at least have one 290 version flag set. If all version flags are reset, it is an error 291 because the PE should have received an EVPN route withdraw for the 292 last version flag. If the PE receives an EVPN Selective Multicast 293 route withdraw, then it must remove the remote PE from the OIF list 294 associated with that multicast group. 296 4) When a PE receives an EVPN Selective Multicast route withdraw, it 297 removes the remote PE from its OIF list for that multicast group and 298 if there are no more OIF entries for that multicast group (either 299 locally or remotely), then the PE MUST stop responding to queries 300 from the locally attached router (if any). If there is a source for 301 that multicast group, the PE stops sending multicast traffic for that 302 source. 304 2.2 Proxy Querier 306 As mentioned in the previous sections, each PE need to have proxy 307 querier functionality for the following reasons: 309 1) To enable the collection of EVPN PEs providing L2VPN service to 310 act as distributed multicast router with Anycast IP address for all 311 attached hosts/VMs in that subnet. 313 2) To enable suppression of IGMP membership reports and queries over 314 MPLS/IP core. 316 3) To enable generation of query messages locally to their attached 317 host. In case of IGMPv1, the PE needs to send out an IGMP membership 318 query to verify that at least one host on the subnet is still 319 interested in receiving traffic directed to that group. When there is 320 no reply to three consecutive IGMP membership queries, the PE times 321 out the group, stops forwarding multicast traffic to the attached 322 hosts for that (*,G), and sends a EVPN Selective Multicast route 323 associated with that (*,G) with the version-1 flag reset or withdraws 324 that route. 326 3 Operation 328 Consider the EVPN network of figure-1, where there is an EVPN 329 instance configured across the PEs shown in this figure (namely PE1, 330 PE2, and PE3). Lets consider that this EVPN instance consist of a 331 single bridge domain (single subnet) with all the hosts, sources and 332 the multicast router shown in this figure connected to this subnet. 333 PE1 only has hosts connected to it. PE2 has a mix of hosts and 334 multicast source. PE3 has a mix of hosts, multicast source, and 335 multicast router. Further more, lets consider that for (S1,G1), R1 is 336 used as the multicast router but for (S2, G2), distributed multicast 337 router with Anycast IP address is used. The following subsections 338 describe the IGMP proxy operation in different PEs with regard to 339 whether the locally attached devices for that subnet are: 341 - only hosts/VMs 342 - mix of hosts/VMs and multicast source 343 - mix of hosts/VMs, multicast source, and multicast router 345 +--------------+ 346 | | 347 | | 348 +----+ | | +----+ 349 H1:(*,G1)v1 ---| | | | | |---- H6(*,G1)v2 350 H2:(*,G1)v1 ---| PE1| | IP/MPLS | | PE2|---- H7(S2,G2)v3 351 H3:(*,G1)v2 ---| | | Network | | |---- S2 352 H4:(S2,G2)v3 --| | | | | | 353 +----+ | | +----+ 354 | | 355 +----+ | | 356 H5:(S1,G1)v3 --| | | | 357 S1 ---| PE3| | | 358 R1 ---| | | | 359 +----+ | | 360 | | 361 +--------------+ 363 Figure 1: 365 3.1 PE with only attached hosts/VMs for a given subnet 367 When PE1 receives an IGMPv1 Join Report from H1, it does not forward 368 this join to any of its other ports (for this subnet) because all 369 these local ports are associated with the hosts/VMs. PE1 sends an 370 EVPN Multicast Group route corresponding to this join for (*,G1) and 371 setting v1 flag. This EVPN route is received by PE2 and PE3 that are 372 the member of the same EVI. PE3 reconstructs IGMPv1 Join Report from 373 this EVPN BGP route and only sends it to the port(s) with multicast 374 routers attached to it (for that subnet). In this example, PE3 sends 375 the reconstructed IGMPv1 Join Report for (*,G1) to only R1. 376 Furthermore, PE2 although receives the EVPN BGP route, it does not 377 send it to any of its port for that subnet - namely ports associated 378 with H6 and H7. 380 When PE1 receives the second IGMPv1 Join from H2 for the same 381 multicast group (*,G1), it only adds that port to its OIF list but it 382 doesn't send any EVPN BGP route because there is no change in 383 information. However, when it receives the IGMPv2 Join from H3 for 384 the same (*,G1), besides adding the corresponding port to its OIF 385 list, it re-advertises the previously sent EVPN Selective Multicast 386 route with the version-2 flag set. 388 Finally when PE1 receives the IMGMPv3 Join from H4 for (S2,G2), it 389 advertises a new EVPN Selective Multicast route corresponding to it. 391 3.2 PE with mixed of attached hosts/VMs and multicast source 393 The main difference in here is that when PE2 receives IGMPv3 Join 394 from H7 for (S2,G2), it does not advertises it in BGP because PE2 395 knows that S2 is attached to its local AC. PE2 adds the port 396 associated with H7 to its OIF list for (S2,G2). The processing for 397 IGMPv2 received from H6 is the same as the v2 Join described in 398 previous section. 400 3.3 PE with mixed of attached hosts/VMs, multicast source and router 402 The main difference in here relative to the previous two sections is 403 that Join messages received locally needs to be sent to the port 404 associated with router R1. Furthermore, the Joins received via BGP 405 need to be passed to the R1 port but filtered for all other ports. 407 4 All-Active Multi-Homing 409 Because a CE's LAG flow hashing algorithm is unknown, in an All- 410 Active redundancy mode it must be assumed that the CE can send a 411 given IGMP message to any one of the multi-homed PEs, either DF or 412 non-DF - i.e., different IGMP Join messages can arrive at different 413 PEs in the redundancy group and furthermore their corresponding Leave 414 messages can arrive at PEs that are different from the ones received 415 the Join messages. Therefore, all PEs attached to a given ES must 416 coordinate IGMP Join and Leave Group (x, G) state, where x may be 417 either '*' or a particular source S, for each [EVI, broadcast domain 418 (BD)] on that ES. This allows the DF for that [ES, EVI, BD] to 419 correctly advertise or withdraw a Selective Multicast Ethernet Tag 420 (SMET) route for that (x, G) group in that [EVI, BD] when needed. 422 All-Active multihoming PEs for a given ES MUST support IGMP synch 423 procedures described in this section if they want to perform IGMP 424 proxy for hosts connects to that ES. 426 4.1 Local IGMP Join Synchronization 428 When a PE, either DF or non-DF, receives, on a given multihomed ES 429 operating in All-Active redundancy mode, an IGMP Membership Report 430 for (x, G), it determines the [EVI, BD] to which the IGMP Membership 431 Report belongs. If the PE doesn't already have local IGMP Join (x, G) 432 state for that [EVI, BD] on that ES, it instantiates local IGMP Join 433 (x, G) state and advertises a BGP IGMP Join Synch route for that [ES, 434 EVI, BD]. Local IGMP Join (x, G) state refers to IGMP Join (x, G) 435 state that is created as the result of processing an IGMP Membership 436 Report for (x, G). 438 The IGMP Join Synch route carries the ES-Import RT for the ES on 439 which the IGMP Membership Report was received. Thus it may only go 440 to the PEs attached to that ES (and not any other PEs). 442 When a PE, either DF or non-DF, receives an IGMP Join Synch route it 443 installs that route and if it doesn't already have IGMP Join (x, G) 444 state for that [ES, EVI, BD], it instantiates that IGMP Join (x,G) 445 state - i.e., IGMP Join (x, G) state is the union of local IGMP Join 446 (x, G) state and installed IGMP Join Synch route. If the DF is not 447 currently advertising (originating) a SMET route for that (x, G) 448 group in that [EVI, BD], it does so now. 450 When a PE, either DF or non-DF, deletes its local IGMP Join (x, G) 451 state for that [ES, EVI, BD], it withdraws its BGP IGMP Join Synch 452 route for that [ES, EVI, BD]. 454 When a PE, either DF or non-DF, receives the withdrawal of an IGMP 455 Join Synch route from another PE it removes that route. When a PE 456 has no local IGMP Join (x, G) state and it has no installed IGMP Join 457 Synch routes, it removes IGMP Join (x, G) state for that [ES, EVI, 458 BD]. If the DF no longer has IGMP Join (x, G) state for that [EVI, 459 BD] on any ES for which it is DF, it withdraws its SMET route for 460 that (x, G) group in that [EVI, BD]. 462 I.e., A PE advertises an SMET route for that (x, G) group in that 463 [EVI, BD] when it has IGMP Join (x, G) state in that [EVI, BD] on at 464 least one ES for which it is DF and it withdraws that SMET route when 465 it does not have IGMP Join (x, G) state in that [EVI, BD] on any ES 466 for which it is DF. 468 4.2 Local IGMP Leave Group Synchronization 469 When a PE, either DF or non-DF, receives, on a given multihomed ES 470 operating in All-Active redundancy mode, an IGMP Leave Group message 471 for (x, G) from the attached CE, it determines the [EVI, BD] to which 472 the IGMPv2 Leave Group belongs. Regardless of whether it has IGMP 473 Join (x, G) state for that [ES, EVI, BD], it initiates the (x, G) 474 leave group synchronization procedure, which consists of the 475 following steps: 477 1) It computes the Maximum Response Time, which is the duration of 478 (x, G) leave group synchronization procedure. This is the product of 479 two locally configured values, Last Member Query Count and Last 480 Member Query Interval (described in Section 3 of [RFC2236]), plus 481 delta, the time it takes for a BGP advertisement to propagate between 482 the PEs attached to the multihomed ES (delta is a consistently 483 configured value on all PEs attached to the multihomed ES). 485 2) It starts the Maximum Response Time timer. Note that the receipt 486 of subsequent IGMP Leave Group messages or BGP Leave Synch routes for 487 (x, G) do not change the value of a currently running Maximum 488 Response Time timer and are ignored by the PE. 490 3) It initiates the Last Member Query procedure described in Section 491 3 of [RFC2236]; viz, it sends a number of Group-Specific Query (x, G) 492 messages (Last Member Query Count) at a fixed interval (Last Member 493 Query Interval) to the attached CE. 495 4) It advertises an IGMP Leave Synch route for that that [ES, EVI, 496 BD]. This route notifies the other multihomed PEs attached to the 497 given multihomed ES that it has initiated an (x, G) leave group 498 synchronization procedure; i.e., it carries the ES-Import RT for the 499 ES on which the IGMP Leave Group was received. It also contains the 500 Maximum Response Time and the Leave Group Synchronization Procedure 501 Sequence number. The latter identifies the specific (x, G) leave 502 group synchronization procedure initiated by the advertising PE, 503 which increments the value whenever it initiates a procedure. 505 5) When the Maximum Response Timer expires, the PE that has 506 advertised the IGMP Leave Synch route withdraws it. 508 4.2.1 Remote Leave Group Synchronization 510 When a PE, either DF or non-DF, receives an IGMP Leave Synch route it 511 installs that route and it starts a timer for (x, G) on the specified 512 [ES, EVI, BD] whose value is set to the Maximum Response Time in the 513 received IGMP Leave Synch route. Note that the receipt of subsequent 514 IGMPv2 Leave Group messages or BGP Leave Synch routes for (x, G) do 515 not change the value of a currently running Maximum Response Time 516 timer and are ignored by the PE. 518 4.2.2 Common Leave Group Synchronization 520 If a PE attached to the multihomed ES receives an IGMP Membership 521 Report for (x, G) before the Maximum Response Time timer expires, it 522 advertises a BGP IGMP Join Synch route for that [ES, EVI, BD]. If it 523 doesn't already have local IGMP Join (x, G) state for that [ES, EVI, 524 BD], it instantiates local IGMP Join (x, G) state. If the DF is not 525 currently advertising (originating) a SMET route for that (x, G) 526 group in that [EVI, BD], it does so now. 528 If a PE attached to the multihomed ES receives an IGMP Join Synch 529 route for (x, G) before the Maximum Response Time timer expires, it 530 installs that route and if it doesn't already have IGMP Join (x, G) 531 state for that [EVI, BD] on that ES, it instantiates that IGMP Join 532 (x,G) state. If the DF is not currently advertising (originating) a 533 SMET route for that (x, G) group in that [EVI, BD], it does so now. 535 When the Maximum Response Timer expires a PE that has advertised an 536 IGMP Leave Synch route, withdraws it. Any PE attached to the 537 multihomed ES, that started the Maximum Response Time and has no 538 local IGMP Join (x, G) state and no installed IGMP Join Synch routes, 539 it removes IGMP Join (x, G) state for that [ES, EVI, BD]. If the DF 540 no longer has IGMP Join (x, G) state for that [EVI, BD] on any ES for 541 which it is DF, it withdraws its SMET route for that (x, G) group in 542 that [EVI, BD]. 544 5 Single-Active Multi-Homing 546 Note that to facilitate state synchronization after failover, the PEs 547 attached to a multihomed ES operating in Single-Active redundancy 548 mode should also coordinate IGMP Join (x, G) state. In this case all 549 IGMP Join messages are received by the DF and distributed to the non- 550 DF PEs using the procedures described above. 552 6 Discovery of Selective P-Tunnel Types 554 To allow an ingress PE that supports IGMP proxy procedures and SMET 555 route to properly assign a selective P-tunnel supported by the 556 receiving PEs, the ingress PE needs to discovery the types of 557 selective P-tunnels supported by the receiving PEs and select the 558 preferred tunnel type among the ones that it has in common with the 559 receiving PEs. 561 In order to support such discovery mechanism, the Multicast Flags 562 extended community defined in section 7.2 is used. Each PE that 563 supports different types of P-tunnels, marks the corresponding bits 564 and advertise this extended community along with its IMET route. 565 Therefore, the ingress PE can discover types of P-tunnels supported 566 by the receiving PEs. If the ingress PE does not receive this 567 extended community along with an IMET route for a given EVI, it 568 assumes the only P-tunnel type supported by the egress PE, is ingress 569 replication. 571 If besides ingress-replication P-tunnel type, there is no other P- 572 tunnel types in common among the participant PEs for an EVI, then the 573 ingress PE MUST use ingress-replication P-tunnel type. 575 If besides ingress-replication P-tunnel type, there is one ore more 576 P-tunnel types in common among the participant PEs for an EVI, then 577 the ingress PE can choose the P-tunnel type that it prefers. 579 If besides ingress-replication P-tunnel type, there is no other P- 580 tunnel types in common among the participant PEs for an EVI, then the 581 ingress PE MAY choose several different P-tunnel types where the 582 union of them covers the tunnel types supported by the participant 583 PEs for that EVI. This implies that the ingress PE replicates the 584 multicast traffic into different P-tunnels - i.e., to replicate the 585 multicast traffic onto P2MP mLDP P-tunnel and ingress-replication P- 586 tunnel. 588 If an ingress PE uses ingress replication, then for a given (x, G) 589 group in a given [EVI, BD]: 591 1) It sends (x, G) traffic to the set of PEs not supporting IGMP 592 Proxy. This set consists of any PE that has advertised an Inclusive 593 Multicast Tag route for the [EVI, BD] without the "IGMP Proxy 594 Support" flag. 596 2) It sends (x, G) traffic to the set of PEs supporting IGMP Proxy 597 and having listeners for that (x, G) group in that [EVI, BD]. This 598 set consists of any PE that has advertised an Inclusive Multicast Tag 599 route for the [EVI, BD] with the "IGMP Proxy Support" flag and that 600 has advertised an SMET route for that (x, G) group in that [EVI, BD]. 602 If an ingress PE's Selective P-Tunnel for a given [EVI, BD] uses P2MP 603 and all of the PEs in the [EVI, BD] support that tunnel type and 604 IGMP, then for a given (x, G) group in a given [EVI, BD] it sends (x, 605 G) traffic using the Selective P-Tunnel for that (x, G) group in that 606 [EVI, BD]. This tunnel will include those PEs that have advertised 607 an SMET route for that (x, G) group on that [EVI, BD] (for Selective 608 P-tunnel) but it may include other PEs as well (for Aggregate 609 Selective P-tunnel). 611 7 BGP Encoding 613 This document defines three new BGP EVPN routes to carry IGMP 614 membership reports. This route type is known as: 616 + 6 - Selective Multicast Ethernet Tag Route 617 + 7 - IGMP Join Synch Route 618 + 8 - IGMP Leave Synch Route 620 The detailed encoding and procedures for this route type is described 621 in subsequent section. 623 7.1 Selective Multicast Ethernet Tag Route 625 An Selective Multicast Ethernet Tag route type specific EVPN NLRI 626 consists of the following: 628 +---------------------------------------+ 629 | RD (8 octets) | 630 +---------------------------------------+ 631 | Ethernet Tag ID (4 octets) | 632 +---------------------------------------+ 633 | Multicast Source Length (1 octet) | 634 +---------------------------------------+ 635 | Multicast Source Address (variable) | 636 +---------------------------------------+ 637 | Multicast Group Length (1 octet) | 638 +---------------------------------------+ 639 | Multicast Group Address (Variable) | 640 +---------------------------------------+ 641 | Originator Router Length (1 octet) | 642 +---------------------------------------+ 643 | Originator Router Address (variable) | 644 +---------------------------------------+ 645 | Flags (1 octets) (optional) | 646 +---------------------------------------+ 648 For the purpose of BGP route key processing, all the fields are 649 considered to be part of the prefix in the NLRI except for the one- 650 octet optional flag field (if included). The Flags fields are defined 651 as follows: 653 0 1 2 3 4 5 6 7 654 +--+--+--+--+--+--+--+--+ 655 | reserved |IE|v3|v2|v1| 656 +--+--+--+--+--+--+--+--+ 658 The least significant bit, bit 7 indicates support for IGMP version 659 1. 661 The second least significant bit, bit 6 indicates support for IGMP 662 version 2. 664 The third least significant bit, bit 5 indicates support for IGMP 665 version 3. 667 The forth least significant bit, bit 4 indicates whether the (S, G) 668 information carried within the route-type is of Include Group type 669 (bit value 0) or an Exclude Group type (bit value 1). The Exclude 670 Group type bit MUST be ignored if bit 5 is not set. 672 This EVPN route type is used to carry tenant IGMP multicast group 673 information. The flag field assists in distributing IGMP membership 674 interest of a given host/VM for a given multicast route. The version 675 bits help associate IGMP version of receivers participating within 676 the EVPN domain. 678 The include/exclude bit helps in creating filters for a given 679 multicast route. 681 7.1.1 Constructing the Selective Multicast route 683 This section describes the procedures used to construct the Selective 684 Multicast route. Support for this route type is optional. 686 The Route Distinguisher (RD) SHOULD be a Type 1 RD [RFC4364]. The 687 value field comprises an IP address of the PE (typically, the 688 loopback address) followed by a number unique to the PE. 690 The Ethernet Tag ID MUST be set as follows: 692 EVI is VLAN-Based or VLAN Bundle service - set to 0 693 EVI is VLAN-Aware Bundle service without translation - set to 694 the customer VID for the [EVI, BD] 695 EVI is VLAN-Aware Bundle service with translation - set to the 696 normalized Ethernet Tag ID for the [EVI, BD] 697 The Multicast Source length MUST be set to length of multicast source 698 address in bits. In case of a (*, G) Join, the Multicast Source 699 Length is set to 0. 701 The Multicast Source is the Source IP address of the IGMP membership 702 report. In case of a (*, G) Join, this field does not exist. 704 The Multicast Group length MUST be set to length of multicast group 705 address in bits. 707 The Multicast Group is the Group address of the IGMP membership 708 report. 710 The Originator Router Length is the length of the Originator Router 711 address in bits. 713 The Originator Router Address is the IP address of Router Originating 714 the prefix. It should be noted that using the "Originating Router's 715 IP address" field to get the PE IP address, needed for building 716 multicast underlay tunnels, allows for inter-AS operations where BGP 717 next hop can get over written. 719 The Flags field indicates the version of IGMP protocol from which the 720 membership report was received. It also indicates whether the 721 multicast group had INCLUDE or EXCLUDE bit set. 723 IGMP protocol is used to receive group membership information from 724 hosts/VMs by TORs. Upon receiving the hosts/VMs expression of 725 interest of a particular group membership, this information is then 726 forwarded using Ethernet Multicast Source Group Route NLRI. The NLRI 727 also keeps track of receiver's IGMP protocol version and any "source 728 filtering" for a given group membership. All EVPN Selective Multicast 729 Group routes are announced with per-EVI Route Target extended 730 communities. 732 7.2 IGMP Join Synch Route 734 This EVPN route type is used to coordinate IGMP Join (x,G) state for 735 a given [EVI, BD] between the PEs attached to a given ES operating in 736 All-Active (or Single-Active) redundancy mode and it consists of 737 following: 739 +--------------------------------------------------+ 740 | RD (8 octets) | 741 +--------------------------------------------------+ 742 | Ethernet Segment Identifier (10 octets) | 743 +--------------------------------------------------+ 744 | Ethernet Tag ID (4 octets) | 745 +--------------------------------------------------+ 746 | Multicast Source Length (1 octet) | 747 +--------------------------------------------------+ 748 | Multicast Source Address (variable) | 749 +--------------------------------------------------+ 750 | Multicast Group Length (1 octet) | 751 +--------------------------------------------------+ 752 | Multicast Group Address (Variable) | 753 +--------------------------------------------------+ 754 | Originator Router Length (1 octet) | 755 +--------------------------------------------------+ 756 | Originator Router Address (variable) | 757 +--------------------------------------------------+ 758 | Flags (1 octet) | 759 +--------------------------------------------------+ 761 For the purpose of BGP route key processing, all the fields are 762 considered to be part of the prefix in the NLRI except for the one- 763 octet Flags field, whose fields are defined as follows: 765 0 1 2 3 4 5 6 7 766 +--+--+--+--+--+--+--+--+ 767 | reserved |IE|v3|v2|v1| 768 +--+--+--+--+--+--+--+--+ 770 The least significant bit, bit 7 indicates support for IGMP version 771 1. The second least significant bit, bit 6 indicates support for 772 IGMP version 2. The third least significant bit, bit 5 indicates 773 support for IGMP version 3. The fourth least significant bit, bit 4 774 indicates whether the (S, G) information carried within the route- 775 type is of Include Group type (bit value 0) or an Exclude Group type 776 (bit value 1). The Exclude Group type bit MUST be ignored if bit 5 is 777 not set. 779 The Flags field assists in distributing IGMP membership interest of a 780 given host/VM for a given multicast route. The version bits help 781 associate IGMP version of receivers participating within the EVPN 782 domain. The include/exclude bit helps in creating filters for a 783 given multicast route. 785 7.2.1 Constructing the IGMP Join Synch Route 787 This section describes the procedures used to construct the IGMP Join 788 Synch route. Support for this route type is optional. If a PE does 789 not support this route, then it MUST not indicate that it supports 790 'IGMP proxy' in Multicast Flag extended community for the EVIs 791 corresponding to its multi-homed Ethernet Segments. An IGMP Join 792 Synch route is advertised with an ES-Import Route Target extended 793 community whose value is set to the ESI for the ES on which the IGMP 794 Join was received. 796 The Route Distinguisher (RD) SHOULD be a Type 1 RD [RFC4364]. The 797 value field comprises an IP address of the PE (typically, the 798 loopback address) followed by a number unique to the PE. 800 The Ethernet Segment Identifier (ESI) MUST be set to the 10-octet 801 value defined for the ES. 803 The Ethernet Tag ID MUST be set as follows: 805 EVI is VLAN-Based or VLAN Bundle service - set to 0 806 EVI is VLAN-Aware Bundle service without translation - set to 807 the customer VID for the [EVI, BD] 808 EVI is VLAN-Aware Bundle service with translation - set to the 809 normalized Ethernet Tag ID for the [EVI, BD] 811 The Multicast Source length MUST be set to length of multicast source 812 address in bits. In case of a (*, G) Join, the Multicast Source 813 Length is set to 0. 815 The Multicast Source is the Source IP address of the IGMP membership 816 report. In case of a (*, G) Join, this field does not exist. 818 The Multicast Group length MUST be set to length of multicast group 819 address in bits. 821 The Multicast Group is the Group address of the IGMP membership 822 report. 824 The Originator Router Length is the length of the Originator Router 825 address in bits. 827 The Originator Router Address is the IP address of Router Originating 828 the prefix. 830 The Flags field indicates the version of IGMP protocol from which the 831 membership report was received. It also indicates whether the 832 multicast group had INCLUDE or EXCLUDE bit set. 834 7.3 IGMP Leave Synch Route This EVPN route type is used to coordinate 835 IGMP Leave Group (x,G) state for a given [EVI, BD] between the PEs 836 attached to a given ES operating in All-Active (or Single-Active) 837 redundancy mode and it consists of following: 839 +--------------------------------------------------+ 840 | RD (8 octets) | 841 +--------------------------------------------------+ 842 | Ethernet Segment Identifier (10 octets) | 843 +--------------------------------------------------+ 844 | Ethernet Tag ID (4 octets) | 845 +--------------------------------------------------+ 846 | Multicast Source Length (1 octet) | 847 +--------------------------------------------------+ 848 | Multicast Source Address (variable) | 849 +--------------------------------------------------+ 850 | Multicast Group Length (1 octet) | 851 +--------------------------------------------------+ 852 | Multicast Group Address (Variable) | 853 +--------------------------------------------------+ 854 | Originator Router Length (1 octet) | 855 +--------------------------------------------------+ 856 | Originator Router Address (variable) | 857 +--------------------------------------------------+ 858 | Leave Group Synchronization # (4 octets) | 859 +--------------------------------------------------+ 860 | Maximum Response Time (1 octet) | 861 +--------------------------------------------------+ 862 | Flags (1 octet) | 863 +--------------------------------------------------+ 865 For the purpose of BGP route key processing, all the fields are 866 considered to be part of the prefix in the NLRI except for the 867 Maximum Response Time and the one-octet Flags field, whose fields are 868 defined as follows: 870 0 1 2 3 4 5 6 7 871 +--+--+--+--+--+--+--+--+ 872 | reserved |IE|v3|v2|v1| 873 +--+--+--+--+--+--+--+--+ 875 The least significant bit, bit 7 indicates support for IGMP version 876 1. The second least significant bit, bit 6 indicates support for 877 IGMP version 2. The third least significant bit, bit 5 indicates 878 support for IGMP version 3. The fourth least significant bit, bit 4 879 indicates whether the (S, G) information carried within the route- 880 type is of Include Group type (bit value 0) or an Exclude Group type 881 (bit value 1). The Exclude Group type bit MUST be ignored if bit 5 is 882 not set. 884 The Flags field assists in distributing IGMP membership interest of a 885 given host/VM for a given multicast route. The version bits help 886 associate IGMP version of receivers participating within the EVPN 887 domain. The include/exclude bit helps in creating filters for a 888 given multicast route. 890 7.3.1 Constructing the IGMP Leave Synch Route 892 This section describes the procedures used to construct the IGMP Join 893 Synch route. Support for this route type is optional. If a PE does 894 not support this route, then it MUST not indicate that it supports 895 'IGMP proxy' in Multicast Flag extended community for the EVIs 896 corresponding to its multi-homed Ethernet Segments. An IGMP Join 897 Synch route is advertised with an ES-Import Route Target extended 898 community whose value is set to the ESI for the ES on which the IGMP 899 Join was received. 901 The Route Distinguisher (RD) SHOULD be a Type 1 RD [RFC4364]. The 902 value field comprises an IP address of the PE (typically, the 903 loopback address) followed by a number unique to the PE. 905 The Ethernet Segment Identifier (ESI) MUST be set to the 10-octet 906 value defined for the ES. 908 The Ethernet Tag ID MUST be set as follows: 910 EVI is VLAN-Based or VLAN Bundle service - set to 0 911 EVI is VLAN-Aware Bundle service without translation - set to 912 the customer VID for the [EVI, BD] 913 EVI is VLAN-Aware Bundle service with translation - set to the 914 normalized Ethernet Tag ID for the [EVI, BD] 915 The Multicast Source length MUST be set to length of multicast source 916 address in bits. In case of a (*, G) Join, the Multicast Source 917 Length is set to 0. 919 The Multicast Source is the Source IP address of the IGMP membership 920 report. In case of a (*, G) Join, this field does not exist. 922 The Multicast Group length MUST be set to length of multicast group 923 address in bits. 925 The Multicast Group is the Group address of the IGMP membership 926 report. 928 The Originator Router Length is the length of the Originator Router 929 address in bits. 931 The Originator Router Address is the IP address of Router Originating 932 the prefix. 934 The Flags field indicates the version of IGMP protocol from which the 935 membership report was received. It also indicates whether the 936 multicast group had INCLUDE or EXCLUDE bit set. 938 7.4 Multicast Flags Extended Community 940 The 'Multicast Flags' extended community is a new EVPN extended 941 community. EVPN extended communities are transitive extended 942 communities with a Type field value of 6. IANA will assign a Sub- 943 Type from the 'EVPN Extended Community Sub-Types' registry. 945 A PE that supports IGMP proxy on a given [EVI, BD] MUST attach this 946 extended community to the Inclusive Multicast Ethernet Tag (IMET) 947 route it advertises for that [EVI, BD] and it Must set the IGMP Proxy 948 Support flag to 1. Note that an [RFC7432] compliant PE will not 949 advertise this extended community so its absence indicates that the 950 advertising PE does not support IGMP Proxy. 952 The advertisement of this extended community enables more efficient 953 multicast tunnel setup from the source PE specially for ingress 954 replication - i.e., if an egress PE supports IGMP proxy but doesn't 955 have any interest in a given (x, G), it advertises its IGMP proxy 956 capability using this extended community but it does not advertise 957 any SMET route for that (x, G). When the source PE (ingress PE) 958 receives such advertisements from the egress PE, it doesn't not 959 replicate the multicast traffic to that egress PE; however, it does 960 replicate the multicast traffic to the egress PEs that don't 961 advertise such capability even if they don't have any interests in 962 that (x, G). 964 A Multicast Flags extended community is encoded as an 8-octet value, 965 as follows: 967 1 2 3 968 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 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Type=0x06 | Sub-Type=TBD | Flags (2 Octets) | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | Reserved=0 | Tunnel Type | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 The low-order bit of the Flags is defined as the "IGMP Proxy Support" 976 bit. A value of 1 means that the PE supports IGMP Proxy as defined 977 in this document, and a value of 0 means that the PE does not support 978 IGMP proxy. The absence of this extended community also means that 979 the PE doesn not support IGMP proxy. 981 Tunnel type field is a 2-octet field with the bits set according to 982 the following: 984 LSB = 1, indicates the support for RSVP-TE P2MP LSP 985 2nd LSB = 1, indicates the support for P2MP LSP 986 3rd LSB = 1, indicates the support for PIM-SSM 987 4th LSB = 1, indicates the support for PIM-SM 988 5th LSB = 1, indicates the support for BIDIR-PIM 989 6th LSB = 1, indicates the support for mLDP MP2MP LSP 991 7.5 EVI-RT Extended Community 993 The 'EVI-RT' extended community is a new EVPN extended community. 994 EVPN extended communities are transitive extended communities with a 995 Type field value of 6. IANA will assign a Sub-Type from the 'EVPN 996 Extended Community Sub-Types' registry. 998 A PE that supports IGMP synch procedures for All-Active (or Single- 999 Active) multi-homed ES, MUST attach this extended community to either 1000 IGMP Join Synch route (sec 7.2) or IGMP Leave Synch route (sec 7.3). 1001 This extended community carries the RT associated with the EVI so 1002 that the receiving PE can identify the EVI properly. The reason 1003 standard format RT is not used, is to avoid distribution of these 1004 routes beyond the group of multihoming PEs for that ES. 1006 1 2 3 1007 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 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | Type=0x06 | Sub-Type=TBD | RT associated with EVI | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | RT associated with the EVI (cont.) | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 8 Acknowledgement 1016 9 Security Considerations 1018 Same security considerations as [RFC7432]. 1020 10 IANA Considerations 1022 Allocation of Extended Community Type and Sub-Type for EVPN. 1024 11 References 1026 11.1 Normative References 1028 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1029 Requirement Levels", BCP 14, RFC 2119, March 1997. 1031 [RFC4360] S. Sangli et al, ""BGP Extended Communities Attribute", 1032 February, 2006. 1034 [RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", February, 1035 2015. 1037 11.2 Informative References 1039 [ETREE-FMWK] Key et al., "A Framework for E-Tree Service over MPLS 1040 Network", draft-ietf-l2vpn-etree-frwk-03, work in progress, September 1041 2013. 1043 [PBB-EVPN] Sajassi et al., "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn- 1044 05.txt, work in progress, October, 2013. 1046 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 1047 "Considerations for IGMP and MLD snooping PEs", RFC 4541, 2006. 1049 Authors' Addresses 1051 Ali Sajassi 1052 Cisco 1053 Email: sajassi@cisco.com 1055 Samir Thoria 1056 Cisco 1057 Email: sthoria@cisco.com 1059 Keyur Patel 1060 Cisco 1061 Email: keyur@arrcus.com 1063 Derek Yeung 1064 Cisco 1065 Email: derek@arrcus.com 1067 John Drake 1068 Juniper 1069 Email: jdrake@juniper.net 1071 Wen Lin 1072 Juniper 1073 Email: wlin@juniper.net