idnits 2.17.1 draft-ietf-bess-extended-evpn-optimized-ir-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([EVPN-AR]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 19, 2020) is 1527 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'EVPN-AR' -- Possible downref: Non-RFC (?) normative reference: ref. 'EVPN-IGMP-PROXY' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS W. Lin, Ed. 3 Internet-Draft S. Sivaraj 4 Intended status: Standards Track V. Garg 5 Expires: August 22, 2020 Juniper Networks, Inc. 6 J. Rabadan 7 Nokia 8 February 19, 2020 10 Extended Procedures for EVPN Optimized Ingress Replication 11 draft-ietf-bess-extended-evpn-optimized-ir-00 13 Abstract 15 [EVPN-AR] specifies an optimized ingress replication solution for 16 more efficient multicast and broadcast delivery in a Network 17 Virtualization Overlay (NVO) network for EVPN. 19 This document extends the optimized ingress replication procedures 20 specified in [EVPN-AR] to overcome the limitation that an AR- 21 REPLICATOR may have. An AR-REPLICATOR may be unable to retain the 22 source IP address or include the expected ESI label that is required 23 for EVPN split horizon filtering when replicating the packet on 24 behalf of its multihomed AR-LEAF. Under this circumstance, the 25 extended procedures specified in this document allows the support of 26 EVPN multihoming on the AR-LEAFs as well as optimized ingress 27 replication for the rest of the EVPN overlay network. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 33 "OPTIONAL" in this document are to be interpreted as described in BCP 34 14 [RFC2119] [RFC8174] when, and only when, they appear in all 35 capitals, as shown here. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on August 22, 2020. 54 Copyright Notice 56 Copyright (c) 2020 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 74 2.1.1. EVPN Multihoming and Split Horizon Filtering Rule . . 3 75 2.2. Optimized-IR and the Need to Maintain the Original Source 76 IP address or Include the ESI Label . . . . . . . . . . . 4 77 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3.1. AR-REPLICATOR Announcing Multihoming Assistant Capability 79 for Optimized-IR . . . . . . . . . . . . . . . . . . . . 5 80 3.2. Multihomed AR-LEAF and Extended-MH AR-REPLICATOR . . . . 6 81 3.3. The Benefit of the Extended Optimized-IR Procedure . . . 7 82 3.4. Support for Mixed AR-REPLICATORs . . . . . . . . . . . . 7 83 4. Extended Optimized-IR Procedure for Supporting Extended-MH 84 AR-REPLICATOR . . . . . . . . . . . . . . . . . . . . . . . . 7 85 4.1. AR-LEAF Procedure . . . . . . . . . . . . . . . . . . . . 8 86 4.1.1. Control Plane Procedure for AR-LEAF . . . . . . . . . 8 87 4.1.2. Forwarding Procedure for AR-LEAF . . . . . . . . . . 9 88 4.2. AR-REPLICATOR Procedure . . . . . . . . . . . . . . . . . 9 89 4.2.1. Control Plane Procedure for AR-REPLICATOR . . . . . . 9 90 4.2.2. Forwarding Procedure for AR-REPLICATOR . . . . . . . 10 91 4.3. RNVE Procedure . . . . . . . . . . . . . . . . . . . . . 10 92 5. AR-LEAF's Peer multihomed NVE in the Extended Optimized-IR 93 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 11 94 6. Multicast Flags Extended Community . . . . . . . . . . . . . 11 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 98 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 101 1. Terminology 103 AR-IP Tunnel 105 An overlay tunnel with a destination IP address of AR-IP that an AR- 106 REPLICATOR advertises in its REPLICATE-AR route. 108 This document heavily uses the terminology specified in [EVPN-AR]. 109 It also uses the terminology specified in [RFC7432] and [RFC8365]. 111 2. Introduction 113 2.1. Background 115 2.1.1. EVPN Multihoming and Split Horizon Filtering Rule 117 This section gives a brief overview of the existing split horizon 118 filtering rules used for EVPN multihoming. 120 [RFC7432] defines the split-horizon filtering rule based on ESI label 121 for EVPN multihoming with MPLS encapsulation, and this filtering rule 122 also applies for EVPN with IP-based encapsulation for MPLS, such as 123 MPLS over GRE or MPLS over UDP. [RFC8365] defines the split horizon 124 filtering rule based on "Local-Bias" for EVPN multihoming with VXLAN 125 encapsulation. 127 When EVPN is used in an NVO network, a Tenant System (TS) may connect 128 to a set of Network Virtualization Edge (NVE) devices through a 129 multihomed Ethernet segment (ES). The split-horizon filtering rule 130 for EVPN all-active multihoming ensures that a Broadcast, Unknown 131 unicast or Multicast (BUM) packet received from an ES that is a part 132 of a multihomed ES is not looped back to the multihomed TS through an 133 egress NVE connected to the same multihomed ES. For EVPN with VXLAN 134 encapsulation, the split-horizon filtering rule is based on the 135 egress NVE examining the source IP address of the BUM packet received 136 from an overlay tunnel. The egress PE identifies the ingress NVE 137 through the source IP address. The egress NVE does not forward the 138 BUM packet received from an overlay tunnel to the multihomed Ethernet 139 segment that it has in common with the ingress NVE. 141 For EVPN with MPLS over IP tunnel, the split-horizon filtering rule 142 is based on the ESI label. For ingress replication, an ESI label is 143 downstream assigned per multihomed ES. The ingress NVE MUST include 144 the ESI label, assigned by the egress PE, when it forwards a BUM 145 packet to the egress NVE if the BUM traffic is form the AC that is 146 part of the multihomed ES associated with that ESI label. The egress 147 NVE does not forward the BUM packet it received from an overlay 148 tunnel to the multihomed ES if the ESI label is allocated by the 149 egress NVE for that multihomed ES. 151 2.2. Optimized-IR and the Need to Maintain the Original Source IP 152 address or Include the ESI Label 154 [EVPN-AR] specifies an optimized ingress replication procedures for 155 the delivery of Multicast and Broadcast (BM) traffic within a bridge 156 domain. It defines the control plane and forwarding plane procedures 157 for AR-REPLICATOR, AR-LEAF and RNVE. To support EVPN AR-LEAF 158 multihoming, [EVPN-AR] recommends that split horizon filtering rule 159 based on "Local-Bias" procedures is used for EVPN NVO network using 160 either 24-bit VNI or MPLS label. 162 To support EVPN all-active multihoming based on "Local-Bias" 163 procedures, when an AR-REPLICATOR performs assisted replication on 164 behalf of a multihomed AR-LEAF, the AR-REPLICATOR shall use the 165 source IP address of the ingress AR-LEAF for packet received on the 166 AR-IP tunnel. This ensures that other remote NVEs, when receiving a 167 packet from its AR-REPLICATOR, can perform the regular split horizon 168 filtering based on the source IP address. 170 To support EVPN all-active multihoming with MPLSoGRE or MPLSoUDP, 171 sometimes it is desirable to continue using the existing split 172 horizon filtering rule based on [RFC7432] procedures. In this case, 173 when performing assisted replication on behalf of a multihomed AR- 174 LEAF, an AR-REPLICATOR shall include the ESI label advertised by a 175 remote NVE for that multihomed ES. 177 Due to either implementation complexity or hardware limitation, an 178 AR-REPLICATOR may be unable to retain the source IP address or 179 include the ESI label when replicating the packet to the remote NVEs 180 on behalf of a multihomed AR-LEAF. Under this circumstance, when 181 receiving the packet, a remote NVE is unable to use the existing 182 split horizon filtering rules to prevent the looping of BM traffic 183 required for all-active multihoming. 185 For example, with VXLAN encapsulation, consider a case where TS1 is 186 multihomed to AR-LEAF1 and AR-LEAF2 through a multihomed ES. When 187 AR-LEAF1 receives an IP multicast packet from TS1, AR-LEAF1 sends the 188 packet to its AR-REPLICATOR with the source IP address set to AR- 189 LEAF1's IR-IP and the destination IP address set to the AR-IP of the 190 AR-REPLICATOR. Since the AR-REPLICATOR is unable to retain the 191 source IP address for the packet it received on the AR-IP tunnel, the 192 AR-REPLICATOR uses one of its own IP addresses as the source IP 193 address when it replicates the packet to other NVEs. When AR-LEAF2 194 receives the packet from the AR-REPLICATOR, it checks for the source 195 IP address. AR-LEAF2 is unable to detect that this packet was 196 originally sent by AR-LEAF1. If AR-LEAF2 is the DF for the 197 multihomed ES connected to TS1, AR-LEAF2 forwards the packet to TS1. 198 This causes the same IP multicast packet to be looped back to TS1. 200 The same problem can also happen to EVPN with MPLS over IP network if 201 an AR-REPLICATOR cannot include the ESI label to the remote NVE for 202 the multihomed ES when the split horizon filtering rule based on 203 [RFC7432] is used. 205 3. Solution 207 This document extends the procedures defined in the [EVPN-AR] to 208 support EVPN multihoming on AR-LEAFs when an NVE acts as an AR- 209 REPLICATOR is incapable of retaining the source IP address or 210 including an ESI label for its AR-LEAF either due to its hardware 211 limitation or implementation complexity. The solution specified in 212 this document is intended to work for EVPN over IP-based network with 213 NVO tunnel using either 24-bit VNI or MPLS label. The solution 214 relies on either [RFC7432] or "Local-Bias" split-horizon filtering 215 rules to prevent the looping of BUM traffic. We refer to the 216 procedures specified in this document as the extended Optimized-IR 217 procedures. The extended Optimized-IR procedures also work with 218 RNVE. The extended Optimized-IR procedures do not apply to EVPN with 219 MPLS encapsulation. 221 3.1. AR-REPLICATOR Announcing Multihoming Assistant Capability for 222 Optimized-IR 224 An AR-REPLICATOR announces its AR-REPLICATOR role through the control 225 plane. A REPLICATOR-AR route, as it is specified in the [EVPN-AR], 226 is an Inclusive Multicast Ethernet Tag (IMET) route that an AR- 227 REPLICATOR originates for its AR-IP and corresponding AR-replication 228 tunnel. 230 If an AR-REPLICATOR cannot or chose not to retain the source IP 231 address or include the expected ESI label for its multihomed AR- 232 LEAFs, it MUST informs other NVEs in the control plane through the 233 use of EVPN Multicast Flags Extended Community as follow: a) the AR- 234 REPLICATOR MUST set the "Extended-MH-AR" flag, as it is specified in 235 the section 6, in the multicast flags extended community, and b) it 236 MUST attach this community to the REPLICATOR-AR route it originates. 237 We call such an AR-REPLICATOR an Extended-MH AR-REPLICATOR. 239 An Extended-MH AR-REPLICATOR supports extended Optimized-IR 240 procedures defined in this document for its multihomed AR-LEAFs. An 241 Extended-MH AR-REPLICATOR keeps track of its AR-LEAF's multihomed 242 peer. An Extended-MH AR-REPLICATOR can perform assisted replication 243 for an AF-LEAF to other NVEs that are not attached to the same 244 multihomed ES as the AR-LEAF. An Extended-MH AR-REPLICATOR does not 245 perform assisted replication for its AR-LEAF to other NVEs that have 246 a multihomed ES in common with the AR-LEAF. The changes in the 247 control plane and forwarding plan procedures for an Extended-MH AR- 248 REPLICATOR is further explained in detail in section 5.2. 250 An AR-REPLICATOR originating a REPLICATOR-AR route without a 251 multicast flags extended community or with the Extended-MH-AR flag 252 unset is considered to be an MH-capable-assistant AR-REPLICATOR. An 253 MH-capable-assistant AR-REPLICATOR can perform assisted replication 254 for its single-homed AR-LEAF as well as multihomed AR-LEAF. 256 3.2. Multihomed AR-LEAF and Extended-MH AR-REPLICATOR 258 An AR-LEAF follows the control plane and forwarding plane procedures 259 specified in [EVPN-AR]. In addition, if a multihomed AR-LEAF detects 260 that one of its AR-REPLICATORs is Extended-MH AR-REPLICATOR based on 261 the processing of its REPLICATOR-AR route, the multihomed AR-LEAF 262 follows the extended Optimized-IR procedures specified in this 263 document. With the extended Optimized-IR procedures, within the same 264 BD, the multihomed AR-LEAF will use the regular ingress replication 265 procedure to deliver a copy of a BUM packet received from its local 266 AC to each of the remote NVEs that has a multihomed ES in common with 267 it. In this way, the egress NVE can use the regular split horizon 268 filtering rule defined in [RFC7432] or [RFC8365] to prevent the BUM 269 traffic to be looped through the egress NVE to the source of origin. 270 The extended procedures required for an AR-LEAF is further specified 271 in detail in section 5. 273 For an AR-LEAF, please note that the additional forwarding procedures 274 specified above apply to BM packets coming from any of its ACs in the 275 same BD, whether that AC is a single homed ES or a part of a 276 multihomed ES. It may also applies to Unknown unicast traffic. This 277 is to further alleviate the burden of an Extended-MH AR-REPLICATOR as 278 it may be unable to detect whether a packet received on its AR-IP 279 tunnel was originally received from a single-homed or multihomed ES. 281 Consider an EVPN NVO network with a tenant domain consists of a set 282 of m AR-LEAFs in BD X: AR-LEAF1, AR-LEAF2, AR-LEAF3, ..., AR-LEAFm. 283 TS1 is multihomed to AR-LEAF1 and AR-LEAF2 in BD X through a 284 multihomed ES ES1. TS2 is multihomed to AR-LEAF1 and AR-LEAF3 in BD 285 X through another multihomed ES ES2. Also, suppose that there are 286 two Extended-MH AR-REPLICATORs in the same tenant domain: AR- 287 REPLICATOR1 and AR-REPLICATOR2. AR-LEAF1 will detect that its AR- 288 REPLICATORs are Extended-MH AR-REPLICATORs. AR-LEAF1 will also 289 detect that both AR-LEAF2 and AR-LEAF3 have a multihomed ES in common 290 with it. AR-LEAF1 will use regular ingress replication to send the 291 BUM traffic it receives from its access to both AR-LEAF2 and AR- 292 LEAF3. AR-LEAF1 will rely on one of its AR-REPLICATORs to send the 293 BM traffic to AR-LEAF4, AR-LEAF5, ..., and AR-LEAFm. 295 3.3. The Benefit of the Extended Optimized-IR Procedure 297 The extended Optimized-IR procedures specified in this document 298 greatly reduces the implementation complexity of an AR-REPLICATOR or 299 helps to overcome the limitation of an AR-REPLICATOR. It frees all 300 AR-REPLICATORs from performing multihoming assisted replication while 301 at the same time, it allows the support of EVPN multihoming on the 302 AR-LEAFs with the existing multihoming procedures and split horizon 303 filtering rules. For EVPN with MPLS over IP-based encapsulation, an 304 NVE can continue to use the split horizon filtering rule based on the 305 ESI label. Furthermore, it still allows the support of efficient 306 Optimized-IR for the rest of an EVPN NVO network. 308 For example, in a typical NVO network, a TS is most likely multihomed 309 to two or a small set of NVEs for redundancy. In an NVO network 310 consisting of many NVEs, the AR-REPLICATOR is still responsible for 311 replicating the BM packet to the most of NVEs for its AR-LEAF and 312 thus it inherits the benefit of optimized ingress replication for the 313 most of its NVO network. 315 3.4. Support for Mixed AR-REPLICATORs 317 When there are mixed MH-capable-assistant AR-REPLICATORs and 318 Extended-MH AR-REPLICATORs in the same tenant domain, all AR capable 319 NVEs MUST follow the extended Optimized-IR procedures as long as one 320 of the AR-REPLICATORs is an Extended-MH AR-REPLICATOR. 322 When there are mixed AR-REPLICATORs, this document recommends that 323 all MH-capable-assistant AR-REPLICATORs to be administratively 324 provisioned to behave as Extended-MH AR-REPLICATORs. In this case, 325 each AR-REPLICATOR originates its REPLICATOR-AR route with the 326 Extended-MH-AR flag set in the multicast flags extended community. 328 The procedure for using mixed AR-REPLICATORs is beyond the scope of 329 this document. 331 4. Extended Optimized-IR Procedure for Supporting Extended-MH AR- 332 REPLICATOR 334 4.1. AR-LEAF Procedure 336 This section covers the extended Optimized-IR procedures required for 337 an AR-LEAF in further detail when at least one of the AR-REPLICATORs 338 is an Extended-MH AR-REPLICATOR. It is assumed that an AR-LEAF 339 follows the procedures defined in [EVPN-AR] unless it is specified 340 otherwise. 342 4.1.1. Control Plane Procedure for AR-LEAF 344 An AR-LEAF detects whether an AR-REPLICATOR is capable of performing 345 multihoming assisted replication through the Extended-MH-AR flag in 346 the multicast flags extended community carried in the REPLICATOR-AR 347 route. An AR-REPLICATOR originating a REPLICATOR-AR route without a 348 multicast flags extended community or with the Extended-MH-AR flag 349 unset is considered to be multihoming assistant capable. 351 If an AR-LEAF does not have any locally attached segment that is a 352 part of a multihomed ES, then there is no additional extended 353 Optimized-IR procedure for an AR-LEAF to follow and we can go 354 directly to section 4.2. 356 If selective assistant-replication is used for the EVI, selective AR- 357 LEAFs that share the same multihomed ES MUST select the same primary 358 AR-REPLICATOR and the same backup AR-REPLICATOR, if there is one. 359 This can be achieved through either manual configuration on each 360 multihomed selective AR-LEAF or by other methods that are beyond the 361 scope of this document. Each selective AR-LEAF follows the 362 procedures defined in the [EVPN-AR] to send its corresponding leaf-AD 363 routes to its AR-REPLICATOR. 365 An AR-LEAF follows the normal procedures defined in [RFC7432] when it 366 originates a type-4 ES route and type-1 Ethernet A-D routes for its 367 locally attached segment that is a part of a multihomed ES. 369 In addition, an AR-LEAF builds a peer-multihomed-flood-list for each 370 BD it attaches. Per normal EVPN procedures defined in [RFC7432], an 371 AR-LEAF discovers the ESI of each multihomed ES that every remote NVE 372 connects to. For a given BD, an AR-LEAF constructs a peer- 373 multihomed-flood-list that consists of its peer multihomed NVEs in 374 that BD that have at least one multihomed ES in common with it. An 375 AR-LEAF may consider a common multihomed ES that it shares with a 376 remote NVE in a BD specific scope or an EVI scope. Please section 5 377 for detail. 379 4.1.2. Forwarding Procedure for AR-LEAF 381 Suppose that a multihomed AR-LEAF detects through the control plane 382 procedure that at least one of its AR-REPLICATORs is an Extended-MH 383 AR-REPLICATOR, then in addition to follow the forwarding procedures 384 defined in [EVPN-AR], the AR-LEAF will use regular ingress 385 replication to send the BUM packet, received from one of its ACs, to 386 each NVE in that BD's peer-multihomed-flood-list. 388 In the case that there are no more AR-REPLICATORs in the tenant 389 domain, the AR-LEAF reverts back to the regular IR behavior as it is 390 defined in [RFC7432]. 392 An AR-LEAF will follow the regular EVPN procedures when it receives a 393 packet from an overlay tunnel and it will never send the packet back 394 to the core. 396 4.2. AR-REPLICATOR Procedure 398 This section describes the additional procedures for an AR-REPLICATOR 399 when there is at least one AR-REPLICATOR in the same tenant domain 400 that is an Extended-MH AR-REPLICATOR. 402 It is also assumed that an AR-REPLICATOR follows the procedures 403 defined in [EVPN-AR] unless specified otherwise. 405 4.2.1. Control Plane Procedure for AR-REPLICATOR 407 An NVE that performs an AR-REPLICATOR role follows the control plane 408 procedures for AR-REPLICATOR defined in the [EVPN-AR]. 410 In addition, if an AR-REPLICATOR is an Extended-MH AR-REPLICATOR or 411 if it is administratively provisioned to behave as an Extended-MH AR- 412 REPLICATOR, it SHALL attach a multicast flags extended community to 413 its REPLICATOR-AR route with the Extended-MH-AR flag set. 415 An AR-REPLICATOR also discovers whether another AR-REPLICATOR is an 416 Extended-MH AR-REPLICATOR based on the multicast flags extended 417 community. If at least one AR-REPLICATOR is an Extended-MH AR 418 replicator, then the rest of AR-REPLICATORs SHALL fall back to 419 support the extended procedures specified in this document. 421 When there are mixed AR-REPLICATORs, this document recommends that 422 all MH-capable-assistant AR-REPLICATORs SHOULD fall back to behave as 423 Extended-MH AR-REPLICATOTRs through administrative provisioning. 425 An Extended-MH AR-REPLICATOR builds a multihomed list for each BD 426 that its AR-LEAF attaches to. We refer to such a multihomed list as 427 an AR-LEAF's multihomed-list. Per normal EVPN procedures defined in 428 [RFC7432], an AR-REPLICATOR imports the Ethernet A-D per EVI route, 429 the alias route, originated by each remote NVE in the same tenant 430 domain. For a given BD that an AR-LEAF belongs to, an AR-LEAF's 431 multihomed-list consists of all the NVEs in that BD that have at 432 least one multihomed ES in common with the said AR-LEAF. Please also 433 refer to section 5 for the common multihomed ES an AR-LEAF shares 434 with its remote NVE. 436 Consider an EVPN NVO network specified in the section 3.2. Both AR- 437 LEAF1 and AR-LEAF2 originate its Ethernet A-D per EVI route for ES1 438 respectively. Both AR-LEAF1 and AR-LEAF3 originate its Ethernet A-D 439 per EVI route for ES2 respectively. Per normal EVPN procedures, each 440 AR-REPLICATOR imports and processes Ethernet A-D per EVI routes. 441 Each AR-REPLICATOR builds an AR-LEAF1's multihomed-list for BD X that 442 consists of AR-LEAF2 and AR-LEAF3. Each AR-REPLICATOR also builds 443 AR-LEAF's multihomed-lists for other AR-LEAFs. 445 4.2.2. Forwarding Procedure for AR-REPLICATOR 447 When an AR-REPLICTOR determines that it is an Extended-MH AR- 448 REPLICATOR or determines that it SHALL fall back to become an 449 Extended-MH AR_REPLICATOR, it MUST follow the forwarding procedures 450 described in this section. 452 For a given BD, when an AR-REPLICATOR replicates the packet, received 453 from its AR-IP tunnel, to other overlay tunnels on behalf of its 454 ingress AR-LEAF, the AR-REPLICATOR MUST skip any NVE that is in that 455 ingress AR-LEAF's multihomed-list built for that said BD. 457 When replicating the traffic to other AR-REPLICATORs or other AR- 458 LEAFs over an overlay tunnel, an AR-REPLICATOR does not set the 459 source IP address to its ingress AR-LEAF's IR-IP. It is assumed 460 under the scope of this document that an AR-LEAF does not share any 461 common multihoming ES with any AR-REPLICATOR. 463 When replicating the traffic to other RNVEs, an AR-REPLICATOR should 464 set the source IP address to its own IR-IP. This is because an RNVE 465 does not recognize the AR-IP. 467 4.3. RNVE Procedure 469 There is no change to the RNVE control and forwarding procedures. 470 RNVE follows the regular ingress replication procedure defined in 471 [RFC7432]. 473 5. AR-LEAF's Peer multihomed NVE in the Extended Optimized-IR Procedure 475 For the extended Optimized-IR procedures specified in this document, 476 a multihomed AR-LEAF may keep track of the common multihomed ES it 477 shares with other remote NVEs in a BD specific scope or in an EVI 478 scope. Correspondingly, an Extended-MH AR-REPLICATOR MUST also use 479 the same scheme to keep track of the common multihomed ES that its 480 AR-LEAF shares with other remote NVEs. All multihomed AR-LEAFs and 481 all AR-REPLICATORs within the same EVI MUST use the same scheme to 482 keep track of the common multihomed ES that an AR-LEAF shares with 483 other remote NVEs. This consistency can be enforced through a manual 484 configuration. 486 A multihomed AR-LEAF maintains a peer-multihomed-flood-list for each 487 BD it attaches. If the common multihomed ES is tracked in a per EVI 488 scope, an AR-LEAF's peer-multihomed-flood-list for a given BD X 489 contains all the NVEs in BD X that have at least one multihomed ES in 490 common with it, regardless whether each common multihomed ES contains 491 BD X or not. If the common multihomed ES is tracked in a BD specific 492 scope, for a given BD X, each common multihomed ES must contain BD X. 493 The same MUST be applied to the AR-LEAF's multihomed-list for BD X an 494 AR-REPLICATOR maintains for its AR-LEAF. 496 When the Ethernet A-D per EVI route is advertised at the granularity 497 of per ES, the common multihomed ES is tracked in a per EVI scope. 499 6. Multicast Flags Extended Community 501 The EVPN Multicast Flags Extended Community is defined in the 502 [EVPN-IGMP-PROXY]. This transitive extended community can carry many 503 flags in its Flags field. This document proposes one new flag in the 504 Flags bit vector. 506 o Extended-MH-AR 508 The Extended-MH-AR flag, M flag for short, takes the next available 509 low-order bit from the Flags field. 511 The Extended-MH-AR flag is used by the AR-REPLICATOR. When this flag 512 is set, the AR-REPLICATOR indicates to other NVEs that it will not 513 retain the source IP address or include the ESI label for an ingress 514 NVE when replicating the packet over an NVO tunnels on behalf of the 515 ingress NVE. Such an AR-REPLICATOR supports the extended optimized- 516 IR procedures defined in this document. 518 7. IANA Considerations 520 A request for a new flag named Extended-MH-AR flag in the Flags field 521 of the multicast flags extended community will be submitted to IANA. 523 8. Security Considerations 525 This document inherits the same securities as they are defined in the 526 [RFC7432], [RFC8365] and [EVPN-AR]. 528 9. Acknowledgements 530 The authors would like to thank Eric Rosen and Jeffrey Zhang for 531 their valuable comments and feedbacks. The authors would also like 532 to thank Aldrin Isaac for his useful discussion, insight on this 533 subject. 535 10. Normative References 537 [EVPN-AR] Rabadan, J., Ed., "Optimized Ingress Replication solution 538 for EVPN", internet-draft ietf-bess-evpn-optimized-ir- 539 06.txt, October 2018. 541 [EVPN-IGMP-PROXY] 542 Sajassi, A., Ed., "IGMP and MLD Proxy for EVPN", internet- 543 draft ietf-bess-evpn-igmp-mld-proxy-04.txt, June 2018. 545 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 546 Requirement Levels", BCP 14, RFC 2119, 547 DOI 10.17487/RFC2119, March 1997, 548 . 550 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 551 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 552 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 553 2015, . 555 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 556 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 557 May 2017, . 559 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 560 Uttaro, J., and W. Henderickx, "A Network Virtualization 561 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 562 DOI 10.17487/RFC8365, March 2018, 563 . 565 Authors' Addresses 567 Wen Lin (editor) 568 Juniper Networks, Inc. 570 EMail: wlin@juniper.net 572 Selvakumar Sivaraj 573 Juniper Networks, Inc. 575 EMail: ssivaraj@juniper.net 577 Vishal Garg 578 Juniper Networks, Inc. 580 EMail: vishalg@juniper.net 582 Jorge Rabadan 583 Nokia 585 EMail: jorge.rabadan@nokia.com