idnits 2.17.1 draft-nr-bess-evpn-mh-split-horizon-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 1, 2019) is 1635 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) == Unused Reference: 'RFC8584' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'TUNNEL-ENCAP' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'SRv6-Services' is defined on line 617, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-bess-evpn-geneve-00 -- Obsolete informational reference (is this intentional?): RFC 5512 (Obsoleted by RFC 9012) == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-14 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-14 == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-00 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup J. Rabadan, Ed. 3 Internet Draft K. Nagaraj 4 Intended status: Standards Track Nokia 6 W. Lin 7 Juniper 9 A. Sajassi 10 Cisco 12 Expires: May 4, 2020 November 1, 2019 14 EVPN Multi-Homing Extensions for Split Horizon Filtering 15 draft-nr-bess-evpn-mh-split-horizon-02 17 Abstract 19 Ethernet Virtual Private Network (EVPN) is commonly used along with 20 Network Virtualization Overlay (NVO) tunnels. The EVPN multi-homing 21 procedures may be different depending on the NVO tunnel type used in 22 the EVPN Broadcast Domain. In particular, there are two multi-homing 23 Split Horizon procedures to avoid looped frames on the multi-homed 24 CE: ESI Label based and Local Bias. ESI Label based Split Horizon is 25 used for MPLSoX tunnels, E.g., MPLSoUDP, whereas Local Bias is used 26 for others, E.g., VXLAN tunnels. The current specifications do not 27 allow the operator to decide which Split Horizon procedure to use for 28 tunnel encapsulations that could support both. Examples of tunnels 29 that may support both procedures are MPLSoGRE, MPLSoUDP, GENEVE or 30 SRv6.sThis document extends the EVPN Multi-Homing procedures so that 31 an operator can decide the Split Horizon procedure for a given NVO 32 tunnel depending on their own requirements. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html 55 This Internet-Draft will expire on May 4, 2020. 57 Copyright Notice 59 Copyright (c) 2019 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1 Conventions and Terminology . . . . . . . . . . . . . . . . 5 76 2. BGP EVPN Extensions . . . . . . . . . . . . . . . . . . . . . . 7 77 2.1 The Split Horizon Type (SHT) . . . . . . . . . . . . . . . . 8 78 2.2 Use of the Split Horizon Type In A-D Per ES Routes . . . . . 8 79 2.3 ESI Label Value In A-D Per ES Routes . . . . . . . . . . . . 9 80 2.4 Backwards Compatibility With [RFC8365] NVEs . . . . . . . . 10 81 3. Procedures for NVEs Supporting Multiple Encapsulations . . . . 11 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 14 87 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 90 1. Introduction 92 Ethernet Virtual Private Network (EVPN) is commonly used along with 93 Network Virtualization Overlay (NVO) tunnels and specified in 94 [RFC8365]. The EVPN multi-homing procedures may be different 95 depending on the NVO tunnel type used in the EVPN Broadcast Domain. 96 In particular, there are two Multi-Homing Split Horizon procedures to 97 avoid looped frames on the multi-homed CE: ESI Label based and Local 98 Bias. ESI Label based Split Horizon is used for MPLSoX tunnels, E.g., 99 MPLSoUDP [RFC7510], and its procedures described in [RFC7432]. Local 100 Bias is used by non-MPLS NVO tunnels, E.g., VXLAN tunnels, and it is 101 described in [RFC8365]. 103 As a refresher: 105 o ESI Label based Split-Horizon filtering [RFC7432] 107 If MPLS-based tunnels are used in EVPN, an MPLS label is used for 108 Split Horizon filtering to support All-Active multi-homing where an 109 ingress NVE adds a label corresponding to the source Ethernet 110 Segment (aka an ESI label) when encapsulating the packet. The 111 egress NVE checks the ESI label when attempting to forward a multi- 112 destination frame out a local ES interface, and if the label 113 corresponds to the same site identifier (ESI) associated with that 114 ES interface, the packet is not forwarded. This prevents the 115 occurrence of forwarding loops for BUM traffic. 117 The ESI Label Split Horizon filtering SHOULD also be used with 118 Single-Active multi-homing to avoid transient loops for in-flight 119 packets when the egress NVE takes over as DF for an Ethernet 120 Segment. 122 o Local Bias for non-MPLS NVO tunnels [RFC8365] 124 Since non-MPLS NVO tunnels, such as VXLAN and NVGRE encapsulations, 125 do not include the ESI label, a different Split Horizon filtering 126 procedure must be used for All-Active multi-homing. This mechanism 127 is called Local Bias and relies on the NVO tunnel source IP address 128 to decide whether to forward BUM traffic to a local ES interface at 129 the egress NVE. 131 In a nutshell, every NVE tracks the IP address(es) associated with 132 the other NVE(s) with which it has shared multi-homed ESs. When the 133 egress NVE receives a BUM frame encapsulated in a VXLAN or NVGRE 134 packet, it examines the source IP address in the tunnel header 135 (which identifies the ingress NVE) and filters out the frame on all 136 local interfaces connected to ESes that are shared with the ingress 137 NVE. 139 Due to this behavior at the egress NVE, the ingress NVE's behavior 140 is also changed to perform replication locally to all directly 141 attached Ethernet segments (regardless of the DF election state) 142 for all BUM ingress from the access ACs. Because of this "local" 143 replication at the ingress NVE, this approach is referred to as 144 Local Bias. 146 Local Bias cannot be used for Single-Active multi-homing, since the 147 ingress NVE brings operationally down the ACs for which it is non- 148 DF (hence local replication to non-DF ACs cannot be done). This 149 means transient in-flight BUM packets may be looped back to the 150 originating site by new elected DF egress NVEs. 152 [RFC8365] states that Local Bias is used only for non-MPLS NVO 153 tunnels, and ESI Label based Split Horizon for MPLS NVO tunnels. 154 However, MPLS NVO tunnels, such as MPLSoGRE or MPLSoUDP, can 155 potentially support both procedures, since they can carry ESI Labels 156 and they also use a tunnel IP header where the source IP address 157 identifies the ingress NVE. 159 Similarly, some non-MPLS NVO tunnels may potentially follow either 160 procedure too. Some examples are GENEVE or SRv6: 162 o In a GENEVE tunnel the source IP address identifies the ingress NVE 163 therefore local bias is possible. Also, [EVPN-GENEVE] defines an 164 Ethernet option TLV (Type Length Value) to encode an ESI label 165 value. 167 o In an SRv6 tunnel, the source IP address also identifies the 168 ingress NVE, however, by default and as described in [SRv6- 169 Services] the ingress PE will add information in the SRv6 packet so 170 that the egress PE can identify the source ES of the BUM packet. 171 That information is the ESI filtering argument of the service SID 172 received on an A-D per ES route from the egress PE. 174 Table 1 shows different tunnel encapsulations and their supported and 175 default Split Horizon method. In the case of GENEVE, the default 176 Split Horizon Type (SHT) depends on whether the Ethernet Option with 177 Source ID TLV is negotiated. In the case of SRv6, the default SHT is 178 listed as ESI label filtering in Table 1, since the behavior is 179 equivalent to that of ESI Label filtering 180 +-------------+------------------------+-----------+----------+ 181 |Tunnel | Default Split Horizon | Supports |Supports | 182 |Encapsulation| Type (SHT) | Local Bias|ESI Label | 183 +-------------|------------------------|-----------|----------+ 184 | VXLAN | Local Bias | Yes | No | 185 +-------------|------------------------|-----------|----------+ 186 | NVGRE | Local Bias | Yes | No | 187 +-------------|------------------------|-----------|----------+ 188 | MPLS | ESI Label filtering | No | Yes | 189 +-------------|------------------------|-----------|----------+ 190 | MPLSoGRE | ESI Label filtering | Yes | Yes | 191 +-------------|------------------------|-----------|----------+ 192 | MPLSoUDP | ESI Label filtering | Yes | Yes | 193 +-------------|------------------------|-----------|----------+ 194 | GENEVE | Local Bias (no ESI Lb) | Yes | Yes | 195 | | ESI Label (if ESI Lb) | | | 196 +-------------|------------------------|-----------|----------+ 197 | SRv6 | ESI Label filtering | Yes | Yes | 198 +-------------+------------------------+-----------+----------+ 200 Table 1 - Tunnel Encapsulations and Split Horizon Types 202 The ESI Label method works for All-Active and Single-Active, while 203 Local Bias only works for All-Active. In addition, the ESI Label 204 method works across different networks, whereas Local Bias is limited 205 to networks with no next hop change between the NVEs in the same 206 Ethernet Segment. However, some operators prefer the Local Bias 207 method, since it simplifies the encapsulation, consumes less 208 resources on the NVEs and the ingress NVE always forwards locally to 209 other interfaces. 211 This document extends the EVPN Multi-Homing procedures so that an 212 operator can decide the Split Horizon procedure for a given NVO 213 tunnel depending on their own specific requirements. The choice of 214 Local Bias or ESI Label Split Horizon is now allowed for NVO tunnels 215 that support both methods. Non-MPLS NVO tunnels that do not support 216 both methods, E.g., VXLAN or NVGRE, will follow [RFC8365] 217 procedures. 219 1.1 Conventions and Terminology 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 223 "OPTIONAL" in this document are to be interpreted as described in BCP 224 14 [RFC2119] [RFC8174] when, and only when, they appear in all 225 capitals, as shown here. 227 o BUM: Broadcast, Unknown unicast and Multicast traffic. 229 o ES and ESI: Ethernet Segment and Ethernet Segment Identifier. 231 o A-D per ES route: refers to the EVPN Ethernet Auto-Discovery per 232 Ethernet Segment route defined in [RFC7432]. 234 o AC: Attachment Circuit. 236 o NVE: Network Virtualization Edge device. 238 o EVI and EVI-RT: EVPN Instance and EVI Route Target. A group of NVEs 239 attached to the same EVI will share the same EVI-RT. 241 o MPLS and non-MPLS NVO tunnels: refer to Multi-Protocol Label 242 Switching (or the absence of it) Network Virtualization Overlay 243 tunnels. Network Virtualization Overlay tunnels use an IP 244 encapsulation for overlay frames, where the source IP address 245 identifies the ingress NVE and the destination IP address the 246 egress NVE. 248 o MPLSoUDP: Multi-Protocol Label Switching over User Datagram 249 Protocol, [RFC7510] 251 o MPLSoGRE: Multi-Protocol Label Switching over Generic Network 252 Encapsulation, [RFC4023]. 254 o MPLSoX: refers to MPLS over any IP encapsulation. Examples are 255 MPLSoUDP or MPLSoGRE. 257 o GENEVE: Generic Network Virtualization Encapsulation, [GENEVE]. 259 o VXLAN: Virtual eXtensible Local Area Network, [RFC7348]. 261 o NVGRE: Network Virtualization Using Generic Routing Encapsulation, 262 [RFC7637]. 264 o VNI: Virtual Network Identifier. A 24-bit identifier used by 265 Network Virtualization Overlay (NVO) over IP encapsulations. 266 Examples are VXLAN (Virtual Extended Local Area Network) or GENEVE 267 (Generic Network Virtualization Encapsulation). 269 o Broadcast Domain (BD): an emulated ethernet, such that two systems 270 on the same BD will receive each other's link-local broadcasts. In 271 this document, BD also refers to the instantiation of a Broadcast 272 Domain on an EVPN PE. An EVPN PE can be attached to one or multiple 273 BDs of the same tenant. 275 o Designated Forwarder (DF): as defined in [RFC7432], an ethernet 276 segment may be multi-homed (attached to more than one PE). An 277 ethernet segment may also contain multiple BDs, of one or more 278 EVIs. For each such EVI, one of the PEs attached to the segment 279 becomes that EVI's DF for that segment. Since a BD may belong to 280 only one EVI, we can speak unambiguously of the BD's DF for a given 281 segment. 283 o SHT: Split Horizon Type, it refers to the Split Horizon method that 284 a PE intends to use and advertises in an A-D per ES route. 286 This document also assumes familiarity with the terminology of 287 [RFC7432] and [RFC8365]. 289 2. BGP EVPN Extensions 291 EVPN extensions are needed so that NVEs can advertise their 292 preference for the Split Horizon method to be used in the Ethernet 293 Segment. Figure 1 shows the ESI Label extended community that is 294 always advertised along with the EVPN A-D per ES route. All the NVEs 295 attached to an Ethernet Segment advertise an A-D per ES route for the 296 ES, including this extended community that conveys the information 297 for the multi-homing mode (All-active or Single-Active), as well as 298 the ESI Label to be used (if needed). 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Type=0x06 | Sub-Type=0x01 | Flags(1 octet)| Reserved=0 | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Reserved=0 | ESI Label | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 1 - ESI Label extended community 309 [RFC7432] defines the low-order bit of the Flags octet (bit 0) as the 310 "Single-Active" bit: 312 o A value of 0 means that the multi-homed Ethernet Segment is 313 operating in All-Active mode. 315 o A value of 1 means that the multi-homed Ethernet Segment is 316 operating in Single-Active mode. 318 2.1 The Split Horizon Type (SHT) 320 [RFC8365] does not add any explicit indication about the Split 321 Horizon method in the A-D per ES route. In this document the 322 [RFC8365] Split Horizon procedure is the default behavior and assumes 323 that Local Bias is used only for non-MPLS NVO tunnels, and ESI Label 324 based Split Horizon for MPLS NVO tunnels. This document defines the 325 two high-order bits in the Flags octet (bits 6 and 7) as the "Split 326 Horizon Type" (SHT) field, where: 328 SHT bit 7 6 329 ----------- 330 0 0 --> Default SHT. Backwards compatible with [RFC8365] 331 0 1 --> Local Bias 332 1 0 --> ESI Label based filtering 333 1 1 --> reserved for future use 335 o SHT = 00 is backwards compatible with [RFC8365] and indicates: 337 - The advertising NVE intends to use the default or native SHT. The 338 default SHT is shown in Table 1 for each NVO encapsulation. 339 - An egress NVE that follows the [RFC8365] behavior and does not 340 support this specification will use an SHT value of 00. 342 o SHT = 01 indicates that the advertising NVE intends to use Local 343 Bias procedures in the Ethernet Segment for which the AD per-ES 344 route is advertised. 346 o SHT = 10 indicates that the advertising NVE intends to use the ESI 347 Label based Split Horizon method procedures in the Ethernet Segment 348 for which the AD per-ES route is advertised. 350 2.2 Use of the Split Horizon Type In A-D Per ES Routes 352 The following must be observed: 354 - An SHT value of 01 or 10 MUST NOT be used with encapsulations that 355 support only one SHT in Table 1, and MAY be used by encapsulations 356 that support the two SHTs in Table 1. 358 - An SHT value different than 00 expresses the intend to use a 359 specific Split Horizon method, but does not reflect the actual 360 operational SHT used by the advertising NVE, unless all the NVEs 361 attached to the ES advertise the same SHT. 363 - In case of inconsistency in the SHT value advertised by the NVEs 364 attached to the same ES for a given EVI, all the NVEs MUST revert 365 to the [RFC8365] behavior, and use the default SHT in Table 1, 366 irrespective of the advertised SHT. 368 - An SHT different from 00 MUST NOT be set if the Single-Active bit 369 is set. A received A-D per ES route where Single-Active and SHT 370 bits are different from zero MUST be treat-as-withdraw [RFC7606]. 372 - The SHT MUST have the same value in each Ethernet A-D per ES route 373 that an NVE advertises for a given ES and a given encapsulation 374 (see Section 3 for NVEs supporting multiple encapsulations). 376 As an example, egress NVEs that support MPLS NVO tunnels, E.g., 377 MPLSoGRE or MPLSoUDP, will advertise A-D per ES route(s) for the ES 378 along with the [RFC5512] BGP Encapsulation extended community 379 indicating the encapsulation (MPLSoGRE or MPLSoUDP) and MAY use the 380 SHT = 01 or 10 to indicate the intend to use Local Bias or ESI Label, 381 respectively. 383 An egress NVE MUST NOT use an SHT value different from 00 when 384 advertising an A-D per ES route with encapsulation VXLAN, NVGRE, MPLS 385 or no [RFC5512] BGP tunnel encapsulation extended community. We 386 assume that, in all these cases, there is no Split Horizon method 387 choice, and therefore the SHT value must be 00. A received route with 388 one of the above encapsulation options and SHT value different from 389 00 SHOULD be treat-as-withdraw. 391 An egress NVE advertising A-D per ES route(s) for an ES with 392 encapsulation GENEVE MAY use an SHT value of 01 or 10. A value of 01 393 indicates the intend to use Local Bias, irrespective of the presence 394 of an Ethernet option TLV with a non-zero Source-ID [EVPN-GENEVE]. A 395 value of 10 indicates the intend to use ESI Label based Split 396 Horizon. A value of 00 indicates the default behavior in Table 1, 397 that is, use Local Bias if no ESI-Label exists in the Ethernet option 398 TLV or no Ethernet option TLV whatsoever. Otherwise the ESI Label 399 Split Horizon method is used. 401 The above procedures assume a single encapsulation supported in the 402 egress NVE. Section 3 describes additional procedures for NVEs 403 supporting multiple encapsulations. 405 2.3 ESI Label Value In A-D Per ES Routes 407 This document also modifies the value that is advertised in the ESI 408 Label field of the ESI Label extended community as follows: 410 o The A-D per ES route(s) for an ES MAY have an ESI Label value of 411 zero if the SHT value is 01. Section 2.2 specifies the cases where 412 the SHT can be 01. An ESI Label value of zero avoids the allocation 413 of Labels in the cases where they are not used (Local Bias). 415 o The A-D per ES route(s) for an ES MAY have an ESI Label value of 416 zero for VXLAN or NVGRE encapsulations. 418 2.4 Backwards Compatibility With [RFC8365] NVEs 420 As discussed in Section 2.2 this specification is backwards 421 compatible with the Split Horizon filtering behavior in [RFC8365] and 422 a non-upgraded NVE can be attached to the same ES as other NVEs 423 supporting this specification. 425 An NVE has an administrative SHT value for an ES (the one that is 426 advertised along with the A-D per ES route) and an operational SHT 427 value (the one that is actually used irrespective of what the NVE 428 advertised). The administrative SHT matches the operational SHT if 429 all the NVEs attached to the ES have the same administrative SHT. 431 This document assumes that an [RFC7432] or [RFC8365] compatible 432 implementation (that does not support this document) ignores the 433 value or all the bits in the ESI Label extended community except for 434 the Single-Active bit. Based on this assumption, a non-upgraded NVE 435 will ignore an SHT different from 00. As soon as an upgraded NVE 436 receives at least one A-D per ES route for the ES with SHT value of 437 00, it MUST revert its operational SHT to the default Split Horizon 438 method, as in Table 1, and irrespective of its administrative SHT. 440 As an example, consider an NVE attached to Ethernet Segment N that 441 receives two A-D per ES routes for N from different NVEs, NVE1 and 442 NVE2. If the route from NVE1 has SHT = 00 and the one from NVE2 an 443 SHT = 01, the NVE MUST use the default Split Horizon method in Table 444 1 as operational SHT, irrespective of its administrative SHT. 446 All the NVEs attached to an ES with operational SHT value of 10 MUST 447 advertise a valid non-zero ESI Label. If the operational SHT value is 448 01, the ESI Label MAY be zero. If the operational SHT value is 00, 449 the ESI Label MAY be zero only if the default encapsulation supports 450 Local Bias only and the NVEs do not check the presence of a valid 451 non-zero ESI Label. 453 If an NVE changes its operational SHT value from 01 to 00 (as a 454 result of a new non-upgraded NVE present in the ES) and it previously 455 advertised a zero ESI Label, it MUST send an update with a non-zero 456 valid ESI Label, unless all the non-upgraded NVEs in the ES support 457 Local Bias only. 459 3. Procedures for NVEs Supporting Multiple Encapsulations 461 As specified by [RFC8365], an egress NVE that supports multiple data 462 plane encapsulations (I.e., VXLAN, NVGRE, MPLS, MPLSoUDP, GENEVE) 463 needs to indicate all the supported encapsulations using BGP 464 Encapsulation extended communities defined in [RFC5512] with all EVPN 465 routes. This section clarifies the multi-homing Split Horizon 466 behavior for NVEs advertising and receiving multiple BGP 467 Encapsulation extended communities along with the A-D per ES routes. 468 This section uses a notation of {x,y} to indicate the encapsulations 469 advertised in [RFC5512] BGP Encapsulation extended communities, with 470 x and y being different encapsulation values. 472 It is important to remember that an NVE MAY advertise multiple A-D 473 per ES routes for the same ES (and not only one), each route 474 conveying a number of EVI Route Targets (EVI-RTs). We refer to the 475 total number of EVI-RTs in a given ES as EVI-RT-set for that ES. Any 476 of the EVIs represented in the EVI-RT-set will have its EVI-RT 477 included in one (and only one) A-D per ES route for the ES. When 478 multiple A-D per ES routes are advertised for the same ES, each route 479 MUST have a different Route Distinguisher. 481 As per [RFC8365], an NVE that advertises multiple encapsulations in 482 the A-D per ES route(s) for an ES, MUST advertise encapsulations that 483 use the same Split Horizon filtering method in the same route. For 484 example: 486 o An A-D per ES route for ES-x may be advertised with {VXLAN,NVGRE} 487 encapsulations. 489 o An A-D per ES route for ES-y may be advertised with 490 {MPLS,MPLSoUDP,MPLSoGRE} encapsulations (or a subset). 492 o But an A-D per ES route for ES-z MUST NOT be advertised with 493 {MPLS,VXLAN} encapsulations. 495 This document extends this behavior as follows: 497 (a) An A-D per ES route for ES-x may be advertised with multiple 498 encapsulations where some support a single Split Horizon method. 499 In this case, the SHT value MUST be 00. As an example, 500 {VXLAN,NVGRE}, {VXLAN,GENEVE} or {MPLS,MPLSoGRE,MPLSoUDP} can be 501 advertised in an A-D per ES route. In all those cases SHT MUST be 502 00. 504 (b) An A-D per ES route for ES-y may be advertised with multiple 505 encapsulations where all of them support both Split Horizon 506 methods. In this case the SHT value MAY be 01 if the desired 507 method is Local Bias, or 10 if ESI Label based. For example, 508 {MPLSoGRE,MPLSoUDP,GENEVE} (or a subset) may be advertised in an 509 A-D per ES route with SHT value of 01. The ESI Label value in 510 this case MAY be zero. 512 (c) If ES-z with EVI-RT-set composed of (EVI-RT1,EVI-RT2,EVI- 513 RT3..EVI-RTn) supports multiple encapsulations that require a 514 different Split Horizon method, a different A-D per ES route (or 515 group of routes) per Split Horizon method MUST be advertised. For 516 example, consider n EVIs in ES-z and: 518 - the EVIs corresponding to (EVI-RT1..EVI-RTi) support VXLAN, 519 - the ones for (EVI-RTi+1..EVI-RTm) (with i. 555 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 556 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, 557 . 559 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 560 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 561 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, 562 . 564 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 565 Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay 566 Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10.17487/RFC8365, 567 March 2018, . 569 8.2. Informative References 571 [RFC8584] Rabadan-Mohanty et al., "Framework for EVPN Designated 572 Forwarder Election Extensibility", , April 2019. 575 [EVPN-GENEVE] Boutros, S., Sajassi, A., Drake, J., and J. Rabadan, 576 "EVPN control plane for Geneve", Work in Progress, draft-ietf-bess- 577 evpn-geneve-00, August 2019. 579 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 580 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible 581 Local Area Network (VXLAN): A Framework for Overlaying Virtualized 582 Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 583 10.17487/RFC7348, August 2014, . 586 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 587 Subsequent Address Family Identifier (SAFI) and the BGP Tunnel 588 Encapsulation Attribute", RFC 5512, DOI 10.17487/RFC5512, April 2009, 589 . 591 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 592 "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", 593 RFC 4023, DOI 10.17487/RFC4023, March 2005, . 596 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 597 Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 598 10.17487/RFC7637, September 2015, . 601 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 602 "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 603 2015, . 605 [GENEVE] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., 606 "Geneve: Generic Network Virtualization Encapsulation", Work in 607 Progress, draft-ietf-nvo3-geneve-14, September 2019. 609 [TUNNEL-ENCAP] Rosen, E., Ed., Patel, K., and G. Vesde, "The BGP 610 Tunnel Encapsulation Attribute", Work in Progress draft-ietf-idr- 611 tunnel-encaps-14, September 2019. 613 [RFC7606] Chen, E., Scudder, J., Mohapatra, P., and K. Patel, 614 "Revised Error Handling for BGP UPDATE Messages", RFC 7606, August 615 2015, . 617 [SRv6-Services] Dawra, G. et al., "SRv6 BGP based Overlay services", 618 Work in Progress, draft-ietf-bess-srv6-services-00, October 2019. 620 9. Acknowledgments 622 10. Contributors 624 Authors' Addresses 626 Jorge Rabadan (Editor) 627 Nokia 628 777 E. Middlefield Road 629 Mountain View, CA 94043 USA 630 Email: jorge.rabadan@nokia.com 632 Kiran Nagaraj 633 Nokia 634 701 E. Middlefield Road 635 Mountain View, CA 94043 USA 636 Email: kiran.nagaraj@nokia.com 638 Wen Lin 639 Juniper Networks 640 Email: wlin@juniper.net 642 Ali Sajassi 643 Cisco Systems, Inc. 644 225 West Tasman Drive 645 San Jose, CA 95134 USA 646 Email: sajassi@cisco.com