idnits 2.17.1 draft-skr-bess-evpn-redundant-mcast-source-01.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 private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2019) is 1755 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) == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-03 == Outdated reference: A later version (-11) exists of draft-ietf-bess-evpn-irb-mcast-02 == Outdated reference: A later version (-15) exists of draft-ietf-bess-mvpn-fast-failover-06 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup J. Rabadan, Ed. 3 Internet Draft J. Kotalwar 4 S. Sathappan 5 Intended status: Standards Track Nokia 7 Z. Zhang 8 W. Lin 9 Juniper 11 E. Rosen 12 Individual 14 Expires: January 6, 2020 July 5, 2019 16 Multicast Source Redundancy in EVPN Networks 17 draft-skr-bess-evpn-redundant-mcast-source-01 19 Abstract 21 EVPN supports intra and inter-subnet IP multicast forwarding. 22 However, EVPN (or conventional IP multicast techniques for that 23 matter) do not have a solution for the case where: a) a given 24 multicast group carries more than one flow (i.e., more than one 25 source), and b) it is desired that each receiver gets only one of the 26 several flows. Existing multicast techniques assume there are no 27 redundant sources sending the same flow to the same IP multicast 28 group, and, in case there were redundant sources, the receiver's 29 application would deal with the received duplicated packets. This 30 document extends the existing EVPN specifications and assumes that IP 31 Multicast source redundancy may exist. It also assumes that, in case 32 two or more sources send the same IP Multicast flows into the tenant 33 domain, the EVPN PEs need to avoid that the receivers get packet 34 duplication by following the described procedures. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html 57 This Internet-Draft will expire on January 6, 2020. 59 Copyright Notice 61 Copyright (c) 2019 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 78 1.2 Background on IP Multicast Delivery in EVPN Networks . . . . 6 79 1.2.1 Intra-subnet IP Multicast Forwarding . . . . . . . . . . 6 80 1.2.2 Inter-subnet IP Multicast Forwarding . . . . . . . . . . 7 81 1.3 Multi-Homed IP Multicast Sources in EVPN . . . . . . . . . . 9 82 1.4 The Need for Redundant IP Multicast Sources in EVPN . . . . 11 83 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 11 84 3. BGP EVPN Extensions . . . . . . . . . . . . . . . . . . . . . . 13 85 4. Warm Standby (WS) Solution for Redundant G-Sources . . . . . . 14 86 4.1 WS Example in an OISM Network . . . . . . . . . . . . . . . 16 87 4.2 WS Example in a Single-BD Tenant Network . . . . . . . . . . 18 89 5. Hot Standby (HS) Solution for Redundant G-Sources . . . . . . . 19 90 5.1 Use of BFD in the HS Solution . . . . . . . . . . . . . . . 22 91 5.2 HS Example in an OISM Network . . . . . . . . . . . . . . . 22 92 5.3 HS Example in a Single-BD Tenant Network . . . . . . . . . . 27 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 27 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27 95 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 96 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 97 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 98 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 28 99 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 102 1. Introduction 104 Intra and Inter-subnet IP Multicast forwarding are supported in EVPN 105 networks. [IGMP-PROXY] describes the procedures required to optimize 106 the delivery of IP Multicast flows when Sources and Receivers are 107 connected to the same EVPN BD (Broadcast Domain), whereas [OISM] 108 specifies the procedures to support Inter-subnet IP Multicast in a 109 tenant network. Inter-subnet IP Multicast means that IP Multicast 110 Source and Receivers of the same multicast flow are connected to 111 different BDs of the same tenant. 113 [IGMP-PROXY], [OISM] or conventional IP multicast techniques do not 114 have a solution for the case where a given multicast group carries 115 more than one flow (i.e., more than one source) and it is desired 116 that each receiver gets only one of the several flows. Multicast 117 techniques assume there are no redundant sources sending the same 118 flows to the same IP multicast group, and, in case there were 119 redundant sources, the receiver's application would deal with the 120 received duplicated packets. 122 As a workaround in conventional IP multicast (PIM or MVPN networks), 123 if all the redundant sources are given the same IP address, each 124 receiver will get only one flow. The reason is that, in conventional 125 IP multicast, (S,G) state is always created by the RP, and sometimes 126 by the Last Hop Router (LHR). The (S,G) state always binds the (S,G) 127 flow to a source-specific tree, rooted at the source IP address. If 128 multiple sources have the same IP address, one may end up with 129 multiple (S,G) trees. However, the way the trees are constructed 130 ensures that any given LHR or RP is on at most one of them. The use 131 of an anycast address assigned to multiple sources may be useful for 132 warm standby redundancy solutions. However, on one hand, it's not 133 really helpful for hot standby redundancy solutions and on the other 134 hand, configuring the same IP address (in particular IPv4 address) in 135 multiple sources may bring issues if the sources need to be reached 136 by IP unicast traffic or if the sources are attached to the same 137 Broadcast Domain. 139 In addition, in the scenario where several G-sources are attached via 140 EVPN/OISM, there is not necessarily any (S,G) state created for the 141 redundant sources. The LHRs may have only (*,G) state, and there may 142 not be an RP (creating (S,G) state) either. Therefore, this document 143 extends the above two specifications and assumes that IP Multicast 144 source redundancy may exist. It also assumes that, in case two or 145 more sources send the same IP Multicast flows into the tenant domain, 146 the EVPN PEs need to avoid that the receivers get packet 147 duplication. 149 The solution provides support for Warm Standby (WS) and Hot Standby 150 (HS) redundancy. WS is defined as the redundancy scenario in which 151 the upstream PEs attached to the redundant sources of the same 152 tenant, make sure that only one source of the same flow can send 153 multicast to the interested downstream PEs at the same time. In HS 154 the upstream PEs forward the redundant multicast flows to the 155 downstream PEs, and the downstream PEs make sure only one flow is 156 forwarded to the interested attached receivers. 158 1.1 Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in BCP 163 14 [RFC2119] [RFC8174] when, and only when, they appear in all 164 capitals, as shown here. 166 o OISM: Optimized Inter-Subnet Multicast, as in [OISM]. 168 o Broadcast Domain (BD): an emulated ethernet, such that two systems 169 on the same BD will receive each other's link-local broadcasts. In 170 this document, BD also refers to the instantiation of a Broadcast 171 Domain on an EVPN PE. An EVPN PE can be attached to one or multiple 172 BDs of the same tenant. 174 o Designated Forwarder (DF): as defined in [RFC7432], an ethernet 175 segment may be multi-homed (attached to more than one PE). An 176 ethernet segment may also contain multiple BDs, of one or more 177 EVIs. For each such EVI, one of the PEs attached to the segment 178 becomes that EVI's DF for that segment. Since a BD may belong to 179 only one EVI, we can speak unambiguously of the BD's DF for a given 180 segment. 182 o Upstream PE: in this document an Upstream PE is referred to as the 183 EVPN PE that is connected to the IP Multicast source or closest to 184 it. It receives the IP Multicast flows on local ACs (Attachment 185 Circuits). 187 o Downstream PE: in this document a Downstream PE is referred to as 188 the EVPN PE that is connected to the IP Multicast receivers and 189 gets the IP Multicast flows from remote EVPN PEs. 191 o G-traffic: any frame with an IP payload whose IP Destination 192 Address (IP DA) is a multicast group G. 194 o G-source: any system sourcing traffic to G. 196 o SFG: Single Flow Group, i.e., a multicast group address G which 197 represents traffic that contains only a single flow. However, 198 multiple sources - with the same or different IP - may be 199 transmitting an SFG. 201 o Redundant G-source: a host or router that transmits an SFG in a 202 tenant network where there are more hosts or routers transmitting 203 the same SFG. Redundant G-sources for the same SFG SHOULD have 204 different IP addresses, although they MAY have the same IP address 205 when in different BDs of the same tenant network. Redundant G- 206 sources are assumed NOT to be "bursty" in this document (typical 207 example are Broadcast TV G-sources or similar). 209 o P-tunnel: Provider tunnel refers to the type of tree a given 210 upstream EVPN PE uses to forward multicast traffic to downstream 211 PEs. Examples of P-tunnels supported in this document are Ingress 212 Replication (IR), Assisted Replication (AR), BIER, mLDP or P2MP 213 RSVP-TE. 215 o Inclusive Multicast Tree or Inclusive Provider Multicast Service 216 Interface (I-PMSI): defined in [RFC6513], in this document it is 217 applicable only to EVPN and refers to the default multicast tree 218 for a given BD. All the EVPN PEs that are attached to a specific BD 219 belong to the I-PMSI for the BD. The I-PMSI trees are signaled by 220 EVPN Inclusive Multicast Ethernet Tag (IMET) routes. 222 o Selective Multicast Tree or Selective Provider Multicast Service 223 Interface (S-PMSI): defined in [RFC6513], in this document it is 224 applicable only to EVPN and refers to the multicast tree to which 225 only the interested PEs of a given BD belong to. There are two 226 types of EVPN S-PMSIs: 228 - EVPN S-PMSIs that require the advertisement of S-PMSI AD routes 229 from the upstream PE, as in [EVPN-BUM]. The interested downstream 230 PEs join the S-PMSI tree as in [EVPN-BUM]. 232 - EVPN S-PMSIs that don't require the advertisement of S-PMSI AD 233 routes. They use the forwarding information of the IMET routes, 234 but upstream PEs send IP Multicast flows only to downstream PEs 235 issuing Selective Multicast Ethernet Tag (SMET) routes for the 236 flow. These S-PMSIs are only supported with the following P- 237 tunnels: Ingress Replication (IR), Assisted Replication (AR) and 238 BIER. 240 This document also assumes familiarity with the terminology of 241 [RFC7432], [RFC4364], [RFC6513], [RFC6514], [IGMP-PROXY], [OISM], 242 [EVPN-RT5] and [EVPN-BUM]. 244 1.2 Background on IP Multicast Delivery in EVPN Networks 246 IP Multicast is all about forwarding a single copy of a packet from a 247 source S to a group of receivers G along a multicast tree. That 248 multicast tree can be created in an EVPN tenant domain where S and 249 the receivers for G are connected to the same BD or different BD. In 250 the former case, we refer to Intra-subnet IP Multicast forwarding, 251 whereas the latter case will be referred to as Inter-subnet IP 252 Multicast forwarding. 254 1.2.1 Intra-subnet IP Multicast Forwarding 256 When the source S1 and receivers interested in G1 are attached to the 257 same BD, the EVPN network can deliver the IP Multicast traffic to the 258 receivers in two different ways (Figure 1): 260 S1 + S1 + 261 (a) + | (b) + | 262 | | (S1,G1) | | (S1,G1) 263 PE1 | | PE1 | | 264 +-----+ v +-----+ v 265 |+---+| |+---+| 266 ||BD1|| ||BD1|| 267 |+---+| |+---+| 268 +-----+ +-----+ 269 +-------|-------+ +-------| 270 | | | | | 271 v v v v v 272 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 273 |+---+| |-----| |-----| |+---+| |+---+| |+---+| 274 ||BD1|| ||BD1|| ||BD1|| ||BD1|| ||BD1|| ||BD1|| 275 |+---+| |-----| |-----| |+---+| |+---+| |+---+| 276 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 277 PE2| PE3| PE4| PE2| PE3| PE4 278 - | - - - | - | - | - - - | - 279 | | | | | | | | | 280 v v v v v 281 | R1 R2 | R3 | R1 R2 | R3 282 - - - G1- - - - - - G1- - - 284 Figure 1 - Intra-subnet IP Multicast 286 Model (a) illustrated in Figure 1 is referred to as IP Multicast 287 delivery as BUM traffic. This way of delivering IP Multicast traffic 288 does not require any extensions to [RFC7432], however, it sends the 289 IP Multicast flows to non-interested receivers, such as e.g., R3 in 290 Figure 1. In this example, downstream PEs can snoop IGMP/MLD messages 291 from the receivers so that layer-2 multicast state is created and, 292 for instance, PE4 can avoid sending (S1,G1) to R3, since R3 is not 293 interested in (S1,G1). 295 Model (b) in Figure 1 uses an S-PMSI to optimize the delivery of the 296 (S1,G1) flow. For instance, assuming PE1 uses IR, PE1 sends (S1,G1) 297 only to the downstream PEs that issued an SMET route for (S1,G1), 298 that is, PE2 and PE3. In case PE1 uses any P-tunnel different than 299 IR, AR or BIER, PE1 will advertise an S-PMSI A-D route for (S1,G1) 300 and PE2/PE2 will join that tree. 302 Procedures for Model (b) are specified in [IGMP-PROXY]. 304 1.2.2 Inter-subnet IP Multicast Forwarding 306 If the source and receivers are attached to different BDs of the same 307 tenant domain, the EVPN network can also use Inclusive or Selective 308 Trees as depicted in Figure 2, models (a) and (b) respectively. 310 S1 + S1 + 311 (a) + | (b) + | 312 | | (S1,G1) | | (S1,G1) 313 PE1 | | PE1 | | 314 +-----+ v +-----+ v 315 |+---+| |+---+| 316 ||BD1|| ||BD1|| 317 |+---+| |+---+| 318 +-----+ +-----+ 319 +-------|-------+ +-------| 320 | | | | | 321 v v v v v 322 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 323 |+---+| |+---+| |+---+| |+---+| |+---+| |+---+| 324 ||SBD|| ||SBD|| ||SBD|| ||SBD|| ||SBD|| ||SBD|| 325 |+-|-+| |+-|-+| |+---+| |+-|-+| |+-|-+| |+---+| 326 | VRF | | VRF | | VRF | | VRF | | VRF | | VRF | 327 |+-v-+| |+-v-+| |+---+| |+-v-+| |+-v-+| |+---+| 328 ||BD2|| ||BD3|| ||BD4|| ||BD2|| ||BD3|| ||BD4|| 329 |+-|-+| |+-|-+| |+---+| |+-|-+| |+-|-+| |+---+| 330 +--|--+ +--|--+ +-----+ +--|--+ +--|--+ +-----+ 331 PE2| PE3| PE4 PE2| PE3| PE4 332 - | - - - | - - | - - - | - 333 | | | | | | | | 334 v v v v 335 | R1 R2 | R3 | R1 R2 | R3 336 - - - G1- - - - - - G1- - - 338 Figure 2 - Inter-subnet IP Multicast 340 [OISM] specifies the procedures to optimize the Inter-subnet 341 Multicast forwarding in an EVPN network. The IP Multicast flows are 342 always sent in the context of the source BD. As described in [OISM], 343 if the downstream PE is not attached to the source BD, the IP 344 Multicast flow is received on the SBD (Supplementary Broadcast 345 Domain), as in the example in Figure 2. 347 [OISM] supports Inclusive or Selective Multicast Trees, and as 348 explained in section 1.3.1 "Intra-subnet IP Multicast Forwarding", 349 the Selective Multicast Trees are setup in a different way, depending 350 on the P-tunnel being used by the source BD. As an example, model (a) 351 in Figure 2 illustrates the use of an Inclusive Multicast Tree for 352 BD1 on PE1. Since the downstream PEs are not attached to BD1, they 353 will all receive (S1,G1) in the context of the SBD and will locally 354 route the flow to the local ACs. Model (b) uses a similar forwarding 355 model, however PE1 sends the (S1,G1) flow in a Selective Multicast 356 Tree. If the P-tunnel is IR, AR or BIER, PE1 does not need to 357 advertise an S-PMSI A-D route. 359 [OISM] is a superset of the procedures in [IGMP-PROXY], in which 360 sources and receivers can be in the same or different BD of the same 361 tenant. [OISM] ensures every upstream PE attached to a source will 362 learn of all other PEs (attached to the same Tenant Domain) that have 363 interest in a particular set of flows. This is because the downstream 364 PEs advertise SMET routes for a set of flows with the SBD's Route 365 Target and they are imported by all the Upstream PEs of the tenant. 366 As a result of that, inter-subnet multicasting can be done within the 367 Tenant Domain, without requiring any Rendezvous Points (RP), shared 368 trees, UMH selection or any other complex aspects of conventional 369 multicast routing techniques. 371 1.3 Multi-Homed IP Multicast Sources in EVPN 373 Contrary to conventional multicast routing technologies, multi-homing 374 PEs attached to the same source can never create IP Multicast packet 375 duplication if the PEs use a multi-homed Ethernet Segment (ES). 376 Figure 3 illustrates this by showing two multi-homing PEs (PE1 and 377 PE2) that are attached to the same source (S1). We assume that S1 is 378 connected to an all-active ES by a layer-2 switch (SW1) with a LAG to 379 PE1 and PE2. 381 S1 382 | 383 v 384 +-----+ 385 | SW1 | 386 +-----+ 387 +---- | | 388 (S1,G1)| +----+ +----+ 389 IGMP | | all-active | 390 J(S1,G1) PE1 v | ES-1 | PE2 391 +----> +-----------|---+ +---|-----------+ 392 | +---+ +---+ | | +---+ | 393 R1 <-----|BD2| |BD1| | | |BD1| | 394 | +---+---+---+ | | +---+---+ | 395 +----| |VRF| | | | |VRF| |----+ 396 | | +---+---+ | | | +---+---+ | | 397 | | |SBD| | | | |SBD| | | 398 | | +---+ | | | +---+ | | 399 | +------------|--+ +---------------+ | 400 | | | 401 | | | 402 | | | 403 | EVPN | ^ | 404 | OISM v PE3 | SMET | 405 | +---------------+ | (*,G1) | 406 | | +---+ | | | 407 | | |SBD| | | 408 | | +---+---+ | | 409 +--------------| |VRF| |----------------+ 410 | +---+---+---+ | 411 | |BD2| |BD3| | 412 | +-|-+ +-|-+ | 413 +---|-------|---+ 414 ^ | | ^ 415 IGMP | v v | IGMP 416 J(*,G1) | R2 R3 | J(S1,G1) 418 Figure 3 - All-active Multi-homing and OISM 420 When receiving the (S1,G1) flow from S1, SW1 will choose only one 421 link to send the flow, as per [RFC7432]. Assuming PE1 is the 422 receiving PE on BD1, the IP Multicast flow will be forwarded as soon 423 as BD1 creates multicast state for (S1,G1) or (*,G1). In the example 424 of Figure 3, receivers R1, R2 and R3 are interested in the multicast 425 flow to G1. R1 will receive (S1,G1) directly via the IRB interface as 426 per [OISM]. Upon receiving IGMP reports from R2 and R3, PE3 will 427 issue an SMET (*,G1) route that will create state in PE1's BD1. PE1 428 will therefore forward the IP Multicast flow to PE3's SBD and PE3 429 will forward to R2 and R3, as per [OISM] procedures. 431 When IP Multicast source multi-homing is required, EVPN multi-homed 432 Ethernet Segments MUST be used. EVPN multi-homing guarantees that 433 only one Upstream PE will forward a given multicast flow at the time, 434 avoiding packet duplication at the Downstream PEs. In addition, the 435 SMET route for a given flow creates state in all the multi-homing 436 Upstream PEs. Therefore, in case of failure on the Upstream PE 437 forwarding the flow, the backup Upstream PE can forward the flow 438 immediately. 440 This document assumes that multi-homing PEs attached to the same 441 source always use multi-homed Ethernet Segments. 443 1.4 The Need for Redundant IP Multicast Sources in EVPN 445 While multi-homing PEs to the same IP Multicast G-source provides 446 certain level of resiliency, multicast applications are often 447 critical in the Operator's network and greater level of redundancy is 448 required. This document assumes that: 450 a) Redundant G-sources for an SFG may exist in the EVPN tenant 451 network. A Redundant G-source is a host or a router that sends an 452 SFG in a tenant network where there is another host or router 453 sending traffic to the same SFG. 455 b) Those redundant G-sources may be in the same BD or different BDs 456 of the tenant. There must not be restrictions imposed on the 457 location of the receiver systems either. 459 c) The redundant G-sources can be single-homed to only one EVPN PE or 460 multi-homed to multiple EVPN PEs. 462 d) The EVPN PEs must avoid duplication of the same SFG on the 463 receiver systems. 465 2. Solution Overview 467 An SFG is represented as (*,G) if any source that issues multicast 468 traffic to G is a redundant G-source. Alternatively, this document 469 allows an SFG to be represented as (S,G), where S is a prefix of any 470 length. In this case, a source is considered a redundant G-source for 471 the SFG if it is contained in the prefix. This document allows 472 variable length prefixes in the Sources advertised in S-PMSI A-D 473 routes only for the particular application of redundant G-sources. 475 There are two redundant G-source solutions described in this 476 document: 478 o Warm Standby (WS) Solution 479 o Hot Standby (HS) Solution 481 The WS solution is an upstream PE based solution (downstream PEs do 482 not participate in the procedures), in which all the upstream PEs 483 attached to redundant G-sources for an SFG represented by (*,G) or 484 (S,G) will elect a "Single Forwarder" (SF) among themselves. Once a 485 SF is elected, the upstream PEs add an RPF check to the (*,G) or 486 (S,G) state for the SFG: 488 - A non-SF upstream PE discards any (*,G)/(S,G) packets received over 489 a local AC. 491 - The SF accepts and forwards any (*,G)/(S,G) packets it receives 492 over a single local AC (for the SFG). In case (*,G)/(S,G) packets 493 for the SFG are received over multiple local ACs, they will be 494 discarded in all the local ACs but one. The procedure to choose the 495 local AC that accepts packets is a local implementation matter. 497 A failure on the SF will result in the election of a new SF. The 498 Election requires BGP extensions on the existing EVPN routes. These 499 extensions and associated procedures are described in Sections 3 and 500 4 respectively. 502 In the HS solution the downstream PEs are the ones avoiding the SFG 503 duplication. The upstream PEs are aware of the locally attached G- 504 sources and add a unique ESI-label per SFG to the SFG packets 505 forwarded to downstream PEs. The downstream PEs pull the SFG from all 506 the upstream PEs attached to the redundant G-sources and avoid 507 duplication on the receiver systems by adding an RPF check to the 508 (*,G) state for the SFG: 510 - A downstream PE discards any (*,G) packets it receives from the 511 "wrong G-source". 513 - The wrong G-source is identified in the data path by an ESI-label 514 that is different than the ESI-label used for the selected G- 515 source. 517 - Note that the ESI-label is used here for "ingress filtering" (at 518 the egress/downstream PE) as opposed to the [RFC7432] "egress 519 filtering" (at the egress/downstream PE) used in the split-horizon 520 procedures. In [RFC7432] the ESI-label indicates what egress ACs 521 must be skipped when forwarding BUM traffic to the egress. In this 522 document, the ESI-label indicates what ingress traffic must be 523 discarded at the downstream PE. 525 The use of ESI-labels for SFGs forwarded by upstream PEs require some 526 control plane and data plane extensions in the procedures used by 527 [RFC7432] for multi-homing. Upon failure of the selected G-source, 528 the downstream PE will switch over to a different selected G-source, 529 and will therefore change the RPF check for the (*,G) state. The 530 extensions and associated procedures are described in Sections 3 and 531 5 respectively. 533 An operator should use the HS solution if they require a fast fail- 534 over time and the additional bandwidth consumption is acceptable (SFG 535 packets are received multiple times on the downstream PEs). Otherwise 536 the operator should use the WS solution, at the expense of a slower 537 fail-over time in case of a G-source or upstream PE failure. Besides 538 bandwidth efficiency, another advantage of the WS solution is that 539 only the upstream PEs attached to the redundant G-sources for the 540 same SFG need to be upgraded to support the new procedures. 542 This document does not impose the support of both solutions on a 543 system. If one solution is supported, the support of the other 544 solution is OPTIONAL. 546 3. BGP EVPN Extensions 548 This document makes use of the following BGP EVPN extensions: 550 1. SFG flag in the Multicast Flags Extended Community 552 The Single Flow Group (SFG) flag is a new bit requested to IANA 553 out of the registry Multicast Flags Extended Community Flag 554 Values. This new flag is set for S-PMSI A-D routes that carry a 555 (*,G)/(S,G) SFG in the NLRI. 557 2. ESI Label Extended Community is used in S-PMSI A-D routes 559 The HS solution requires the advertisement of one or more ESI 560 Label Extended Communities [RFC7432] that encode the Ethernet 561 Segment Identifier(s) associated to an S-PMSI A-D (*,G)/(S,G) 562 route that advertises the presence of an SFG. Only the ESI Label 563 value in the extended community is relevant to the procedures in 564 this document. The Flags field in the extended community will be 565 advertised as 0x00 and ignored on reception. [RFC7432] specifies 566 that the ESI Label Extended Community is advertised along with the 567 A-D per ES route. This documents extends the use of this extended 568 community so that it can be advertised multiple times (with 569 different ESI values) along with the S-PMSI A-D route. 571 4. Warm Standby (WS) Solution for Redundant G-Sources 573 The general procedure is described as follows: 575 1. Configuration of the upstream PEs 577 Upstream PEs (possibly attached to redundant G-sources) need to be 578 configured to know which groups are carrying only flows from 579 redundant G-sources, that is, the SFGs in the tenant domain. They 580 will also be configured to know which local BDs may be attached to a 581 redundant G-source. The SFGs can be configured for any source, E.g., 582 SFG for "*", or for a prefix that contains multiple sources that will 583 issue the same SFG, i.e., "10.0.0.0/30". In the latter case sources 584 10.0.0.1 and 10.0.0.2 are considered as Redundant G-sources, whereas 585 10.0.0.10 is not considered a redundant G-source for the same SFG. 587 As an example: 589 - PE1 is configured to know that G1 is an SFG for any source and 590 redundant G-sources for G1 may be attached to BD1 or BD2. 591 - Or PE1 can also be configured to know that G1 is an SFG for the 592 sources contained in 10.0.0.0/30, and those redundant G-sources 593 may be attached to BD1 or BD2. 595 2. Signaling the location of a G-source for a given SFG 597 Upon receiving G-traffic for a configured SFG on a BD, an 598 upstream PE configured to follow this procedure, e.g., PE1: 600 a. Originates an S-PMSI A-D (*,G)/(S,G) route for the SFG. An 601 (*,G) route is advertised if the SFG is configured for any 602 source, and an (S,G) route is advertised (where the Source can 603 have any length) if the SFG is configured for a prefix. 605 b. The S-PMSI A-D route is imported by all the PEs attached to the 606 tenant domain. In order to do that, the route will use the SBD- 607 RT (Supplementary Broadcast Domain Route-Target) in addition to 608 the BD-RT of the BD over which the G-traffic is received. The 609 route SHOULD also carry a DF Election Extended Community (EC) 610 and a flag indicating that it conveys an SFG. The DF Election 611 EC and its use is specified in [RFC8584]. 613 c. The above S-PMSI A-D route MAY be advertised with or without 614 PMSI Tunnel Attribute (PTA): 616 - With no PTA if an I-PMSI or S-PMSI A-D with IR/AR/BIER are to 617 be used. 619 - With PTA in any other case. 621 d. The S-PMSI A-D route is triggered by the first packet of the 622 SFG and withdrawn when the flow is not received anymore. 623 Detecting when the G-source is no longer active is a local 624 implementation matter. The use of a timer is RECOMMENDED. The 625 timer is started when the traffic to G1 is not received. Upon 626 expiration of the timer, the PE will withdraw the route. 628 3. Single Forwarder (SF) Election 630 If the PE with a local G-source receives one or more S-PMSI A-D 631 routes for the same SFG from a remote PE, it will run a Single 632 Forwarder (SF) Election based on the information encoded in the DF 633 Election EC. Two S-PMSI A-D routes are considered for the same SFG 634 if they are advertised for the same tenant, and their Multicast 635 Source Length, Multicast Source, Multicast Group Length and 636 Multicast Group fields match. 638 a. A given DF Alg can only be used if all the PEs running the DF 639 Alg have consistent input. For example, in an OISM network, if 640 the redundant G-sources for an SFG are attached to BDs with 641 different Ethernet Tags, the Default DF Election Alg MUST NOT 642 be used. 644 b. In case the there is a mismatch in the DF Election Alg or 645 capabilities advertised by two PEs competing for the SF, the 646 lowest PE IP address (given by the Originator Address in the S- 647 PMSI A-D route) will be used as a tie-breaker. 649 4. RPF check on the PEs attached to a redundant G-source 651 All the PEs with a local G-source for the SFG will add an RPF 652 check to the (*,G)/(S,G) state for the SFG. That RPF check depends 653 on the SF Election result: 655 a. The non-SF PEs discard any (*,G)/(S,G) packets for the SFG 656 received over a local AC. 658 b. The SF accepts any (*,G)/(S,G) packets for the SFG it receives 659 over one (and only one) local AC. 661 The solution above provides redundancy for SFGs and it does not 662 require an upgrade of the downstream PEs (PEs where there is 663 certainty that no redundant G-sources are connected). Other G-sources 664 for non-SFGs may exist in the same tenant domain. This document does 665 not change the existing procedures for non-SFG G-sources. 667 The redundant G-sources can be single-homed or multi-homed to a BD in 668 the tenant domain. Multi-homing does not change the above procedures. 670 Sections 4.1 and 4.2 show two examples of the WS solution. 672 4.1 WS Example in an OISM Network 674 Figure 4 illustrates an example in which S1 and S2 are redundant G- 675 sources for the SFG (*,G1). 677 S1 (Single S2 678 | Forwarder) | 679 (S1,G1)| (S2,G1)| 680 | | 681 PE1 | PE2 | 682 +--------v---+ +--------v---+ 683 S-PMSI | +---+ | | +---+ | S-PMSI 684 (*,G1) | +---|BD1| | | +---|BD2| | (*,G1) 685 Pref200 | |VRF+---+ | | |VRF+---+ | Pref100 686 |SFG |+---+ | | | |+---+ | | SFG| 687 | +----|SBD|--+ | |-----------||SBD|--+ |---+ | 688 v | |+---+ | | |+---+ | | v 689 | +---------|--+ +------------+ | 690 SMET | | | SMET 691 (*,G1) | | (S1,G1) | (*,G1) 692 | +--------+------------------+ | 693 ^ | | | | ^ 694 | | | EVPN | | | 695 | | | OISM | | | 696 | | | | | | 697 PE3 | | PE4 | | PE5 698 +--------v---+ +------------+ | +------------+ 699 | +---+ | | +---+ | | | +---+ | 700 | +---|SBD| |-------| +---|SBD| |--|---| +---|SBD| | 701 | |VRF+---+ | | |VRF+---+ | | | |VRF+---+ | 702 |+---+ | | |+---+ | | | |+---+ | | 703 ||BD3|--+ | ||BD4|--+ | +--->|BD1|--+ | 704 |+---+ | |+---+ | |+---+ | 705 +------------+ +------------+ +------------+ 706 | ^ | ^ 707 | | IGMP | | IGMP 708 R1 | J(*,G1) R3 | J(*,G1) 710 Figure 4 - WS Solution for Redundant G-Sources 712 The WS solution works as follows: 714 1. Configuration of the upstream PEs, PE1 and PE2 716 PE1 and PE2 are configured to know that G1 is an SFG for any 717 source and redundant G-sources for G1 may be attached to BD1 or 718 BD2, respectively. 720 2. Signaling the location of S1 and S2 for (*,G1) 722 Upon receiving (S1,G1) traffic on a local AC, PE1 and PE2 723 originate S-PMSI A-D (*,G1) routes with the SBD-RT, DF Election 724 Extended Community (EC) and a flag indicating that it conveys an 725 SFG. 727 3. Single Forwarder (SF) Election 729 Based on the DF Election EC content, PE1 and PE2 elect an SF for 730 (*,G1). Assuming both PEs agree on e.g., Preference based Election 731 as the algorithm to use [DF-PREF], and PE1 has a higher 732 preference, PE1 becomes the SF for (*,G1). 734 4. RPF check on the PEs attached to a redundant G-source 736 a. The non-SF, PE2, discards any (*,G1) packets received over a 737 local AC. 739 b. The SF, PE1 accepts (*,G1) packets it receives over a one (and 740 only one) local AC. 742 The end result is that, upon receiving reports for (*,G1) or (S,G1), 743 the downstream PEs (PE3 and PE5) will issue SMET routes and will pull 744 the multicast SFG from PE1, and PE1 only. A failure on S1, the AC 745 connected to S1 or PE1 itself will trigger the S-PMSI A-D (*,G1) 746 withdrawal from PE1 and PE2 will be promoted to SF. 748 4.2 WS Example in a Single-BD Tenant Network 750 Figure 5 illustrates an example in which S1 and S2 are redundant G- 751 sources for the SFG (*,G1), however, now all the G-sources and 752 receivers are connected to the same BD1 and there is no SBD. 754 S1 (Single S2 755 | Forwarder) | 756 (S1,G1)| (S2,G1)| 757 | | 758 PE1 | PE2 | 759 +--------v---+ +--------v---+ 760 S-PMSI | +---+ | | +---+ | S-PMSI 761 (*,G1) | |BD1| | | |BD1| | (*,G1) 762 Pref200 | +---+ | | +---+ | Pref100 763 |SFG | | | | | SFG| 764 | +---| | |-----------| |---+ | 765 v | | | | | | | v 766 | +---------|--+ +------------+ | 767 SMET | | | SMET 768 (*,G1) | | (S1,G1) | (*,G1) 769 | +--------+------------------------+ | 770 ^ | | | | ^ 771 | | | EVPN | | | 772 | | | | | | 773 | | | | | | 774 PE3 | | PE4 | | PE5 775 +--------v---+ +------------+ +-|----------+ 776 | +---+ | | +---+ | | | +---+ | 777 | |BD1| |-------| |BD1| |------| +--->|BD1| | 778 | +---+ | | +---+ | | +---+ | 779 | | | | | | 780 | | | | | | 781 | | | | | | 782 +------------+ +------------+ +------------+ 783 | ^ | ^ 784 | | IGMP | | IGMP 785 R1 | J(*,G1) R3 | J(*,G1) 787 Figure 5 - WS Solution for Redundant G-Sources in the same BD 789 The same procedure as in Section 4.1 is valid here, being this a sub- 790 case of the one in Section 4.1. Upon receiving traffic for the SFG 791 G1, PE1 and PE2 advertise the S-PMSI A-D routes with BD1-RT only, 792 since there is no SBD. 794 5. Hot Standby (HS) Solution for Redundant G-Sources 796 If fast-failover time is desired upon the failure of a G-source or PE 797 attached to the G-source, and in spite of the extra bandwidth 798 consumption in the tenant network, the HS solution should be used. 799 The procedure is as follows: 801 1. Configuration of the PEs 803 As in the WS case, the upstream PEs where redundant G-sources may 804 exist need to be configured to know which groups (for any source 805 or a prefix containing the intended sources) are carrying only 806 flows from redundant G-sources, that is, the SFGs in the tenant 807 domain. 809 In addition (and this is not done in WS mode), the individual 810 redundant G-sources for an SFG need to be associated with an 811 Ethernet Segment (ES) on the upstream PEs. This is irrespective of 812 the redundant G-source being multi-homed or single-homed. Even for 813 single-homed redundant G-sources the HS procedure relies on the 814 ESI labels for the RPF check on downstream PEs. The term "S-ESI" 815 is used in this document to refer to an ESI associated to a 816 redundant G-source. 818 Contrary to the WS method (that is transparent to the downstream 819 PEs), the support for the HS procedure in all downstream PEs 820 connected to the receivers in the tenant network is REQUIRED. The 821 downstream PEs do not need to be configured to know the connected 822 SFGs or their ESIs, since they get that information from the 823 upstream PEs. The downstream PEs will locally select an ESI for a 824 given SFG, and will program an RPF check to the (*,G)/(S,G) state 825 for the SFG that will discard (*,G)/(S,G) packets from the rest of 826 the ESIs. The selection of the ESI for the SFG is based on local 827 policy. 829 2. Signaling the location of a G-source for a given SFG and its 830 association to the local ESIs 832 Based on the configuration in step 1, an upstream PE configured to 833 follow the HS procedures: 835 a. Advertises an S-PMSI A-D (*,G)/(S,G) route per each configured 836 SFG. These routes need to be imported by all the PEs of the 837 tenant domain, therefore they will carry the BD-RT and SBD-RT 838 (if the SBD exists). The route also carries the ESI Label 839 Extended Communities needed to convey all the S-ESIs associated 840 to the SFG in the PE. 842 b. The S-PMSI A-D route will convey a PTA in the same cases as in 843 the WS procedure. 845 c. The S-PMSI A-D (*,G)/(S,G) route is triggered by the 846 configuration of the SFG and not by the reception of G-traffic. 848 3. Distribution of DCB (Domain-wide Common Block) ESI-labels and G- 849 source ES routes 851 An upstream PE advertises the corresponding ES, A-D per EVI and A- 852 D per ES routes for the local S-ESIs. 854 a. ES routes are used for regular DF Election for the S-ES. This 855 document does not introduce any change in the procedures 856 related to the ES routes. 858 b. The A-D per EVI and A-D per ES routes MUST include the SBD-RT 859 since they have to be imported by all the PEs in the tenant 860 domain. 862 c. The A-D per ES routes convey the S-ESI labels that the 863 downstream PEs use to add the RPF check for the (*,G)/(S,G) 864 associated to the SFGs. This RPF check requires that all the 865 packets for a given G-source are received with the same S-ESI 866 label value on the downstream PEs. For example, if two 867 redundant G-sources are multi-homed to PE1 and PE2 via S-ES-1 868 and S-ES-2, PE1 and PE2 MUST allocate the same ESI label "Lx" 869 for S-ES-1 and they MUST allocate the same ESI label "Ly" for 870 S-ES-2. In addition, Lx and Ly MUST be different. These ESI 871 labels are Domain-wide Common Block (DCB) labels and follow the 872 allocation procedures in [DCB]. 874 4. Processing of A-D per ES/EVI routes and RPF check on the 875 downstream PEs 877 The A-D per ES/EVI routes are received and imported in all the PEs 878 in the tenant domain. The processing of the A-D per ES/EVI routes 879 on a given PE depends on its configuration: 881 a. The PEs attached to the same BD of the BD-RT that is included 882 in the A-D per ES/EVI routes will process the routes as in 883 [RFC7432] and [RFC8584]. If the receiving PE is attached to the 884 same ES as indicated in the route, [RFC7432] split-horizon 885 procedures will be followed and the DF Election candidate list 886 may be modified as in [RFC8584] if the ES supports the AC-DF 887 capability. 889 b. The PEs that are not attached to the BD-RT but are attached to 890 the SBD of the received SBD-RT, will import the A-D per ES/EVI 891 routes and use them for redundant G-source mass withdrawal, as 892 explained later. 894 c. Upon importing A-D per ES routes corresponding to different S- 895 ESes, a PE MUST select a primary S-ES and add an RPF check to 896 the (*,G)/(S,G) state in the BD or SBD. This RPF check will 897 discard all ingress packets to (*,G)/(S,G) that are not 898 received with the ESI-label of the primary S-ES. The selection 899 of the primary S-ES is a matter of local policy. 901 5. G-traffic forwarding for redundant G-sources and fault detection 903 Assuming there is (*,G) or (S,G) state for the SFG with OIF list 904 entries associated to remote EVPN PEs, upon receiving G-traffic on 905 a S-ES, the upstream PE will add a S-ESI label at the bottom of 906 the stack before forwarding the traffic to the remote EVPN PEs. 907 This label is allocated from a DCB as described in step 3. If P2MP 908 or BIER PMSIs are used, this is not adding any new data path 909 procedures on the upstream PEs (except that the ESI-label is 910 allocated from a DCB). However, if IR/AR are used, this document 911 extends the [RFC7432] procedures by pushing the S-ESI labels not 912 only on packets sent to the PEs that shared the ES but also to the 913 rest of the PEs in the tenant domain. This allows the downstream 914 PEs to receive all the multicast packets from the redundant G- 915 sources with a S-ESI label (irrespective of the PMSI type and the 916 local ESes), and discard any packet that conveys a S-ESI label 917 different from the primary S-ESI label (that is, the label 918 associated to the selected primary S-ES), as discussed in step 4. 920 If the last A-D per EVI or the last A-D per ES route for the 921 primary S-ES is withdrawn, the downstream PE will immediately 922 select a new primary S-ES and will change the RPF check. Note that 923 if the S-ES is re-used for multiple tenant domains by the upstream 924 PEs, the withdrawal of all the A-D per-ES routes for a S-ES 925 provides a mass withdrawal capability that makes a downstream PE 926 to change the RPF check in all the tenant domains using the same 927 S-ES. 929 The withdrawal of the last S-PMSI A-D route for a given 930 (*,G)/(S,G) that represents a SFG SHOULD make the downstream PE 931 remove the S-ESI label based RPF check on (*,G)/(S,G). 933 5.1 Use of BFD in the HS Solution 935 The BGP-BFD Attribute (advertised along with the S-PMSI A-D routes) 936 and similar procedures as the ones described in [MVPN-FAST-FAILOVER] 937 MAY be used to bootstrap multipoint BFD sessions on the downstream 938 PEs. 940 5.2 HS Example in an OISM Network 942 Figure 6 illustrates the HS model in an OISM network. Consider S1 and 943 S2 are redundant G-sources for the SFG (*,G1) in BD1 (any source 944 using G1 is assumed to transmit an SFG). S1 and S2 are (all-active) 945 multi-homed to upstream PEs, PE1 and PE2. The receivers are attached 946 to downstream PEs, PE3 and PE5, in BD3 and BD1, respectively. S1 and 947 S2 are assumed to be connected by a LAG to the multi-homing PEs, and 948 the multicast traffic can use the link to either upstream PE. The 949 diagram illustrates how S1 sends the G-traffic to PE1 and PE1 950 forwards to the remote interested downstream PEs, whereas S2 sends to 951 PE2 and PE2 forwards further. In this HS model, the interested 952 downstream PEs will get duplicate G-traffic from the two G-sources 953 for the same SFG. While the diagram shows that the two flows are 954 forwarded by different upstream PEs, the all-active multi-homing 955 procedures may cause that the two flows come from the same upstream 956 PE. Therefore, finding out the upstream PE for the flow is not enough 957 for the downstream PEs to program the required RPF check to avoid 958 duplicate packets on the receiver. 960 S1(ESI-1) S2(ESI-2) 961 | | 962 | +----------------------+ 963 (S1,G1)| | (S2,G1)| 964 +----------------------+ | 965 PE1 | | PE2 | | 966 +--------v---+ +--------v---+ 967 | +---+ | | +---+ | S-PMSI 968 S-PMSI | +---|BD1| | | +---|BD1| | (*,G1) 969 (*,G1) | |VRF+---+ | | |VRF+---+ | SFG 970 SFG |+---+ | | | |+---+ | | | ESI1,2 971 ESI1,2 +---||SBD|--+ | |-----------||SBD|--+ | |---+ | 972 | | |+---+ | | EVPN |+---+ | | | v 973 v | +---------|--+ OISM +---------|--+ | 974 | | | | 975 | | (S1,G1) | | 976 SMET | +---------+------------------+ | | SMET 977 (*,G1) | | | | | (*,G1) 978 ^ | | +----------------------------+---+ | ^ 979 | | | | (S2,G1) | | | | 980 | | | | | | | | 981 PE3 | | | PE4 | | | PE5 982 +-------v-v--+ +------------+ | | +------------+ 983 | +---+ | | +---+ | | | | +---+ | 984 | +---|SBD| +-------| +---|SBD| |--|-|-| +---|SBD| | 985 | |VRF+---+ | | |VRF+---+ | | | | |VRF+---+ | 986 |+---+ | | |+---+ | | | | |+---+ | | 987 ||BD3|--+ | ||BD4|--+ | | +->|BD1|--+ | 988 |+---+ | |+---+ | +--->+---+ | 989 +------------+ +------------+ +------------+ 990 | ^ | ^ 991 | | IGMP | | IGMP 992 R1 | J(*,G1) R3 | J(*,G1) 994 Figure 6 - HS Solution for Multi-homed Redundant G-Sources in OISM 996 In this scenario, the HS solution works as follows: 998 1. Configuration of the upstream PEs, PE1 and PE2 1000 PE1 and PE2 are configured to know that G1 is an SFG for any 1001 source (a source prefix length could have been configured instead) 1002 and the redundant G-sources for G1 use S-ESIs ESI-1 and ESI-2 1003 respectively. Both ESes are configured in both PEs and the ESI 1004 value can be configured or auto-derived. The ESI-label values are 1005 allocated from a DCB [DCB] and are configured either locally or by 1006 a centralized controller. We assume ESI-1 is configured to use 1007 ESI-label-1 and ESI-2 to use ESI-label-2. 1009 The downstream PEs, PE3, PE4 and PE5 are configured to support HS 1010 mode and select the G-source with e.g., lowest ESI value. 1012 2. PE1 and PE2 advertise S-PMSI A-D (*,G1) and ES/A-D per ES/EVI 1013 routes 1015 Based on the configuration of step 1, PE1 and PE2 advertise an S- 1016 PMSI A-D (*,G1) route each. The route from each of the two PEs 1017 will include TWO ESI Label Extended Communities with ESI-1 and 1018 ESI-2 respectively, as well as BD1-RT plus SBD-RT and a flag that 1019 indicates that (*,G1) is an SFG. 1021 In addition, PE1 and PE2 advertise ES and A-D per ES/EVI routes 1022 for ESI-1 and ESI-2. The A-D per ES and per EVI routes will 1023 include the SBD-RT so that they can be imported by the downstream 1024 PEs that are not attached to BD1, e.g., PE3 and PE4. The A-D per 1025 ES routes will convey ESI-label-1 for ESI-1 (on both PEs) and ESI- 1026 label-2 for ESI-2 (also on both PEs). 1028 3. Processing of A-D per ES/EVI routes and RPF check 1030 PE1 and PE2 received each other's ES and A-D per ES/EVI routes. 1031 Regular [RFC7432] [RFC8584] procedures will be followed for DF 1032 Election and programming of the ESI-labels for egress split- 1033 horizon filtering. PE3/PE4 import the A-D per ES/EVI routes in the 1034 SBD. Since PE3 has created a (*,G1) state based on local interest, 1035 PE3 will add an RPF check to (*,G1) so that packets coming with 1036 ESI-label-2 are discarded (lowest ESI value is assumed to give the 1037 primary S-ES). 1039 4. G-traffic forwarding and fault detection 1041 PE1 receives G-traffic (S1,G1) on ES-1 that is forwarded within 1042 the context of BD1. Irrespective of the tunnel type, PE1 pushes 1043 ESI-label-1 at the bottom of the stack and the traffic gets to PE3 1044 and PE5 with the mentioned ESI-label (PE4 has no local interested 1045 receivers). The G-traffic with ESI-label-1 passes the RPF check 1046 and it is forwarded to R1. In the same way, PE2 sends (S2,G1) with 1047 ESI-label-2, but this G-traffic does not pass the RPF check and 1048 gets discarded at PE3/PE5. 1050 If the link from S1 to PE1 fails, S1 will forward the (S1,G1) 1051 traffic to PE2 instead. PE1 withdraws the ES and A-D routes for 1052 ESI-1. Now both flows will be originated by PE2, however the RPF 1053 checks don't change in PE3/PE5. 1055 If subsequently, the link from S1 to PE2 fails, PE2 also withdraws 1056 the ES and A-D routes for ESI-1. Since PE3 and PE5 have no longer 1057 A-D per ES/EVI routes for ESI-1, they immediately change the RPF 1058 check so that packets with ESI-label-2 are now accepted. 1060 Figure 7 illustrates a scenario where S1 and S2 are single-homed to 1061 PE1 and PE2 respectively. This scenario is a sub-case of the one in 1062 Figure 6. Now ES-1 only exists in PE1, hence only PE1 advertises the 1063 A-D per ES/EVI routes for ESI-1. Similarly, ES-2 only exists in PE2 1064 and PE2 is the only PE advertising A-D routes for ESI-2. The same 1065 procedures as in Figure 6 applies to this use-case. 1067 S1(ESI-1) S2(ESI-2) 1068 | | 1069 (S1,G1)| (S2,G1)| 1070 | | 1071 PE1 | PE2 | 1072 +--------v---+ +--------v---+ 1073 | +---+ | | +---+ | S-PMSI 1074 S-PMSI | +---|BD1| | | +---|BD2| | (*,G1) 1075 (*,G1) | |VRF+---+ | | |VRF+---+ | SFG 1076 SFG |+---+ | | | |+---+ | | | ESI2 1077 ESI1 +---||SBD|--+ | |-----------||SBD|--+ | |---+ | 1078 | | |+---+ | | EVPN |+---+ | | | v 1079 v | +---------|--+ OISM +---------|--+ | 1080 | | | | 1081 | | (S1,G1) | | 1082 SMET | +---------+------------------+ | | SMET 1083 (*,G1) | | | | | (*,G1) 1084 ^ | | +--------------------------------+----+ | ^ 1085 | | | | (S2,G1) | | | | 1086 | | | | | | | | 1087 PE3 | | | PE4 | | | PE5 1088 +-------v-v--+ +------------+ | +------v-----+ 1089 | +---+ | | +---+ | | | +---+ | 1090 | +---|SBD| |-------| +---|SBD| |--|---| +---|SBD| | 1091 | |VRF+---+ | | |VRF+---+ | | | |VRF+---+ | 1092 |+---+ | | |+---+ | | | |+---+ | | 1093 ||BD3|--+ | ||BD4|--+ | +--->|BD1|--+ | 1094 |+---+ | |+---+ | |+---+ | 1095 +------------+ +------------+ +------------+ 1096 | ^ | ^ 1097 | | IGMP | | IGMP 1098 R1 | J(*,G1) R3 | J(*,G1) 1100 Figure 7 - HS Solution for single-homed Redundant G-Sources in OISM 1102 5.3 HS Example in a Single-BD Tenant Network 1104 Irrespective of the redundant G-sources being multi-homed or single- 1105 homed, if the tenant network has only one BD, e.g., BD1, the 1106 procedures of Section 5.2 still apply, only that routes do not 1107 include any SBD-RT and all the procedures apply to BD1 only. 1109 6. Security Considerations 1111 The same Security Considerations described in [OISM] are valid for 1112 this document. 1114 7. IANA Considerations 1116 IANA is requested to allocate a Bit in the Multicast Flags Extended 1117 Community to indicate that a given (*,G) or (S,G) in an S-PMSI A-D 1118 route is associated with an SFG. 1120 8. References 1122 8.1. Normative References 1124 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1125 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 1126 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, 1127 . 1129 [RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in 1130 MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, 1131 . 1133 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1134 Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 1135 6514, DOI 10.17487/RFC6514, February 2012, . 1138 [IGMP-PROXY] Sajassi, A. et al, "IGMP and MLD Proxy for EVPN", June 1139 2019, work-in-progress, draft-ietf-bess-evpn-igmp-mld-proxy-03. 1141 [OISM] Rosen, E. et al, "EVPN Optimized Inter-Subnet Multicast 1142 (OISM) Forwarding", January 2019, work-in-progress, draft-ietf-bess- 1143 evpn-irb-mcast-02. 1145 [RFC8584] Rabadan, J., Mohanty, S., Sajassi, A., Drake, J., Nagaraj, 1146 K., and S. Sathappan, "Framework for Ethernet VPN Designated 1147 Forwarder Election Extensibility", RFC 8584, DOI 10.17487/RFC8584, 1148 April 2019, . 1150 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1151 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1152 1997, . 1154 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1155 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, 1156 . 1158 [DCB] Zhang, Z. et al, "MVPN/EVPN Tunnel Aggregation with Common 1159 Labels", April 2018, work-in-progress, draft-zzhang-bess-mvpn-evpn- 1160 aggregation-label-01. 1162 [MVPN-FAST-FAILOVER] Morin, T., Kebler, R., and G. Mirsky, 1163 "Multicast VPN fast upstream failover", draft-ietf-bess-mvpn-fast- 1164 failover-06 (work in progress), July 2019. 1166 8.2. Informative References 1168 [EVPN-RT5] Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 1169 Sajassi, "IP Prefix Advertisement in EVPN", internet-draft ietf-bess- 1170 evpn-prefix-advertisement-11.txt, May 2018. 1172 [EVPN-BUM] Zhang, Z., Lin, W., Rabadan, J., and K. Patel, "Updates 1173 on EVPN BUM Procedures", internet-draft ietf-bess-evpn-bum-procedure- 1174 updates-06, June 2019. 1176 [DF-PREF] Rabadan, J., Sathappan, S., Przygienda, T., Lin, W., 1177 Drake, J., Sajassi, A., and S. Mohanty, "Preference-based EVPN DF 1178 Election", internet-draft ietf-bess-evpn-pref-df-04.txt, June 2019. 1180 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1181 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, 1182 . 1184 9. Acknowledgments 1186 The authors would like to thank Mankamana Mishra and Ali Sajassi for 1187 their review and valuable comments. 1189 10. Contributors 1190 Authors' Addresses 1192 Jorge Rabadan 1193 Nokia 1194 777 E. Middlefield Road 1195 Mountain View, CA 94043 USA 1196 Email: jorge.rabadan@nokia.com 1198 Senthil Sathappan 1199 Nokia 1200 701 E. Middlefield Road 1201 Mountain View, CA 94043 USA 1202 Email: senthil.sathappan@nokia.com 1204 Jayant Kotalwar 1205 Nokia 1206 701 E. Middlefield Road 1207 Mountain View, CA 94043 USA 1208 Email: jayant.kotalwar@nokia.com 1210 Eric C. Rosen 1211 EMail: erosen52@gmail.com 1213 Zhaohui Zhang 1214 Juniper Networks 1215 EMail: zzhang@juniper.net 1217 Wen Lin 1218 Juniper Networks, Inc. 1219 EMail: wlin@juniper.net