idnits 2.17.1 draft-wang-bess-evpn-distributed-bump-in-the-wire-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 : ---------------------------------------------------------------------------- ** 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 120: '...plane is MPLS. The source MAC MUST be...' RFC 2119 keyword, line 346: '...1 route of ESI23 MUST be advertised bo...' RFC 2119 keyword, line 369: '...rget of RT5E_SN1 MUST be set to the ro...' RFC 2119 keyword, line 385: '...T-5E route's ESI MUST be determined by...' RFC 2119 keyword, line 392: '...T-ID of RT5E_SN1 MUST be set to 0. If...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (24 October 2021) is 913 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: 'RFC9135' is defined on line 627, but no explicit reference was found in the text == Unused Reference: 'I-D.wz-bess-evpn-vpws-as-vrf-ac' is defined on line 653, 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 (~~), 5 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 Q. Niu 4 Intended status: Standards Track ZTE Corporation 5 Expires: 27 April 2022 24 October 2021 7 Distributed Bump-in-the-wire Use Case 8 draft-wang-bess-evpn-distributed-bump-in-the-wire-01 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 27 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. Centerlized Inter-subnet Forwarding . . . . . . . . . . . 5 58 2.2. RT-1 Confliction among Multiple Bump-in-the-wires . . . . 6 59 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.1. Supplementary BD for Bump-in-the-wire . . . . . . . . . . 8 61 3.2. Constructing IP Prefix Advertisement Route . . . . . . . 9 62 3.3. ACI-specific Supplementary Overlay Index Extended 63 Community . . . . . . . . . . . . . . . . . . . . . . . . 11 64 3.4. Determining the Aliasing Pathes for RT-5E . . . . . . . . 13 65 3.5. Other Considerations . . . . . . . . . . . . . . . . . . 13 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 6.1. Normative References . . . . . . . . . . . . . . . . . . 14 70 6.2. Informative References . . . . . . . . . . . . . . . . . 15 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 73 1. Introduction 75 As shown in Figure 1, the Bump-in-the-wire use-case of Section 4.3 of 76 [RFC9136] is a centerlized inter-subnet forwarding solution. The 77 centerlized inter-subnet forwarding burdens the DGWs with the L3 78 traffics among different subnets (e.g. SN1 and H3 of Figure 2) 79 inside the same DC. 81 NVE2 DGW1 82 M2 +-----------+ +---------+ +-------------+ 83 +---TS2(VA)--| (BD-10) |-| |----| (BD-10) | 84 | ESI23 +-----------+ | | | IRB1\ | 85 | + | | | (IP-VRF)|---+ 86 | | | | +-------------+ _|_ 87 SN1 | | VXLAN/ | ( ) 88 | | | GENEVE | DGW2 ( WAN ) 89 | + NVE3 | | +-------------+ (___) 90 | ESI23 +-----------+ | |----| (BD-10) | | 91 +---TS3(VA)--| (BD-10) |-| | | IRB2\ | | 92 M3 +-----------+ +---------+ | (IP-VRF)|---+ 93 +-------------+ 95 Figure 1: RFC9136's Figure 7 97 When a SBD is added (see Figure 4) for the IP-VRF instance, using 98 this SBD and its SBD IRB, we can extend the Bump-in-the-wire use case 99 to form a distributed inter-subnet forwarding solution which will not 100 burden the DGWs with the L3 traffics among different subnets inside 101 the same DC. 103 But when multiple Bump-in-the-wires are integrated into the same IP- 104 VRF (as shown in Figure 3), the above extension is not enough, the 105 details are discribed in Section 2.2, thus some futher extensions are 106 introduced to solve that problem. 108 The RT-5 route that specifies an ESI as overlay index is first 109 defined in Section 4.3 of [RFC9136], where the Bump-in-the-wire use 110 case (which is called the first type RT-5E usage) is also defined 111 there. 113 Note that the RT-5E routes (which are called the second type RT-5E 114 usage) of Section 4.3.2 of 115 [I-D.wang-bess-evpn-arp-nd-synch-without-irb] and Section 1.3 of 116 [I-D.sajassi-bess-evpn-ip-aliasing] are different from these RT-5E 117 routes of Bump-in-the-wire use case in the following factors: 119 * Source MAC - The ethernet header can not be absent in the first 120 type usage even if the data plane is MPLS. The source MAC MUST be 121 set to the MAC address of the IRB interface of BD-10 in Bump-in- 122 the-wire usecase. But in the second type usage the ethernet 123 header can be absent if the data plane is MPLS. 125 * Recursive Resolution - The recursive resolution of the first type 126 usage are done in the context of a BD, But the recursive 127 resolution of the second type usage are done in the context of a 128 IP-VRF. 130 * EVPN label - The EVPN label of the corresponding RT-1 per EVI 131 route of the first type usage is a MPLS label which identifies a 132 BD, But the EVPN label of the corresponding RT-1 per EVI route of 133 the second type usage is a MPLS label which identifies an IP-VRF. 135 * ESI - The ESI of the first type usage is attached to a BD, But 136 ESIs of the second type usage are attached to IP-VRFs. 138 The Bump-in-the-wire use case is a special form of EVPN IRB use case, 139 that's why its corresponding RT-1 per EVI routes are resolved in BD 140 context. 142 1.1. Terminology and Acronyms 144 Most of the acronyms and terms used in this documents comes from 145 [RFC9136] and [I-D.wang-bess-evpn-ether-tag-id-usage] except for the 146 following: 148 * VRF AC - An Attachment Circuit (AC) that attaches a CE to an 149 IP-VRF but is not an IRB interface. 151 * VRF Interface - An IRB interface or a VRF-AC or an IRC 152 interface. Note that a VRF interface will be bound to the 153 routing space of an IP-VRF. 155 * L3 EVI - An EVPN instance spanning the Provider Edge (PE) 156 devices participating in that EVPN which contains VRF ACs and 157 maybe contains IRB interfaces or IRC interfaces. 159 * RT-1 per EVI - Ethernet Auto-Discovery route per EVI, and the 160 EVI here is an IP-VRF. Note that the Ethernet Tag ID of an 161 RT-1 per EVI route may be not zero. 163 * IP-AD/ES - Ethernet Auto-Discovery route per ES, and the EVI 164 for one of its route targets is an IP-VRF. 166 * RMAC - Router's MAC, which is signaled in the Router's MAC 167 extended community. 169 * ESI Overlay Index - ESI as overlay index. 171 * ET-ID - Ethernet Tag ID, it is also called ETI for short in 172 this document. 174 * RT-5E - An EVPN Prefix Advertisement Route with a non-reserved 175 ESI as its overlay index (the ESI-as-Overlay-Index-style RT-5) 176 . 178 * CE-BGP - The BGP session between PE and CE. Note that CE-BGP 179 route doesn't have a RD or Route-Target. 181 * CE-Prefix - An IP Prefixes behind a CE is called as that CE's 182 CE-Prefix. 184 * ETI-Agnostic BD - A Broadcast Domain (BD) whose data packets 185 can be received along with any Ethernet Tag ID (ETI). Note 186 that a broadcast domain of an L2 EVI of VLAN-aware bundle 187 service interface is a good example of an ETI-Specific BD. 189 * ETI-Specific BD - A Broadcast Domain (BD) whose data packets 190 are expected to be received along with a normalized Ethernet 191 Tag ID (ETI). Note that a broadcast domain of an L2 EVI of 192 VLAN-bundle or VLAN-based service interface is a good example 193 of an ETI-Agnostic BD. 195 * BDI-Specific EADR - When the uses BDI-Specific 196 Ethernet Auto-discovery mode, the only Ethernet A-D per EVI 197 route of that is called as a BDI-Specific EADR in 198 this draft. 200 * ACI-Specific EADR - When the uses ACI-Specific 201 Ethernet Auto-discovery mode, the Ethernet A-D per EVI routes 202 of that are called as ACI-Specific EADRs in this 203 draft. 205 2. Problem Statement 207 2.1. Centerlized Inter-subnet Forwarding 208 NVE2 DGW1 209 M2 +-----------+ +----------+ +-------------+ 210 +--TS2(VA1)--| (BD-10) |---| | | (BD-30) | 211 | ESI23 +-----------+ | | | \ IRB3 | 212 | + | |---| (IP-VRF) +---+ 213 | | | | | / IRB1 | | 214 SN1 | | | | (BD-10) | | 215 | | | | +-------------+ _|_ 216 | + NVE3 | | ( ) 217 | ESI23 +-----------+ | DC | ( WAN ) 218 +--TS3(VA1)--| (BD-10) |---| Underlay | DGW2 (___) 219 M3 +-----------+ | | +-------------+ | 220 | | | (BD-10) | | 221 NVE8 | | | \ IRB1 | | 222 +----------------+ | |---| (IP-VRF) +---+ 223 H3----+(BD-30)-(IP-VRF)|---| | | / IRB3 | 224 | IRB3 | | | | (BD-30) | 225 +----------------+ +----------+ +-------------+ 227 Figure 2: Centerlized Bump-in-the-wire Use Case 229 As shown in Figure 2, SN1 and H3 are both internal hosts of the same 230 DC. But the communication between them have to pass through a DGW, 231 that's why the DGWs will be burdened with inter-subnet forwarding of 232 the internal hosts. 234 The Section 4.3 of [RFC9136] defined the Bump-in-the-wire use-case, 235 where a style (which is called as RT-5E in this draft) of RT-5 routes 236 (whose overlay index is a non-zero ESI), is used to advertise the IP 237 prefix of subnet SN1 (see Figure 3). The RT-5E routes (whose IP 238 prefix is SN1, and ESI is ESI23) of Section 4.3 of [RFC9136] is 239 called as RT5E_SN1 in this draft. And the RT-1 routes (whose ESI is 240 ESI23) corresponding to the RT5E_SN1 is called as RT1_ESI23 in this 241 draft. 243 Note that when DGW1 or DGW2 receives RT5E_SN1, it should know (before 244 the recursive resolution) that RT5E_SN1's ESI (ESI23) should be 245 resolved in the context of BD-10, not in BD-30 (whether BD-30 is 246 another Bump-in-the-wire BD or not). Because of RT5E_SN1's Route 247 target (which identifies BD-10), DGW1 can know that before the 248 recursive resolution. 250 2.2. RT-1 Confliction among Multiple Bump-in-the-wires 251 TS2 NVE2 252 +------------+ +------------+ 253 | | | | 254 SN7----(VA2-M4)__ | | __(BD-20) | 255 | | \ | IF2 | / | 256 | | >=============< +---+ 257 | | __/ | ESI23 | \__ | | 258 | +---(VA1-M2) | + | (BD-10) | | NVE8 259 | | | | | | | | +---------+ 260 | | +------------+ | +------------+ _+_ | (SBD) | 261 | | | ( ) | | | 262 | SN1 | ( DC )--| |IRB8 | 263 | | TS3 | NVE3 (_ _) | | | 264 | | +------------+ | +------------+ + |(IP-VRF)-+-+H3 265 | | | | | | | | +---------+ 266 | +---(VA1-M3)__ | + | __(BD-10) | | 267 | | \ | ESI23 | / | | 268 | | >=============< +---+ 269 | | __/ | IF3 | \__ | 270 SN7----(VA2-M5) | | (BD-20) | 271 | | | | 272 +------------+ +------------+ 274 Figure 3: ET-ID Confliction of Bump-in-the-wire 276 This network is another view of a part of Figure 4, and it is similar 277 to Section 4.3 of [RFC9136] with a few notable exceptions as below: 279 The NVE2,NVE3,BD-10,ESI23,TS2,TS3 and SN1 here is the NVE2,NVE3,BD- 280 10,ESI23,TS2,TS3 and SN1 there (Section 4.3 of [RFC9136]). The VA1 281 here is the Virtual Appliance (whose VA-MAC is M2/M3 on TS2/TS3) 282 there. The NVE8 here is the DGW1 there. The IRB8 here takes the 283 place of the IRB1 there. 285 But here we have another Bump-in-the-wire instance for Virtual 286 Appliance VA2, which are attached to another Broadcast Domain BD-20. 287 Both BD-10 and BD-20 are integrated into the same IP-VRF by DGW1. 288 But the subnet SN1 can only be reached through BD-10, while the 289 subnet SN7 can only be reached through BD-20. 291 RT5E_SN1 (whose route-target identifying BD-10) is imported into the 292 BD-10 at first, although it can be imported into the IP-VRF following 293 BD-10's IRB interface, RT5E_SN1 will not be imported into the IP-VRF 294 on other PEs which don't have an instance of BD-10. Thus such PEs 295 are precluded from connecting to the hosts of SN1 by such rules. 297 Note that both BD-10 and BD-20 are L2 EVIs of VLAN-based Service 298 Interfaces. 300 The solution for this problem is decribed in Section 3.5. 302 3. Solutions 304 3.1. Supplementary BD for Bump-in-the-wire 306 As shown in Figure 4, the SN1, BD-10, IP-VRF are the same as 307 Figure 2, except that the TS2, TS3 and ESI23 are not shown in 308 Figure 4, but they are still there unchanged. Then we add a SBD for 309 the IP-VRF instance, and each SBD will be configured with an IRB 310 interface (which is called its SBD IRB). Using this SBD and its SBD 311 IRB, we can extend the Bump-in-the-wire use case to form a 312 distributed inter-subnet forwarding solution which will not burden 313 the DGWs with the L3 traffics among different subnets inside the same 314 DC. 316 NVE2 DGW1 317 +----------------+ +--------+ +----------------+ 318 | IRB8b | | | | IRB8d | 319 |(IP-VRF)-(SBD) | | | | (SBD)-(IP-VRF) |-----+ 320 | / IRB1 | | | | | | 321 +---+(BD-10) | | | +----------------+ _+_ 322 | +----------------+ | | ( ) 323 SN1| | | ( WAN ) 324 | NVE3 | | (___) 325 | +----------------+ | | DGW2 + 326 +---+(BD-10) | | DC | +----------------+ | 327 | \ IRB2 | |Underlay| | | | 328 |(IP-VRF)-(SBD) | | | | (SBD)-(IP-VRF) |-----+ 329 | IRB8c | | | | IRB8e | 330 +----------------+ | | +----------------+ 331 | | 332 NVE8 | | 333 +----------------+ | | 334 H3----+(IP-VRF)-(SBD) | | | 335 | IRB8 | | | 336 +----------------+ +--------+ 338 Figure 4: Distributed Bump-in-the-wire Use Case 340 The RT-5 route (say RT5E_SN1) advertised by NVE2/NVE3 for SN1 is the 341 same as Section 4.3 of [RFC9136] except for the following notable 342 differentces: 344 * The route-targets of RT5E_SN1 is set to the export-RT of the SBD. 346 * The RT-1 route of ESI23 MUST be advertised both for BD-10 and the 347 SBD, when they are advertised for the SBD, the EVPN label of the 348 RT-1 per EVI route should be set to the EVPN label of the BD-10, 349 as if it is advertised for BD-10. 351 Note that when it is advertised for the SBD, it may use different 352 RD than it is advertised for BD-10. 354 * In order to process the RT5E_SN1 properly, the DGW1 and DGW2 355 don't have to change its behavior of Section 4.3 of [RFC9136]. 356 But the configurations of DGW1 and DGW2 must be changed, because 357 that the BD-10 is removed and the SBD takes its place. 359 Note that to the RT5E_SN1 route, the NVE8 is actually no different 360 from DGW1 and DGW2. NVE8 is not a DC gateway, but whether NVE8 is a 361 DC gateway is not awared by NVE1 and NVE2. 363 3.2. Constructing IP Prefix Advertisement Route 365 The RT5E_SN1 is constructed following Section 4.3 of [RFC9136] except 366 for the following differences: 368 * Route target and RD 369 The route target of RT5E_SN1 MUST be set to the route-target which 370 identifies the SBD. In other words, RT5E_SN1 is advertise for the 371 SBD, or we can see RT5E_SN1 is advertised in the context of the 372 SBD. 374 The RD of RT5E_SN1 can be set to the RD of SBD too. 376 * ESI and ET-ID 378 No matter whether BD-10 is an ETI-agnostic BD or ETI-specific BD, 379 it will be enough to configure the SBD as an ETI-agnostic BD. But 380 the Ethernet Tag ID of the Ethernet A-D per EVI routes of the SBD 381 may be set to non-reserved ET-IDs. 383 When an CE-prefix of a Bump-in-the-wire instance is advertised by a 384 RT-5E route, The RT-5E route is advertised in the SBD's context. 385 The RT-5E route's ESI MUST be determined by the CE-prefix's VA MAC 386 (which will be known by policy). Take SN1 of Figure 4 for example, 387 by policy, we can know that the VA MAC M1 is in BD-10, then we can 388 know that VA MAC M1 is learnt over , so the ESI of 389 RT5E_SN1 should be set to ESI23. 391 If BD-10 is an ETI-agnostic BD (e.g. BD-10 is of VLAN-based 392 service interface), the ET-ID of RT5E_SN1 MUST be set to 0. If 393 BD-10 is an ETI-specific BD (e.g. BD-10 is of VLAN-aware bundle 394 service interface), the ET-ID of RT5E_SN1 MUST be set to the BD-ID 395 of BD-10 (even if the SBD is ETI-agnostic). 397 Note that the ET-ID of RT5E_SN1 is not used to resolve (as 398 described in Section 3.4) RT5E_SN1's ESI overlay index to a proper 399 Ethernet A-D per EVI route. 401 * ACI-Specific Supplementary Overlay Index 403 When an IP Prefix Advertisement is advertised, The ACI-Specific 404 Supplementary Overlay Index (SOI) extended community is always 405 recommanded to be carried along with it, if it is not clear that 406 whether there will be conflictions among Ethernet A-D per EVI 407 routes inside the SBD in the future. 409 Note that the ACI-Specific SOI here is not used to isolate IP 410 address spaces. It is just used to resolve (as described in 411 Section 3.4) RT5E_SN1's ESI overlay index to a proper Ethernet A-D 412 per EVI route. 414 ACI-specific Overlay Index extended community should be advertised 415 along with the RT-5E routes. Thus the ET-ID of these RT-5E routes 416 can be set to zero if BD-10 and BD-20 are ETI-agnostic BDs. 418 Note that the combination of will be used to select the 419 corresponding RT-1 per EVI routes (in SBD) for these RT-5E routes 420 on other PEs. 422 Note that in the data plane, the EVPN label that is encapsulated by 423 NVE8 for NVE2 or NVE3 will be a label that identifies BD-10. So 424 when BD-10 is an ETI-Specific BD, the ET-ID of RT5E_SN1 MUST be 425 encapsulated into the ethernet header of the data packets. 426 Otherwise such data packets won't be received by BD-10 (of NVE2 or 427 NVE3). 429 3.3. ACI-specific Supplementary Overlay Index Extended Community 431 A new EVPN BGP Extended Community called Supplementary Overlay Index 432 is introduced. This new extended community is a transitive extended 433 community with the Type field of 0x06 (EVPN) and the Sub-Type of TBD. 434 It is advertised along with EVPN MAC/IP Advertisement Route (Route 435 Type 2) per [RFC7432] in ACI-Sepecific Ethernet Auto-Discovery mode. 436 It may also be advertised along with EVPN Prefix Advertisement Route 437 (Route Type 5) as per [RFC9136]. Generically speaking, the new 438 extended community must be attached to any routes which are leant 439 over an of ACI-specific Ethernet Auto-Discovery. 441 The Supplementary Overlay Index Extended Community is encoded as an 442 8-octet value as follows: 444 0 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Type=0x06 | Sub-Type=TBD | Type |O|Z|F=1| Flags | MBZ | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | MBZ(Cont.) | VLAN2 | VLAN1 | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Figure 5: Supplementary Overlay Index Extended Community 454 o F: Format Indicator, its value is always 1 in this draft. Other 455 values are reserved. 457 o Type: . 459 * 0: VLAN-based AC-ID. 460 +=====+===========+========+=======+=======+=====+ 461 | No. | Use Cases | Type | VLAN2 | VLAN1 | MBZ | 462 +=====+===========+========+=======+=======+=====+ 463 | 1 | untag | type 0 | 0 | 0 | 0 | 464 +-----+-----------+--------+-------+-------+-----+ 465 | 2 | default | type 0 | 0 | FFF | 0 | 466 +-----+-----------+--------+-------+-------+-----+ 467 | 3 | dot1q | type 0 | 0 | E | 0 | 468 +-----+-----------+--------+-------+-------+-----+ 469 | 4 | QinQ | type 0 | E | I | 0 | 470 +-----+-----------+--------+-------+-------+-----+ 472 Table 1: VLAN-based AOIs 473 Notes: 474 E : That field is the External VLAN of the AC. 475 I : That field is the Internal VLAN of the AC. 476 0 : The tag corresponding to that field is absent. 478 FFF : The AC is the default subinterface (Section 3.3) of the 479 corresponding ES. 480 untag : An untagged subinterface should be matched by that 481 format. 482 default : A default subinterface should be matched by that 483 format. When the AC is a default subinterface, it will 484 match all the remaining VLAN-tags (which are left over by 485 other subinterfaces) on its main-interface. 486 dot1q : A dot1q subinterface should be matched by that format. 487 QinQ : A QinQ subinterface should be matched by that format. 488 * 1-15: Reserved. 490 o O Flag: Overlay Index Flag, this extended community is used as 491 overlay index. 493 When type field is 0-1: For ACI-Specific Ethernet auto-discovery 494 mode, when it is carried along with a RT-2 route, the O Flag should 495 be set to 1, For BDI-Specific Ethernet auto-discovery, when it is 496 carried along with a RT-2 route, the O Flag should be set to 0. 498 When the O Flag is set to 1, this AC-ID is also called as AOI (ACI- 499 Specific Overlay Index), and the of that RT-2R or RT-5E 500 should be used to determine ECMP pathes. At the same time, the AOI 501 should also be used like Attachment Circuit ID Extended Community 502 too. 504 Note that only the lowest 8 bits of MBZ field should be used to 505 select RT-1 per EVI routes. 506 of a type-0 AOI forms an Ethernet Tag ID of an ACI-Specific EADR. 508 o Z Flag: Must be zero. Reserved for future use, the receiver 509 should ignore this extended coummunity if Z flag is not zero at 510 now. 512 o Flags: Reserved for future use. it is set to 0 on advertising, and 513 ignored on receiving. 515 Note that although this extended community is similar to the AC-ID 516 extended community (as per 517 [I-D.sajassi-bess-evpn-ac-aware-bundling]), we can assume that they 518 may be of different Sub-Types because that they have different 519 behaviors. 521 3.4. Determining the Aliasing Pathes for RT-5E 523 No matter whether a RT-5 route is constructed following Section 4.3 524 of [RFC9136] or Section 3.2 of this draft, the RT-1 per EVI routes 525 corresponding to that RT-5E route will be resolved in the context of 526 a BD, not in an IP-VRF. 528 When resolving corresponding RT-1 per EVI routes for a RT-5E route, 529 the AOI (ACI-specific SOI) Extended Community of the RT-5E route can 530 be used. 532 Note that when the RT-5E's AOI is Y (Y!=0), the ET-IDs of the 533 selected Ethernet A-D per EVI routes (of that RT-5E) should be all Y. 535 Note that when the RT-5E's ET-ID is not 0, and an AOI is advertised 536 along with the RT-5E, the Ethernet A-D per EVI routes of that RT-5E 537 should be selected according to the . 539 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 541 should be encapsulated into the data packet (as 802.1q Tag), not the 542 AOI. 544 Note that [I-D.sajassi-bess-evpn-ac-aware-bundling] requires the 545 Presence of Attachment Circuit ID Extended Community MUST be ignored 546 by non multihoming PEs. It requires the remote PE (non-multihome PE, 547 e.g. PE3) MUST process MAC route as defined in [RFC7432]. But the 548 AOI of this case should be used to select ETI-Specific EADRs. This 549 is non-compatible with the Attachment Circuit Extended Community, 550 thus the new ACI-Specific Overlay Index Extended Community is 551 defined. 553 3.5. Other Considerations 555 We can assume that maybe neither BD-10 nor BD-20 will be configured 556 on NVE8, as illustrated in Figure 4. In such case, we assume that a 557 SBD (Supplementary BD) can be provisoned on NVE8. 559 The SBD is similar to the combination of the SBD of Section 4.4.3 of 560 [RFC9136] and the BD-10 of Section 4.3 of [RFC9136], except for the 561 following factors: 563 The RT-1 per EVI routes advertised for SBD is originated from the 564 BD-10. and the SBD don't have to advertise any EVPN routes (e.g. 565 IMET route) of its own. because there are no hosts (even the IP 566 address of SBD IRB will not be provisoned in this case) in the 567 SBD. 569 Note that DGWs will advertise their own IP prefixes using their own 570 L3 EVPN label and route-targets. They don't have to expect any data 571 packets to be received from such SBD. 573 The route advertisement behavior of NVE2 and NVE3 should also be 574 changed: 576 * When BD-10 advertised a RT-1 per EVI route RT1a, another RT-1 per 577 EVI route RT1b (which is the mirroring of RT1a) should be 578 advertised for the SBD. Although RT1b is advertised for the SBD, 579 RT1b's EVPN label should be set to BD-10's EVPN label, not the 580 SBD's EVPN label. RT1b's ET-ID MUST be set to the AC-ID of the AC 581 corresponding to RT1a. 583 Otherwise the RT-1 per EVI routes for BD-10 and BD-20 will 584 conflict with each other, because that both BD-10 and BD-20 are of 585 VLAN-based Servcice Interface. 587 * The MAC addresses of IRB interface of each Bump-in-the-wire BD 588 (e.g. BD-10 and BD-20) should be the same as the SBD IRB 589 interface of the same L3 EVI, otherwise the source MAC may be not 590 expected to be learnt by the CE-side L2 switches. 592 4. IANA Considerations 594 A new transitive extended community Type of 0x06 and Sub-Type of TBD 595 for EVPN Supplementary Overlay Index Extended Community needs to be 596 allocated by IANA. 598 5. Security Considerations 600 TBD. 602 6. References 604 6.1. Normative References 606 [I-D.sajassi-bess-evpn-ac-aware-bundling] 607 Sajassi, A., Brissette, P., Mishra, M., Thoria, S., 608 Rabadan, J., and J. Drake, "AC-Aware Bundling Service 609 Interface in EVPN", Work in Progress, Internet-Draft, 610 draft-sajassi-bess-evpn-ac-aware-bundling-04, 11 July 611 2021, . 614 [I-D.sajassi-bess-evpn-ip-aliasing] 615 Sajassi, A., Badoni, G., Warade, P., Pasupula, S., Drake, 616 J., and J. Rabadan, "EVPN Support for L3 Fast Convergence 617 and Aliasing/Backup Path", Work in Progress, Internet- 618 Draft, draft-sajassi-bess-evpn-ip-aliasing-02, 8 June 619 2021, . 622 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 623 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 624 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 625 2015, . 627 [RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 628 Rabadan, "Integrated Routing and Bridging in Ethernet VPN 629 (EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021, 630 . 632 [RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and 633 A. Sajassi, "IP Prefix Advertisement in Ethernet VPN 634 (EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021, 635 . 637 6.2. Informative References 639 [I-D.wang-bess-evpn-arp-nd-synch-without-irb] 640 Wang, Y. and Z. Zhang, "ARP/ND Synching And IP Aliasing 641 without IRB", Work in Progress, Internet-Draft, draft- 642 wang-bess-evpn-arp-nd-synch-without-irb-08, 1 September 643 2021, . 646 [I-D.wang-bess-evpn-ether-tag-id-usage] 647 Wang, Y., "Ethernet Tag ID Usage Update for Ethernet A-D 648 per EVI Route", Work in Progress, Internet-Draft, draft- 649 wang-bess-evpn-ether-tag-id-usage-03, 26 August 2021, 650 . 653 [I-D.wz-bess-evpn-vpws-as-vrf-ac] 654 Wang, Y. and Z. Zhang, "EVPN VPWS as VRF Attachment 655 Circuit", Work in Progress, Internet-Draft, draft-wz-bess- 656 evpn-vpws-as-vrf-ac-02, 28 August 2021, 657 . 660 Authors' Addresses 661 Yubao Wang 662 ZTE Corporation 663 No.68 of Zijinghua Road, Yuhuatai Distinct 664 Nanjing 665 China 667 Email: wang.yubao2@zte.com.cn 669 Qibo Niu 670 ZTE Corporation 671 No. 50 Software Ave, Yuhuatai Distinct 672 Nanjing 673 China 675 Email: niu.qibo@zte.com.cn