idnits 2.17.1 draft-wang-bess-evpn-distributed-bump-in-the-wire-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 ([RFC9136]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 132: '...1 route of ESI23 MUST be advertised bo...' RFC 2119 keyword, line 321: '... Circuit ID Extended Community MUST be...' RFC 2119 keyword, line 323: '...e PE, e.g. PE3) MUST process MAC rout...' RFC 2119 keyword, line 529: '... ETI MUST be encapsulated into the e...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 October 2021) is 914 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: 'I-D.sajassi-bess-evpn-ip-aliasing' is defined on line 583, but no explicit reference was found in the text == Unused Reference: 'RFC9135' is defined on line 596, but no explicit reference was found in the text == Unused Reference: 'I-D.wang-bess-evpn-arp-nd-synch-without-irb' is defined on line 608, but no explicit reference was found in the text == Unused Reference: 'I-D.wz-bess-evpn-vpws-as-vrf-ac' is defined on line 622, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-sajassi-bess-evpn-ac-aware-bundling-04 == Outdated reference: A later version (-09) exists of draft-sajassi-bess-evpn-ip-aliasing-02 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WG Y. Wang 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track 15 October 2021 5 Expires: 18 April 2022 7 Distributed Bump-in-the-wire Use Case 8 draft-wang-bess-evpn-distributed-bump-in-the-wire-00 10 Abstract 12 The Bump-in-the-wire use-case of Section 4.3 of [RFC9136] is a 13 centerlized inter-subnet forwarding solution. The centerlized inter- 14 subnet forwarding burdens the DGWs with the L3 traffics among 15 different subnets inside the same DC. 17 This draft extends the Bump-in-the-wire use-case of Section 4.3 of 18 [RFC9136] in order to achieve a distributed inter-subnet forwarding 19 solution. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 18 April 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . 4 56 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. Problem with Bump-in-the-wire Use-Case . . . . . . . . . 5 58 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.1. Determining the Aliasing Pathes for RT-5E . . . . . . . . 7 60 3.2. ACI-specific Overlay Index Extended Community . . . . . . 8 61 3.3. Constructing IP Prefix Advertisement Route . . . . . . . 10 62 3.4. Bump-in-the-wire Specific Procedures . . . . . . . . . . 10 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 67 6.2. Informative References . . . . . . . . . . . . . . . . . 14 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 70 1. Introduction 72 As shown in Figure 1, the Bump-in-the-wire use-case of Section 4.3 of 73 [RFC9136] is a centerlized inter-subnet forwarding solution. The 74 centerlized inter-subnet forwarding burdens the DGWs with the L3 75 traffics among different subnets inside the same DC. 77 NVE2 DGW1 78 M2 +-----------+ +---------+ +-------------+ 79 +---TS2(VA)--| (BD-10) |-| |----| (BD-10) | 80 | ESI23 +-----------+ | | | IRB1\ | 81 | + | | | (IP-VRF)|---+ 82 | | | | +-------------+ _|_ 83 SN1 | | VXLAN/ | ( ) 84 | | | GENEVE | DGW2 ( WAN ) 85 | + NVE3 | | +-------------+ (___) 86 | ESI23 +-----------+ | |----| (BD-10) | | 87 +---TS3(VA)--| (BD-10) |-| | | IRB2\ | | 88 M3 +-----------+ +---------+ | (IP-VRF)|---+ 89 +-------------+ 91 Figure 1: Centerlized Bump-in-the-wire Use Case 93 As shown in Figure 2, the SN1, BD-10, IP-VRF are the same as 94 Figure 1, except that the TS2, TS3 and ESI23 are not shown in 95 Figure 2, but they are still there unchanged. Then we add a SBD for 96 the IP-VRF instance, and each SBD will be configured with an IRB 97 interface (which is called its SBD IRB). Using this SBD and its SBD 98 IRB, we can extend the Bump-in-the-wire use case to form a 99 distributed inter-subnet forwarding solution which will not burden 100 the DGWs with the L3 traffics among different subnets inside the same 101 DC. 103 NVE2 DGW1 104 +------------+ +---------------+ +------------+ 105 | | | | | | 106 |(IP-VRF)-(SBD)| |(SBD)-(IP-VRF)|-----+ 107 | / IRB2 | | | | IRB1 | | 108 +---+(BD-10) | | | +------------+ _+_ 109 | +------------+ | | ( ) 110 SN1| | VXLAN/ | ( WAN )--H1 111 | NVE3 | GENEVE/ | (___) 112 | +------------+ | MPLS | DGW2 + 113 +---+(BD-10) | | | +------------+ | 114 | \ IRB3 | | | | | | 115 |(IP-VRF)-(SBD)| |(SBD)-(IP-VRF)|-----+ 116 +------------+ | | | IRB9 | 117 | | +------------+ 118 NVE8 | | 119 +------------+ | | 120 SN8+----+(IP-VRF)-(SBD)| | 121 | IRB8 | | | 122 +------------+ +---------------+ 124 Figure 2: Distributed Bump-in-the-wire Use Case 126 The RT-5 route (say RT5E_SN1) advertised by NVE2/NVE3 for SN1 is the 127 same as Section 4.3 of [RFC9136] except for the following notable 128 differentces: 130 * The route-targets of RT5E_SN1 is set to the export-RT of the SBD. 132 * The RT-1 route of ESI23 MUST be advertised both for BD-10 and the 133 SBD, when they are advertised for the SBD, the EVPN label of the 134 RT-1 per EVI route should be set to the EVPN label of the BD-10, 135 as if it is advertised for BD-10. 137 Note that when it is advertised for the SBD, it may use different 138 RD than it is advertised for BD-10. 140 * In order to process the RT5E_SN1 properly, the DGW1 and DGW2 141 don't have to change its behavior of Section 4.3 of [RFC9136]. 142 But the configurations of DGW1 and DGW2 must be changed, because 143 that the BD-10 is removed and the SBD takes its place. 145 Note that to the RT5E_SN1 route, the NVE8 is actually no different 146 from DGW1 and DGW2. NVE8 is not a DC gateway, but whether NVE8 is a 147 DC gateway is not awared by NVE1 and NVE2. 149 But when multiple Bump-in-the-wire are integrated into the same IP- 150 VRF, the above extension is not enough, the details are discribed in 151 Section 2.1, thus some extensions are introduced to solve that 152 problem. 154 1.1. Terminology and Acronyms 156 Most of the acronyms and terms used in this documents comes from 157 [RFC9136] and [I-D.wang-bess-evpn-ether-tag-id-usage] except for the 158 following: 160 * VRF AC - An Attachment Circuit (AC) that attaches a CE to an 161 IP-VRF but is not an IRB interface. 163 * VRF Interface - An IRB interface or a VRF-AC or an IRC 164 interface. Note that a VRF interface will be bound to the 165 routing space of an IP-VRF. 167 * L3 EVI - An EVPN instance spanning the Provider Edge (PE) 168 devices participating in that EVPN which contains VRF ACs and 169 maybe contains IRB interfaces or IRC interfaces. 171 * IP-AD/EVI - Ethernet Auto-Discovery route per EVI, and the EVI 172 here is an IP-VRF. Note that the Ethernet Tag ID of an IP-AD/ 173 EVI route may be not zero. 175 * IP-AD/ES - Ethernet Auto-Discovery route per ES, and the EVI 176 for one of its route targets is an IP-VRF. 178 * RMAC - Router's MAC, which is signaled in the Router's MAC 179 extended community. 181 * ESI Overlay Index - ESI as overlay index. 183 * ET-ID - Ethernet Tag ID, it is also called ETI for short in 184 this document. 186 * RT-5E - An EVPN Prefix Advertisement Route with a non-reserved 187 ESI as its overlay index (the ESI-as-Overlay-Index-style RT-5) 188 . 190 * CE-BGP - The BGP session between PE and CE. Note that CE-BGP 191 route doesn't have a RD or Route-Target. 193 * CE-Prefix - An IP Prefixes behind a CE is called as that CE's 194 CE-Prefix. 196 * ETI-Agnostic BD - A Broadcast Domain (BD) whose data packets 197 can be received along with any Ethernet Tag ID (ETI). Note 198 that a broadcast domain of an L2 EVI of VLAN-aware bundle 199 service interface is a good example of an ETI-Specific BD. 201 * ETI-Specific BD - A Broadcast Domain (BD) whose data packets 202 are expected to be received along with a normalized Ethernet 203 Tag ID (ETI). Note that a broadcast domain of an L2 EVI of 204 VLAN-bundle or VLAN-based service interface is a good example 205 of an ETI-Agnostic BD. 207 * BDI-Specific EADR - When the uses BDI-Specific 208 Ethernet Auto-discovery mode, the only Ethernet A-D per EVI 209 route of that is called as a BDI-Specific EADR in 210 this draft. 212 * ACI-Specific EADR - When the uses ACI-Specific 213 Ethernet Auto-discovery mode, the Ethernet A-D per EVI routes 214 of that are called as ACI-Specific EADRs in this 215 draft. 217 2. Problem Statement 219 2.1. Problem with Bump-in-the-wire Use-Case 221 The Section 4.3 of [RFC9136] defined the Bump-in-the-wire use-case, 222 where a style (which is called as RT-5E in this draft) of RT-5 routes 223 (whose overlay index is a non-zero ESI), is used to advertise the IP 224 prefix of subnet SN1 (see Figure 3). The RT-5E routes (whose IP 225 prefix is SN1, and ESI is ESI23) of that draft is called as RT5E_SN1 226 in this draft. And the RT-1 routes (whose ESI is ESI23) 227 corresponding to the RT5E_SN1 is called as RT1_ESI23 in this draft. 229 TS2 NVE2 230 +--------------+ +---------------+ 231 | | | | 232 SN7-----(N2-M4)__ | | __(BD-20) | 233 | \ | IF2 | / | 234 | =============== +-------+ 235 | __/ | ESI23 | \__ | | 236 +----- (N1-M2) | + | (BD-10) | | DGW1 237 | | | | | | +---+-----+ 238 | +--------------+ | +---------------+ | (BD-10) | 239 | | | \IRB1 | 240 SN1 | |(IP-VRF) +-+H3 241 | TS3 | NVE3 | /IBR3 | 242 | +--------------+ | +---------------+ | (BD-20) | 243 | | | | | | +---+-----+ 244 +------(N1-M3)__ | + | __(BD-10) | | 245 | \ | ESI23 | / | | 246 | =============== +-------+ 247 | __/ | IF3 | \__ | 248 SN7-----(N2-M5) | | (BD-20) | 249 | | | | 250 +--------------+ +---------------+ 252 Figure 3: RT-1 Confliction of Bump-in-the-wire 254 This network is similar to Figure 7 of Section 4.3 of [RFC9136] with 255 a few notable exceptions as below. 257 The NVE2,NVE3,DGW1,IRB1,BD-10,ESI23,TS2,TS3 and SN1 here is the 258 NVE2,NVE3,DGW1,IRB1,BD-10,ESI23,TS2,TS3 and SN1 there. The N1 here 259 is the Virtual Appliance (whose VA-MAC is M2/M3 on TS2/TS3) there. 261 But here we have another Virtual Appliance N2, which are attached to 262 another Broadcast Domain BD-20. Both BD-10 and BD-20 are integrated 263 into the same IP-VRF by DGW1. But the subnet SN1 can only be reached 264 through BD-10, while the subnet SN7 can only be reached through BD- 265 20. 267 RT5E_SN1 (whose route-target identifying BD-10) is imported into the 268 BD-10 at first, although it can be imported into the IP-VRF following 269 BD-10's IRB interface, RT5E_SN1 will not be imported into the IP-VRF 270 on other PEs which don't have an instance of BD-10. Thus such PEs 271 are precluded from connecting to the hosts of SN1 by such rules. 273 Note that both BD-10 and BD-20 are L2 EVIs of VLAN-based Service 274 Interfaces. 276 The solution for this problem is decribed in Section 3.4. 278 3. Solutions 280 3.1. Determining the Aliasing Pathes for RT-5E 282 In this case, the RT-1 per EVI routes corresponding to that RT-5E 283 route are selected in the context of a BD. 285 When selecting corresponding IP-AD/EVI routes for a RT-5E route, the 286 AOI Extended Community (if it exists) of the RT-5E route is prefered 287 than the ET-ID of the RT-5E route. 289 * Using ET-ID to select BDI-Specific EADRs - There may be multiple 290 Ethernet A-D per EVI routes which all can match the RT-5E's ESI. 291 In such case, The Ethernet A-D per EVI routes with the same ET-ID 292 as the RT-5E should be selected. 294 Note that when the RT-5E's ET-ID is X (X!=0), the ET-IDs of the 295 selected Ethernet A-D per EVI routes (of that RT-5E) should be all 296 X. 298 Note that the RT-5E's ET-ID not only just be used to select 299 Ethernet A-D per EVI routes, but also be encapsulated into data 300 packets in order to keep compatible with ETI-specific Bump-in-the- 301 wire use case. 303 * Using AOI to select ETI-Specific EADRs - There may be multiple 304 Ethernet A-D per EVI routes which all can match the RT-5E's ESI. 305 In such case, The Ethernet A-D per EVI routes whose ET-ID are the 306 same as the RT-5E's AOI should be selected. 308 Note that when the RT-5E's AOI is Y (Y!=0), the ET-IDs of the 309 selected Ethernet A-D per EVI routes (of that RT-5E) should be all 310 Y. 312 Note that when the RT-5E's ET-ID is not 0, and an AOI is advertised 313 along with the RT-5E, the Ethernet A-D per EVI routes of that RT-5E 314 should be selected according to the AOI. 316 Note that when a data packet is load-balanced according to , in Bump-in-the-wire use case, it is the RT-5E's ET-ID which 318 should be encapsulated into the data packet, not the AOI. 320 Note that [I-D.sajassi-bess-evpn-ac-aware-bundling] requires the 321 Presence of Attachment Circuit ID Extended Community MUST be 322 ignored by non multihoming PEs. It requires the remote PE (non- 323 multihome PE, e.g. PE3) MUST process MAC route as defined in 324 [RFC7432]. But the AOI of this case should be used to select ETI- 325 Specific EADRs. This is non-compatible with the Attachment Circuit 326 Extended Community, thus the new ACI-Specific Overlay Index 327 Extended Community is defined. 329 3.2. ACI-specific Overlay Index Extended Community 331 A new EVPN BGP Extended Community called Supplementary Overlay Index 332 is introduced. This new extended community is a transitive extended 333 community with the Type field of 0x06 (EVPN) and the Sub-Type of TBD. 334 It is advertised along with EVPN MAC/IP Advertisement Route (Route 335 Type 2) per [RFC7432] in ACI-Sepecific Ethernet Auto-Discovery mode. 336 It may also be advertised along with EVPN Prefix Advertisement Route 337 (Route Type 5) as per [RFC9136]. Generically speaking, the new 338 extended community must be attached to any routes which are leant 339 over an of ACI-specific Ethernet Auto-Discovery. 341 The Supplementary Overlay Index Extended Community is encoded as an 342 8-octet value as follows: 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Type=0x06 | Sub-Type=TBD | Type |O|Z|F=1| Flags | MBZ | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | MBZ(Cont.) | VLAN2 | VLAN1 | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Figure 4: Supplementary Overlay Index Extended Community 354 o F: Format Indicator, its value is always 1 in this draft. Other 355 values are reserved. 357 o Type: . 359 * 0: VLAN-based AC-ID. 361 +=====+===========+========+=======+=======+=====+ 362 | No. | Use Cases | Type | VLAN2 | VLAN1 | MBZ | 363 +=====+===========+========+=======+=======+=====+ 364 | 1 | untag | type 0 | 0 | 0 | 0 | 365 +-----+-----------+--------+-------+-------+-----+ 366 | 2 | default | type 0 | 0 | FFF | 0 | 367 +-----+-----------+--------+-------+-------+-----+ 368 | 3 | dot1q | type 0 | 0 | E | 0 | 369 +-----+-----------+--------+-------+-------+-----+ 370 | 4 | QinQ | type 0 | E | I | 0 | 371 +-----+-----------+--------+-------+-------+-----+ 373 Table 1: VLAN-based AOIs 374 Notes: 375 E : That field is the External VLAN of the AC. 376 I : That field is the Internal VLAN of the AC. 377 0 : The tag corresponding to that field is absent. 378 FFF : The AC is the default subinterface (Section 3.2) of the 379 corresponding ES. 380 untag : An untagged subinterface should be matched by that 381 format. 382 default : A default subinterface should be matched by that 383 format. When the AC is a default subinterface, it will 384 match all the remaining VLAN-tags (which are left over by 385 other subinterfaces) on its main-interface. 386 dot1q : A dot1q subinterface should be matched by that format. 387 QinQ : A QinQ subinterface should be matched by that format. 388 * 1-15: Reserved. 390 o O Flag: Overlay Index Flag, this extended community is used as 391 overlay index. 393 When type field is 0-1: For ACI-Specific Ethernet auto-discovery 394 mode, when it is carried along with a RT-2 route, the O Flag should 395 be set to 1, For BDI-Specific Ethernet auto-discovery, when it is 396 carried along with a RT-2 route, the O Flag should be set to 0. 398 When the O Flag is set to 1, this AC-ID is also called as AOI (ACI- 399 Specific Overlay Index), and the of that RT-2R or RT-5E 400 should be used to determine ECMP pathes. At the same time, the AOI 401 should also be used like Attachment Circuit ID Extended Community 402 too. 404 Note that only the lowest 8 bits of MBZ field should be used to 405 select RT-1 per EVI routes. 406 of a type-0 AOI forms an Ethernet Tag ID of an ACI-Specific EADR. 408 o Z Flag: Must be zero. Reserved for future use, the receiver 409 should ignore this extended coummunity if Z flag is not zero at 410 now. 412 o Flags: Reserved for future use. it is set to 0 on advertising, and 413 ignored on receiving. 415 Note that although this extended community is similar to the AC-ID 416 extended community (as per 417 [I-D.sajassi-bess-evpn-ac-aware-bundling]), we can assume that they 418 may be of different Sub-Types because that they have different 419 behaviors. 421 3.3. Constructing IP Prefix Advertisement Route 423 When an IP Prefix Advertisement is advertised, The ACI-Specific SOI 424 extended community is recommanded to be carried along with it, if it 425 is not clear that whether there will be conflictions among IP A-D per 426 EVI routes in the future. 428 Note that the ACI-Specific SOI here is not used to isolate IP address 429 spaces. It is just used to resolve its ESI overlay index to a proper 430 IP A-D per EVI route. 432 The AC-ID extended community can't be considered as a substitute of 433 the ET-ID. Because that the AC-ID is not the key of IP A-D per EVI 434 routes, but the ET-ID is. 436 3.4. Bump-in-the-wire Specific Procedures 437 TS2 NVE2 438 +--------------+ +---------------+ 439 | | | | 440 SN7-----(N2-M4)__ | | __(BD-20) | 441 | \ | IF2 | / | 442 | =============== +-------+ 443 | __/ | ESI23 | \__ | | 444 +----- (N1-M2) | + | (BD-10) | | DGW8 445 | | | | | | +---+-----+ 446 | +--------------+ | +---------------+ | (SBD8) | 447 | | | | | 448 SN1 | | |IRB8 | 449 | TS3 | NVE3 | | | 450 | +--------------+ | +---------------+ |(IP-VRF)-+-+H8 451 | | | | | | +---+-----+ 452 +------(N1-M3)__ | + | __(BD-10) | | 453 | \ | ESI23 | / | | 454 | =============== +-------+ 455 | __/ | IF3 | \__ | 456 SN7-----(N2-M5) | | (BD-20) | 457 | | | | 458 +--------------+ +---------------+ 460 Figure 5: SBD of Bump-in-the-wire 462 We can assume that maybe neither BD-10 nor BD-20 will be configured 463 on DGW8, as illustrated in Figure 5. In such case, we assume that a 464 SBD (Supplementary BD) can be provisoned on DGW8. 466 The SBD8 is similar to the SBD of Section 4.4.3 of [RFC9136], except 467 for the following factors: 469 The SBD8 will import all the RT-5E routes and the RT-1 routes 470 which are advertised for BD-10 and BD-20 (and other such BDs of 471 Bump-in-the-wire use cases) by the NVEs of that DC, But the SBD8 472 don't import other EVPN routes. and it don't have to advertise 473 any EVPN routes (e.g. IMET route) because there are no hosts 474 (even the IP address of IRB8 will not be provisoned in this case) 475 in the SBD. 477 Note that DGW3 will advertise the IP prefixes of the IP-VRF using its 478 own EVPN label and route-targets. It don't have to expect any data 479 packets to be received from such SBD. 481 The route advertisement behavior of NVE2 and NVE3 should also be 482 changed: 484 * ACI-specific ethernet auto-discovery mode should be used when NVEs 485 advertise the RT-1 routes of Bump-in-the-wire use case. Otherwise 486 the RT-1 routes from BD-10 and BD-20 will conflict with each 487 other, because that both BD-10 and BD-20 are of VLAN-based 488 Servcice Interface. 490 * ACI-specific Overlay Index extended community should be advertised 491 along with the RT-5E routes. Thus the ET-ID of these RT-5E routes 492 can be set to zero because that BD-10 and BD-20 are ETI-agnostic 493 BDs. 495 Note that the combination of will be used to select the 496 corresponding RT-1 per EVI routes for these RT-5E routes by SBDs 497 of other PEs. 499 The RT-5E routes (for the CE-prefixes behind each BD) should be 500 advertised follows Section 3.3. Note that the IP-ETI, EADR-ETI 501 and IP-ACI should be determined by the outgoing AC per each CE- 502 prefix's VA MAC. The IP-ETI is set to the BD-ID of that outgoing 503 AC's BD. Given that is ACI-Specific EAD mode, the IP-ACI 504 is the AOI extended comunity for that , and the EADR-ETI 505 is the same value as the IP-ACI. 507 * The MAC addresses of IRB interfaces of each BD (e.g. BD-10 and 508 BD-20) should be the same as the SBD IRB interfaces of the same L3 509 EVI, otherwise the source MAC may be not expected to be learnt by 510 the CE-side L2 switches. 512 Note that although the NVEs of the original Bump-in-the-wire don't 513 have an IP-VRF instance, it will be no difficult for the RT5E_SN1 514 and RT1_ESI23 are used when there is an IP-VRF (where SN9 is 515 learnt by a CE-BGP session) and IRBs on each of the NVEs. In such 516 case, maybe it will be better for the NVEs to advertise its IRB 517 (e.g. BD-10's IRB) MAC along with RT1_ESI23 (which is for BD-10) 518 in order to indicate DGW8 to encapsulate that MAC as source MAC. 519 By doing so, there will be no need for SBDs, thus the RT-5E routes 520 and RT-1 per EVI routes can be advertised and imported using the 521 IP-VRF's route-targets. The RT-1 per EVI routes (whose MPLS label 522 identifies that BD) can be advertised along with both BD's RT and 523 IP-VRF's RT. thus the amount of RT-1 per EVI routes will not be 524 increased. 526 Note that in Bump-in-the-wire use cases, the EVPN label that is 527 encapsulated by DGW1/DGW3 for NVE2 or NVE2 will be a label that 528 identifies a L2 EVI. So when the BD is an ETI-Specific BD, the IP- 529 ETI MUST be encapsulated into the ethernet header of the data 530 packets. Otherwise such data packets won't be received by that BD. 532 Note that in Bump-in-the-wire use cases, even if the BD is a MPLS 533 EVPN BD, PE3 should send data packets to NVE2/NVE3 along with the 534 overlay ethernet header (whose SA is the SBD IRB's MAC address), 535 because the Bump-in-the-wire use case is actually a special EVPN IRB 536 use case. Otherwise NVE2/NVE3 can't decapsulate the data packets 537 properly. 539 Note that in such case, the RT-5E routes technically can be directly 540 imported into the IP-VRF identified by its route-target. only if 541 there would be no more than one SBD in a specified IP-VRF. In 542 original Bump-in-the-wire use-case, if there would be no more than 543 one BD in a specified IP-VRF, the the RT-5E routes technically can be 544 directly imported into the IP-VRF identified by its route-target 545 (which is determined by policy, because a RT-5E route itself will be 546 learnt by policy too, according to [RFC9136]). For backward 547 comptibility with such implementations, the ET-ID (if it is not zero) 548 of these RT-5E routes may be used to selected RT-1 per EVI routes 549 from the only BD of that IP-VRF, and in such case it should be 550 encapsulated into the ethernet header (in VXLAN EVPN) of the 551 corresponding data packets, because that the RT-1 per EVI routes of 552 Bump-in-the-wire use case are advertised for BD-10, and BD-10 may use 553 VLAN-aware bundle service interface according to [RFC9136]. 555 The ESIs of these RT-5E routes are used to selecte RT-1 per EVI 556 routes in the context of a BD, as described in [RFC9136]. When the 557 ESIs of RT-5E routes are used to selected RT-1 per EVI routes in the 558 context of an IP-VRF, it seems that this is not explicitly described 559 in [RFC9136]. 561 4. IANA Considerations 563 A new transitive extended community Type of 0x06 and Sub-Type of TBD 564 for EVPN Supplementary Overlay Index Extended Community needs to be 565 allocated by IANA. 567 5. Security Considerations 569 TBD. 571 6. References 573 6.1. Normative References 575 [I-D.sajassi-bess-evpn-ac-aware-bundling] 576 Sajassi, A., Brissette, P., Mishra, M., Thoria, S., 577 Rabadan, J., and J. Drake, "AC-Aware Bundling Service 578 Interface in EVPN", Work in Progress, Internet-Draft, 579 draft-sajassi-bess-evpn-ac-aware-bundling-04, 11 July 580 2021, . 583 [I-D.sajassi-bess-evpn-ip-aliasing] 584 Sajassi, A., Badoni, G., Warade, P., Pasupula, S., Drake, 585 J., and J. Rabadan, "EVPN Support for L3 Fast Convergence 586 and Aliasing/Backup Path", Work in Progress, Internet- 587 Draft, draft-sajassi-bess-evpn-ip-aliasing-02, 8 June 588 2021, . 591 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 592 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 593 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 594 2015, . 596 [RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 597 Rabadan, "Integrated Routing and Bridging in Ethernet VPN 598 (EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021, 599 . 601 [RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and 602 A. Sajassi, "IP Prefix Advertisement in Ethernet VPN 603 (EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021, 604 . 606 6.2. Informative References 608 [I-D.wang-bess-evpn-arp-nd-synch-without-irb] 609 Wang, Y. and Z. Zhang, "ARP/ND Synching And IP Aliasing 610 without IRB", Work in Progress, Internet-Draft, draft- 611 wang-bess-evpn-arp-nd-synch-without-irb-08, 1 September 612 2021, . 615 [I-D.wang-bess-evpn-ether-tag-id-usage] 616 Wang, Y., "Ethernet Tag ID Usage Update for Ethernet A-D 617 per EVI Route", Work in Progress, Internet-Draft, draft- 618 wang-bess-evpn-ether-tag-id-usage-03, 26 August 2021, 619 . 622 [I-D.wz-bess-evpn-vpws-as-vrf-ac] 623 Wang, Y. and Z. Zhang, "EVPN VPWS as VRF Attachment 624 Circuit", Work in Progress, Internet-Draft, draft-wz-bess- 625 evpn-vpws-as-vrf-ac-02, 28 August 2021, 626 . 629 Author's Address 631 Yubao Wang 632 ZTE Corporation 633 No.68 of Zijinghua Road, Yuhuatai Distinct 634 Nanjing 635 China 637 Email: wang.yubao2@zte.com.cn