BESS WG Y. Wang Internet-Draft ZTE Corporation Intended status: Standards Track 6 August 2021 Expires: 7 February 2022 Ethernet Tag ID Usage Update for Ethernet A-D per EVI Route draft-wang-bess-evpn-ether-tag-id-usage-00 Abstract This draft discusses the issues with ESI Overlay Index. Then it proposes an extension to [RFC7432] and [I-D.sajassi-bess-evpn-ip-aliasing] to do ARP synchronizing and IP aliasing for Layer 3 routes that is needed for L3-EVIs to build a complete IP ECMP. It also extended two EVPN Service Interfaces for EVPN VPLS services. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 February 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Wang Expires 7 February 2022 [Page 1] Internet-Draft ET-ID Usage Update August 2021 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Problem with EVPN Signalled L3VPNs . . . . . . . . . . . 3 2.2. Problem with IP-aliasing of EVPN IRB . . . . . . . . . . 5 2.3. Problem with Multipe VLAN-based Service Interface . . . . 6 2.4. Problem with N:1 VLAN-aware Service Interface . . . . . . 7 2.5. Problem with Bump-in-the-wire Use-Case . . . . . . . . . 8 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. ARP/ND Synching and IP Aliasing . . . . . . . . . . . . . 10 3.1.1. Constructing MAC/IP Advertisement Route . . . . . . . 10 3.1.2. Constructing IP-AD/EVI Route . . . . . . . . . . . . 11 3.2. Constructing IP Prefix Advertisement Route . . . . . . . 11 3.3. Forwarding Unicast Packets . . . . . . . . . . . . . . . 12 3.4. Secenario-Specific Procedures . . . . . . . . . . . . . . 12 3.4.1. EVPN-IRB Specific Procedures . . . . . . . . . . . . 12 3.4.2. On Fragmented VLAN-bundle Service Interface . . . . . 13 3.4.3. On N:1 VLAN-aware Service Interface . . . . . . . . . 13 3.4.4. Bump-in-the-wire Specific Procedures . . . . . . . . 14 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Normative References . . . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction In [I-D.wang-bess-evpn-arp-nd-synch-without-irb], the ESI of IP-VRF ACs are advertised as Overlay index of IP forwarding. But in IP-VRF context, the Ethernet A-D per EVI routes of the same ESI are more easier to conflict with each other, when they are imported into the same IP-VRF. This document discribes three secenarios of such kind. Then it discribes the solutions of them. These solutions all need an extension for the Ethernet Tag ID of the Ethernet A-D per EVI routes. But the Ethernet Tag ID of RT-2 routes don't need to be extended, Because they are extended by [I-D.ietf-bess-evpn-modes-interop] already. Then this draft proposes two new Service Interfaces for EVPN VPLS services, they are Fragmented VLAN-bundl Service Interface and N:1 VLAN-aware Service Interface. When different VLANs on the same ES of the same Broadcast Domain can fail independently, these service interfaces will be better than VLAN-bundle and VLAN-aware bundle service interface. Wang Expires 7 February 2022 [Page 2] Internet-Draft ET-ID Usage Update August 2021 1.1. Terminology and Acronyms Most of the acronyms and terms used in this documents comes from [RFC7432], [I-D.wang-bess-evpn-arp-nd-synch-without-irb] and [I-D.sajassi-bess-evpn-ip-aliasing] except for the following: * VRF AC: An Attachment Circuit (AC) that attaches a CE to an IP-VRF but is not an IRB interface. * VRF Interface: An IRB interface or a VRF-AC or an IRC interface. Note that a VRF interface will be bound to the routing space of an IP-VRF. * L3 EVI: An EVPN instance spanning the Provider Edge (PE) devices participating in that EVPN which contains VRF ACs and maybe contains IRB interfaces or IRC interfaces. * IP-AD/EVI: Ethernet Auto-Discovery route per EVI, and the EVI here is an IP-VRF. * IP-AD/ES: Ethernet Auto-Discovery route per ES, and the EVI for one of its route targets is an IP-VRF. * RMAC: Router's MAC, which is signaled in the Router's MAC extended community. * ESI Overlay Index: ESI as overlay index. * ET-ID: Ethernet Tag ID, it is also called ETI for short in this document. * RT-2E: A MAC/IP Advertisement Route with a non-reserved ESI. * RT-5E: An EVPN Prefix Advertisement Route with a non-reserved ESI as its overlay index. 2. Problem Statement 2.1. Problem with EVPN Signalled L3VPNs Wang Expires 7 February 2022 [Page 3] Internet-Draft ET-ID Usage Update August 2021 PE1 PNEC1 +---------------+ +--------------+ | __(IF2.20) | | | IF2 | / \ | | -------=============== (IP-VRF) +-------+ | / / | ESI23 | \__ / | | | .10/ .20/ | + | (IF2.10) | | PE3 | / / | | +---------------+ +---+----+ | +---+ +---+ | | | | SN8+---+N1 | |N2 | | | |(IP-VRF)+-+H3 | +---+ +---+ | | PE2 | | | \ \ | | +---------------+ +---+----+ | .10\ .20\ | + | __(IF3.10) | | | \ \ | ESI23 | / \ | | | -------=============== (IP-VRF) +-------+ | | IF3 | \__ / | +--------------+ | (IF3.20) | +---------------+ Figure 1: RT-1 Confliction of L3EVIs There are three network-elements named N1/N2/N3 in the above network. N1/N2/N3 may be a host or an IP router. When N1/N2/N3 is a host, it is also called H1/H2/H3 in this document. When N1/N2/N3 is a router, it is also called R1/R2/R3 in this document. Consider a pair of multi-homed PEs PE1 and PE2. Let there be two hosts N1 and N2 attached to them via a Physical Network-Element- Container PNEC1. Consider another PE PE3 and a host N3 attached to it. The N1 represent subnet SN1 and the N2 represents subnet SN2. Note that There are no MAC-VRF or IRB interface on PE1/PE2/PE3 in this case. Thus the IP-VRFs are called as EVPN instance instead. Such EVPN instance can be called EVPN signalled L3VPN or L3EVI for short. The anycast gateway IP address (10.0.0.1 of SN1) of N1 is configured on the sub-interfaces IF2.10 and IF3.10, where IF2.10 is a subinterface of IF2, IF3.10 is a subinterface of IF3. The anycast gateway IP address (20.0.0.1 of SN1) of N2 is configured on the sub- interfaces IF2.20 and IF3.20, where IF2.20 is also a subinterface of IF2, IF3.20 is also a subinterface of IF3. IF2.10, IF3.10, IF2.20 and IF3.20 are all VRF Attachment Circuits of the same IP-VRF. Note that the PNEC1 multi-homing PE1 and PE2 via a LAG interface (by whom IF2 and IF3 is aggregated) which maybe load-balance traffic to these PEs. That LAG interface is called as IF23 in this document. IF23 has two subinterfaces, they are IF23.10 and IF23.20. IF23.10 (10.0.0.2) is connected to N1, and IF23.20 (20.0.0.2) is connected to N2. Wang Expires 7 February 2022 [Page 4] Internet-Draft ET-ID Usage Update August 2021 Note that IF23.10 (or IF23.20) is illustrated as two ".10"s (or ".20"s) in Figure 1, but these two ".10"s (or ".20"s) are of the same subinterface. IF2 and IF3 are configured with the same ESI ESI23, thus an Ethernet A-D per EVI route ETI_10_2 is advertsed for IF2.10, an Ethernet A-D per EVI route ETI_10_3 is advertsed for IF3.10, an Ethernet A-D per EVI route ETI_20_2 is advertsed for IF2.20, and an Ethernet A-D per EVI route ETI_20_3 is advertsed for IF3.20. When PE3 receives ETI_10_2 and ETI_20_2, it will pick up only one of them to be installed to the data plane. Because that they have the same and nexthop. We assume that the ETI_20_2 are picked out. When PE3 receives ETI_10_3 and ETI_20_3, it will also pick up only one of them to be installed to the data plane. Because that they also have the same and nexthop. We assume that the ETI_20_3 are picked out. Although PE1 will advertise a RT-5 Route R5_SN8_1 (whose ESI is ESI23) to PE3, When H3 send data packet DP_3_8 to a host in SN8 after IF2.10 fails, PE3 may still send DP_3_8 to PE1 because that PE3 will load-balance traffics just fllowing ETI_20_2 and ETI_20_3. That's a problem that will cause packet-drop or traffic-bypassing. The solution for this problem is decribed in Section 3. 2.2. Problem with IP-aliasing of EVPN IRB PE1 PNEC1 +---------------+ +--------------+ | __(BD-20) | | | IF2 | / \IRB21 | | -------=============== (IP-VRF) +-------+ | / / | ESI23 | \__ /IRB11 | | | .20/ .10/ | + | (BD-10) | | PE3 | / / | | +---------------+ +---+----+ | +---+ +---+ | | | | H1+----+N1 | |N2 | | | |(IP-VRF)+-+H3 | +---+ +---+ | | PE2 | | | \ \ | | +---------------+ +---+----+ | .20\ .10\ | + | __(BD-10) | | | \ \ | ESI23 | / \IRB12 | | | -------=============== (IP-VRF) +-------+ | | IF3 | \__ /IRB22 | +--------------+ | (BD-20) | +---------------+ Figure 2: RT-1 Confliction of EVPN IRB Wang Expires 7 February 2022 [Page 5] Internet-Draft ET-ID Usage Update August 2021 This network is similar to Figure 1 with a few notable exceptions as below. IF2.10, IF2.20, IF3.10 and IF3.20 are ACs of MAC-VRFs, not ACs of IP- VRFs. IF2.10 and IF3.10 are ACs of MAC-VRF BD-10, IF2.20 and IF3.20 are ACs of MAC-VRF BD-20. As a result of that, the previous IP address of IF2.10, IF2.20, IF3.10 and IF3.20 are now configured to IRB11,IRB21, IRB12 and IRB22 correspondingly. Note that IRB11 and IRB12 are IRB interfaces of BD-10 where BD-10 is a Broadcast Domain of VLAN-based Service Interface. IRB21 and IRB22 are IRB interfaces of BD-20 where BD-20 is a Broadcast Domain of VLAN-based Service Interface. According to [I-D.sajassi-bess-evpn-ip-aliasing], the IP A-D per EVI routes R1_210, R1_220, R1_310, R1_320 for IF2.10, IF2.20, IF3.10 and IF3.20 will all have zero Ethernet Tag IDs. When PE3 receives R1_210 and R1_220, it will pick up only one of them to be installed to the data plane. We assume that the R1_220 is picked out. When PE3 receives R1_310 and R1_320, it will pick up only one of them to be installed to the data plane. We assume that the R1_320 is picked out. Although PE1 will advertise a RT-2 Route R2_N1 (whose ESI is ESI23) to PE3, When H3 send data packet DP_3_N1 to N1 after IF2.10 fails, PE3 may still send DP_3_N1 to PE1 because that PE3 will load-balance traffics just fllowing R1_220 and R1_320. That's a problem that will cause packet-drop or traffic-bypassing. The solution for this problem is decribed in Section 3.4.1. 2.3. Problem with Multipe VLAN-based Service Interface Wang Expires 7 February 2022 [Page 6] Internet-Draft ET-ID Usage Update August 2021 PE1 PNEC1 +---------------+ +--------------+ | __(IF2.20) | | | IF2 | / \ | | -------=============== (BD-100) +-------+ | / / | ESI23 | \__ / | | | .20/ .10/ | + | (IF2.10) | | PE3 | / / | | +---------------+ +---+----+ | +---+ +---+ | | | | | |N1 | |N2 | | | |(BD-100)+-+H3 | +---+ +---+ | | PE2 | | | \ \ | | +---------------+ +---+----+ | .20\ .10\ | + | __(IF3.10) | | | \ \ | ESI23 | / \ | | | -------=============== (BD-100) +-------+ | | IF3 | \__ / | +--------------+ | (IF3.20) | +---------------+ Figure 3: RT-1 Confliction of Multiple VLAN-based SI This network is similar to Figure 1 with a few notable exceptions as below. We want the IP addresses of IF23.10, IF23.20 and H3 are of the same subnet (say SN100). As a result of that, IF2.10, IF2.20, IF3.10 and IF3.20 are ACs of the same Bridge-domain BD-100, not ACs of any IP- VRF. Thus none of the four ACs will have an IP address. According to VLAN-based or VLAN-bundl Service Interface per [RFC7432], the Ethernet A-D per EVI routes for IF2.10 and IF2.20 will be the same (say R1_100_2), the Ethernet A-D per EVI routes for IF3.10 and IF3.20 will be the same (say R1_100_3). Both R1_100_2 and R1_100_3 will have a zero Ethernet Tag ID. So when the CFM of subinterface IF2.10 fails, if R1_100_2 is withdrawn, the forwarding of N2's packets (data packets which are destined to N2) will be in the wrong, but if R1_100_2 is not withdrawn, the forwarding of N1's packets will be affected. That's the problem. The solution for this problem is decribed in Section 3.4.2. 2.4. Problem with N:1 VLAN-aware Service Interface This network is similar to Section 2.3 with a few notable exceptions as below. Wang Expires 7 February 2022 [Page 7] Internet-Draft ET-ID Usage Update August 2021 The BD-100 is one of the Broadcast Domains of an EVI of VLAN-aware bundle service interface. Although that EVI is of VLAN-aware bundle Service Interface and the VLANs of IF2.10 and IF2.20 are different, IF2.10 and IF2.20 can't be attached to different BDs of that EVI. Because that we still want the IP addresses of IF23.10, IF23.20 and H3 are of the same subnet (say SN100), like what we have expected in Section 2.3. So we assign the same normalized ET-ID (say ET-ID 100) to IF2.10, IF2.20, IF3.10 and IF3.20. As a result of that, the Ethernet A-D per EVI routes for IF2.10 and IF2.20 will be the same (say R1_100_2b), the Ethernet A-D per EVI routes for IF3.10 and IF3.20 will be the same (say R1_100_3b). Both R1_100_2b and R1_100_3b will have a ET-ID 100. So when the CFM of subinterface IF2.10 fails, if R1_100_2b is withdrawn, the forwarding of N2's packets (those packets destinating to N2) will be in the wrong, but if R1_100_2b is not withdrawn, the forwarding of N1's packets will be affected. That's the problem. Note that this problem will not be resolved even if R1_100_2b can carry two AC-ID Extended Communities (one per AC). The solution for this problem is decribed in Section 3.4.3. 2.5. Problem with Bump-in-the-wire Use-Case Wang Expires 7 February 2022 [Page 8] Internet-Draft ET-ID Usage Update August 2021 TS2 PE1 +--------------+ +---------------+ | | | | SN7-----(N2-M4)__ | | __(BD-20) | | \ | IF2 | / | | =============== +-------+ | __/ | ESI23 | \__ | | +----- (N1-M2) | + | (BD-10) | | PE3 | | | | | | +---+-----+ | +--------------+ | +---------------+ | (BD-10) | | | | \IRB1 | SN1 | |(IP-VRF) +-+H3 | TS3 | PE2 | /IBR3 | | +--------------+ | +---------------+ | (BD-20) | | | | | | | +---+-----+ +----- (N1-M3)__ | + | __(BD-10) | | | \ | ESI23 | / | | | =============== +-------+ | __/ | IF3 | \__ | SN7-----(N2-M5) | | (BD-20) | | | | | +--------------+ +---------------+ Figure 4: RT-1 Confliction of Bump-in-the-wire This network is similar to Figure 7 (section 4.3) of [I-D.ietf-bess-evpn-prefix-advertisement] with a few notable exceptions as below. The PE1 here is the NVE2 there, the PE2 here is the NVE3 there, the PE3 here is the DGW1 there. The N1 here is the Virtual Appliance there. The IRB1 here is the IRB1 there. The ESI23 here is the ESI23 there. The SN1 here is the SN1 there. But here we have another Virtual Appliance N2, which are attached to another Broadcast Domain BD-20. Both BD-10 and BD-20 are integrated into the same IP-VRF by PE3 (DGW1). But the subnet SN1 can only be reached through BD-10, while the subnet SN7 can only be reached through BD-20. Wang Expires 7 February 2022 [Page 9] Internet-Draft ET-ID Usage Update August 2021 As the result of that, the DGW1(PE3) will receive a RT-5 route R5_X (IPL=24, IP=SN1, ESI=ESI23, from NVE2/PE1) and two RT1 routes R1_BD10 and R1_BD20 from NVE2(PE1). These two RT1 routes both can be imported into the same IP-VRF instance. Which RT-1 route will R5_X's ESI overlay index be resolved to? The R1_BD10 or the R1_BD20 ? If R1_BD10 is picked out, then it can't reach SN1 (especially when R5_X is advertised for SN1). If R1_BD20 is picked out, then it can't reach SN7 (especially when R5_X is advertised for SN7). That's the Problem. Note that both BD-10 and BD-20 are EVIs of VLAN-based Service Interfaces. Note that similar problem will occurs when Bump-in-the-wire Use-Case are integrated into the same IP-VRF with an EVPN IRB instance on the same ESI. The solution for this problem is decribed in Section 3.4.4. 3. Solutions Note that the PEs follow [I-D.wang-bess-evpn-arp-nd-synch-without-irb] to achieve the ESI load balance except for the following explicit discription. 3.1. ARP/ND Synching and IP Aliasing 3.1.1. Constructing MAC/IP Advertisement Route This draft introduces a new usage/construction of MAC/IP Advertisement route to enable Aliasing for IP addresses in L3EVI use- cases. The usage/construction of this route remains similar to that described in RFC 7432 with a few notable exceptions as below. * The Route-Distinguisher should be set to the corresponding L3EVI context. * The Ethernet Tag ID should be set to the VLANs of the VRF-AC from where that MAC/IP is learnt. * The ESI SHOULD be set to the ESI of the VRF interface from which the ARP entry is learnt. Note that the is used to install remote synched ARP entries to corresponding VRF interfaces on PE1/PE2. But on PE3, the is used to load balance traffics. Wang Expires 7 February 2022 [Page 10] Internet-Draft ET-ID Usage Update August 2021 * The MAC/IP Advertisement SHOULD carry one or more IP VRF Route- Target (RT) attributes. * The MPLS Label1 should be set to the same pre-configured value for all local ARP entries. It is just used to be compatible with existing RRs. * The MPLS Label2 should be set to the local label of the IP-VRF in MPLS or VXLAN EVPN. But it should be set to implicit-null in SRv6 EVPN. * The RMAC Extended Community attribute SHOULD be carried in VXLAN EVPN. 3.1.2. Constructing IP-AD/EVI Route The usage/construction of this route is similar to the IP-AD per EVI route described in [I-D.sajassi-bess-evpn-ip-aliasing] with a few notable exceptions as below. * The Ethernet Tag ID (ET-ID) should be set to the VLANs of the VRF- AC for which it is advertised. 3.2. Constructing IP Prefix Advertisement Route When an IP Prefix Advertisement is advertised, The Ethernet Tag ID is recommanded to be carried along with it, if it is not clear that whether there will be conflictions among IP A-D per EVI routes in the future. Note that the Ethernet Tag ID here is not used to isolate IP address spaces. It is just used to resolve its ESI overlay index to a proper IP A-D per EVI route. The AC-ID extended community can't be considered as a substitute of the ET-ID. Because that the AC-ID is not the key of IP A-D per EVI routes, but the ET-ID is. Arguably, non-reserved Ethernet Tag ID in the RT-5 route, could be assumed that it is already in [I-D.ietf-bess-evpn-prefix-advertisement], because that when the BD-10 of the Bump-in-the-wire use-case is of an EVI of VLAN-aware bundl service interface, non-reserved ethernet tag ID will be carried along with Ethernet A-D per EVI routes, hence non-reserved Ethernet Tag ID should be carried along with IP Prefix Advertisement Routes too. Otherwise those Ethernet A-D per EVI routes can not be referred by these IP Prefix Advertisement Routes. Wang Expires 7 February 2022 [Page 11] Internet-Draft ET-ID Usage Update August 2021 3.3. Forwarding Unicast Packets When PE3 forward a data packet DP_2021 according to an IP Prefix advertisement route R5_2021 whose overlay index is an ESI, If the ET- ID of R5_2021 is a non-reserved ET-ID, DP_2021 should not be forwarded according to an ethernet A-D per EVI route R1_2021, unless the ET-ID and ESI of R1_2021 are both the same as that of R5_2021. Note that in [I-D.sajassi-bess-evpn-ip-aliasing] the IP-AD per EVI route carries a "Router's MAC" extended community in case the RMAC is not the same among different PEs. In these cases, the inner destination MAC of the corresponding data packets from PE3 to PE1/PE2 must use the RMAC in IP-AD/EVI route instead, even if there is a RMAC in RT-2E route. Note that this is a data-plane update of [I-D.ietf-bess-evpn-prefix-advertisement] for both EVPN signalled L3VPN and [I-D.sajassi-bess-evpn-ip-aliasing]. According to [I-D.ietf-bess-evpn-prefix-advertisement] section 4.3 or [I-D.ietf-bess-evpn-inter-subnet-forwarding] section 3.2.3, the inner destination MAC will follow the RMAC of RT-5E Route or RT-2E Route. 3.4. Secenario-Specific Procedures 3.4.1. EVPN-IRB Specific Procedures PE1 may advertise two IP A-D per EVI routes for subinterface IF2.10, one (say R1_210b) is for BD-10, the other (that R1_210) is for IP- VRF. The Ethernet Tag ID of R1_210b is zero per [RFC7432], but the Ethernet Tag ID of R1_210 is set to the VLANs of IF2.10 according to this draft. When PE1 advertise a RT-5 Route for a prefix behind BD-10, the Ethernet Tag ID of that RT-5 Route is determined by the out-interface (IF2.10) of the MAC of that prefix's overlay nexthop (10.0.0.2). Note that R1_210b will not be imported into the IP-VRF. PE1 may advertise two RT-2 routes for N1's MAC/IP, one (say R2_N1b) is for BD-10, the other (that R2_N1) is for the IP-VRF. The Ethernet Tag ID of R2_N1b is zero per [RFC7432], but the Ethernet Tag ID of R2_N1 is set to the VLANs of IF2.10 according to this draft. The MAC-VRFs and IP-VRFs in this solution will have their own copy of EVPN routes, This issue can be improved using the mechanisms of Section 3.4.2, if interoperation between VLAN-based service interface and VLAN-aware service interface per [I-D.ietf-bess-evpn-modes-interop] is provisioned in this network. Wang Expires 7 February 2022 [Page 12] Internet-Draft ET-ID Usage Update August 2021 3.4.2. On Fragmented VLAN-bundle Service Interface PE1 will advertise different Ethernet A-D per EVI routes for IF2.10 and IF2.20, the Ethernet Tag ID of them will be the VLANs of corresponding AC (IF2.10 or IF2.20). Note that the MAC/IPs on IF2.10 and IF2.20 will be advertised along with such ET-IDs too. When PE3 receives such Ethernet A-D per EVI routes and RT-2 routes, it SHOULD process them following [I-D.ietf-bess-evpn-modes-interop]'s section 3.1.2. As a result of that, although PE3 works in VLAN-based or VLAN-baundle Service Interface, Such MAC/IPs will be istalled in BD-100 and they will be resolved to those Ethernet A-D per EVI routes under the help of such ET-IDs. Such Service Interface is called as Fragmented VLAN-bundl Service Interface or Multiple VLAN-based Service Interface. Because that the VLAN-range are fragmented into multiple separate VLANs. 3.4.3. On N:1 VLAN-aware Service Interface PE1 will advertise different Ethernet A-D per EVI routes for IF2.10 and IF2.20, the Ethernet Tag ID of them will be the VLANs (10 or 20) of corresponding AC (IF2.10 or IF2.20), not the normalized ET-ID (100). Note that the MAC/IPs on IF2.10 and IF2.20 will not be advertised along with such ET-IDs too, They will be advertised along with the normalized ET-ID and the corresponding AC-ID extended community per [I-D.sajassi-bess-evpn-ac-aware-bundling]. When PE3 receives these two Ethernet A-D per EVI routes, it installs them separately. Whe PE3 receives the RT-2 route for N1's address, that route carries the AC-ID 10 of IF2.10, PE3 will resolve it to the Ethernet A-D per EVI routes (in all-active mode) whose ET-ID are 10 (not the normalized ET-ID 100). Whe PE3 receives the RT-2 route for N2's address, that route carries the AC-ID 20 of IF2.20, PE3 will resolve it to the Ethernet A-D per EVI routes (in all-active mode) whose ET-ID are 20 (not the normalized ET-ID 100). Note that [I-D.sajassi-bess-evpn-ac-aware-bundling] requires the Presence of Attachment Circuit ID Extended Community MUST be ignored by non multihoming PEs. It requires the remote PE (non-multihome PE, e.g. PE3) MUST process MAC route as defined in [RFC7432]. That is updated in this section, they are different use-cases. Wang Expires 7 February 2022 [Page 13] Internet-Draft ET-ID Usage Update August 2021 Such Service Interface is called as N:1 VLAN-aware Service Interface. Because that N ACs of the same ES are normalized to the same ET-ID. 3.4.4. Bump-in-the-wire Specific Procedures The advertisement of Ethernet A-D per EVI routes and RT-2 routes are similar to Section 3.4.2. The RT-5 routes (for the prefixes behind each BD) should be advertised along with the Ethernet Tag ID (the same as it is advertised in Ethernet A-D per EVI route) of the outgoing AC per each prefix's VA MAC. 4. IANA Considerations no IANA Considerations. 5. Security Considerations TBD. 6. References 6.1. Normative References [I-D.ietf-bess-evpn-modes-interop] Krattiger, L., Sajassi, A., Thoria, S., Rabadan, J., and J. Drake, "EVPN Interoperability Modes", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-modes-interop-00, 31 May 2021, . [I-D.ietf-bess-srv6-services] Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based Overlay Services", Work in Progress, Internet-Draft, draft-ietf-bess-srv6-services-07, 11 April 2021, . [I-D.sajassi-bess-evpn-ip-aliasing] Sajassi, A., Badoni, G., Warade, P., Pasupula, S., Drake, J., and J. Rabadan, "EVPN Support for L3 Fast Convergence and Aliasing/Backup Path", Work in Progress, Internet- Draft, draft-sajassi-bess-evpn-ip-aliasing-02, 8 June 2021, . Wang Expires 7 February 2022 [Page 14] Internet-Draft ET-ID Usage Update August 2021 [I-D.sajassi-bess-evpn-ac-aware-bundling] Sajassi, A., Brissette, P., Mishra, M. P., Thoria, S., Rabadan, J., and J. Drake, "AC-Aware Bundling Service Interface in EVPN", Work in Progress, Internet-Draft, draft-sajassi-bess-evpn-ac-aware-bundling-04, 11 July 2021, . [I-D.ietf-bess-evpn-prefix-advertisement] Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. Sajassi, "IP Prefix Advertisement in EVPN", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-prefix- advertisement-11, 18 May 2018, . [I-D.ietf-bess-evpn-inter-subnet-forwarding] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. Rabadan, "Integrated Routing and Bridging in EVPN", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-inter- subnet-forwarding-15, 26 July 2021, . [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10.17487/RFC8365, March 2018, . 6.2. Informative References [I-D.wang-bess-evpn-arp-nd-synch-without-irb] Wang, Y. and Z. Zhang, "ARP/ND Synching And IP Aliasing without IRB", Work in Progress, Internet-Draft, draft- wang-bess-evpn-arp-nd-synch-without-irb-06, 4 July 2020, . Wang Expires 7 February 2022 [Page 15] Internet-Draft ET-ID Usage Update August 2021 [I-D.wz-bess-evpn-vpws-as-vrf-ac] Wang, Y. and Z. Zhang, "EVPN VPWS as VRF Attachment Circuit", Work in Progress, Internet-Draft, draft-wz-bess- evpn-vpws-as-vrf-ac-01, 28 July 2021, . Author's Address Yubao Wang ZTE Corporation No.68 of Zijinghua Road, Yuhuatai Distinct Nanjing China Email: wang.yubao2@zte.com.cn Wang Expires 7 February 2022 [Page 16]