Internet Engineering Task Force (IETF) J. Rabadan, Ed. Request for Comments: 8388 S. Palislamovic Category: Informational W. Henderickx ISSN: 2070-1721 Nokia A. Sajassi Cisco J. Uttaro AT&T May 2018 Usage and Applicability of BGP MPLS-Based Ethernet VPN
AbstractThis document discusses the usage and applicability of BGP MPLS-based Ethernet VPN (EVPN) in a simple and fairly common deployment scenario. The different EVPN procedures are explained in the example scenario along with the benefits and trade-offs of each option. This document is intended to provide a simplified guide for the deployment of EVPN networks. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8388.
Copyright Notice Copyright (c) 2018 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. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Case Scenario Description and Requirements . . . . . . . 5 3.1. Service Requirements . . . . . . . . . . . . . . . . . . 5 3.2. Why EVPN Is Chosen to Address This Use Case . . . . . . . 7 4. Provisioning Model . . . . . . . . . . . . . . . . . . . . . 7 4.1. Common Provisioning Tasks . . . . . . . . . . . . . . . . 8 4.1.1. Non-Service-Specific Parameters . . . . . . . . . . . 8 4.1.2. Service-Specific Parameters . . . . . . . . . . . . . 9 4.2. Service-Interface-Dependent Provisioning Tasks . . . . . 9 4.2.1. VLAN-Based Service Interface EVI . . . . . . . . . . 10 4.2.2. VLAN Bundle Service Interface EVI . . . . . . . . . . 10 4.2.3. VLAN-Aware Bundling Service Interface EVI . . . . . . 10 5. BGP EVPN NLRI Usage . . . . . . . . . . . . . . . . . . . . . 11 6. MAC-Based Forwarding Model Use Case . . . . . . . . . . . . . 11 6.1. EVPN Network Startup Procedures . . . . . . . . . . . . . 12 6.2. VLAN-Based Service Procedures . . . . . . . . . . . . . . 12 6.2.1. Service Startup Procedures . . . . . . . . . . . . . 13 6.2.2. Packet Walk-Through . . . . . . . . . . . . . . . . . 13 6.3. VLAN Bundle Service Procedures . . . . . . . . . . . . . 17 6.3.1. Service Startup Procedures . . . . . . . . . . . . . 17 6.3.2. Packet Walk-Through . . . . . . . . . . . . . . . . . 18 6.4. VLAN-Aware Bundling Service Procedures . . . . . . . . . 18 6.4.1. Service Startup Procedures . . . . . . . . . . . . . 18 6.4.2. Packet Walk-Through . . . . . . . . . . . . . . . . . 19 7. MPLS-Based Forwarding Model Use Case . . . . . . . . . . . . 20 7.1. Impact of MPLS-Based Forwarding on the EVPN Network Startup . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.2. Impact of MPLS-Based Forwarding on the VLAN-Based Service Procedures . . . . . . . . . . . . . . . . . . . . . . . 21
7.3. Impact of MPLS-Based Forwarding on the VLAN Bundle Service Procedures . . . . . . . . . . . . . . . . . . . 22 7.4. Impact of MPLS-Based Forwarding on the VLAN-Aware Service Procedures . . . . . . . . . . . . . . . . . . . . . . . 22 8. Comparison between MAC-Based and MPLS-Based Egress Forwarding Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Traffic Flow Optimization . . . . . . . . . . . . . . . . . . 24 9.1. Control-Plane Procedures . . . . . . . . . . . . . . . . 24 9.1.1. MAC Learning Options . . . . . . . . . . . . . . . . 24 9.1.2. Proxy ARP/ND . . . . . . . . . . . . . . . . . . . . 25 9.1.3. Unknown Unicast Flooding Suppression . . . . . . . . 25 9.1.4. Optimization of Inter-Subnet Forwarding . . . . . . . 26 9.2. Packet Walk-Through Examples . . . . . . . . . . . . . . 27 9.2.1. Proxy ARP Example for CE2-to-CE3 Traffic . . . . . . 27 9.2.2. Flood Suppression Example for CE1-to-CE3 Traffic . . 27 9.2.3. Optimization of Inter-subnet Forwarding Example for CE3-to-CE2 Traffic . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . 30 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 RFC7432] by discussing the applicability of the technology in a simple and fairly common deployment scenario, which is described in Section 3. After describing the topology and requirements of the use case scenario, Section 4 will describe the provisioning model. Once the provisioning model is analyzed, Sections 5, 6, and 7 will describe the control-plane and data-plane procedures in the example scenario for the two potential disposition/forwarding models: MAC- based and MPLS-based models. While both models can interoperate in the same network, each one has different trade-offs that are analyzed in Section 8. Finally, EVPN provides some potential traffic flow optimization tools that are also described in Section 9 in the context of the example scenario.
Figure 1 depicts the scenario that will be referenced throughout the rest of the document. +--------------+ | | +----+ +----+ | | +----+ +----+ | CE1|-----| | | | | |---| CE3| +----+ /| PE1| | IP/MPLS | | PE3| +----+ / +----+ | Network | +----+ / | | / +----+ | | +----+/ | | | | | CE2|-----| PE2| | | +----+ +----+ | | +--------------+ Figure 1: EVPN Use Case Scenario There are three PEs and three CEs considered in this example: PE1, PE2, and PE3, as well as CE1, CE2, and CE3. Broadcast domains must be extended among the three CEs.
- The following three EVI services are required in this example: EVI100 uses VLAN-based service interfaces in the three CEs with a 1:1 VLAN-to-EVI mapping. The CE-VIDs at the three CEs can be the same (for example, VID 100) or different at each CE (for instance, VID 101 in CE1, VID 102 in CE2, and VID 103 in CE3). A single broadcast domain needs to be created for EVI100 in any case; therefore, CE-VIDs will require translation at the egress PEs if they are not consistent across the three CEs. The case when the same CE-VID is used across the three CEs for EVI100 is referred to in [RFC7432] as the "Unique VLAN" EVPN case. This term will be used throughout this document too. EVI200 uses VLAN bundle service interfaces in CE1, CE2, and CE3 based on an N:1 VLAN-to-EVI mapping. The operator needs to preconfigure a range of CE-VIDs and its mapping to the EVI, and this mapping should be consistent in all the PEs (no translation is supported). A single broadcast domain is created for the customer. The customer is responsible for keeping the separation between users in different CE-VIDs. EVI300 uses VLAN-aware bundling service interfaces in CE1, CE2, and CE3. As in the EVI200 case, an N:1 VLAN-to-EVI mapping is created at the ingress PEs; however, in this case, a separate broadcast domain is required per CE-VID. The CE-VIDs can be different (hence, CE-VID translation is required). Note that in Section 4.2.1, only EVI100 is used as an example of VLAN-based service provisioning. In Sections 6.2 and 7.2, 4k VLAN- based EVIs (EVI1 to EVI4k) are used so that the impact of MAC versus MPLS disposition models in the control plane can be evaluated. In the same way, EVI200 and EVI300 will be described with a 4k:1 mapping (CE-VIDs-to-EVI mapping) in Sections 6.3, 6.4, 7.3, and 7.4. o Broadcast, Unknown Unicast, Multicast (BUM) optimization requirements: - The solution must support ingress replication or P2MP MPLS LSPs on a per EVI service. For example, we can use ingress replication for EVI100 and EVI200, assuming those EVIs will not carry much BUM traffic. On the contrary, if EVI300 is presumably carrying a significant amount of multicast traffic, P2MP MPLS LSPs can be used for this service. - The benefit of ingress replication compared to P2MP LSPs is that the core routers will not need to maintain any multicast states.
RFC4761], [RFC4762], and [RFC6074] cannot meet the requirements in Section 3, whereas EVPN can. For example: o If CE2 has a single CE-VID (or a few CE-VIDs), the current VPLS multihoming solutions (based on load-balancing per CE-VID or service) do not provide the optimized link utilization required in this example. EVPN provides the flow-based, load-balancing, multihoming solution required in this scenario to optimize the upstream/downstream link utilization between CE2 and PE1-PE2. o EVPN provides a fast convergence solution that is independent of the CE-VIDs in the multihomed PEs. Upon failure on the link between CE2 and PE1, PE3 can immediately send the traffic to PE2 based on a single notification message being sent by PE1. This is not possible with VPLS solutions. o With regard to service interfaces and mapping to broadcast domains, while VPLS might meet the requirements for EVI100 and EVI200, the VLAN-aware bundling service interfaces required by EVI300 are not supported by the current VPLS tools. The rest of the document will describe how EVPN can be used to meet the service requirements described in Section 3 and even optimize the network further by: o providing the user with an option to reduce (and even suppress) ARP (Address Resolution Protocol) flooding; and o supporting ARP termination and inter-subnet forwarding. RFC7209] is the ease of provisioning. BGP parameters and service context parameters should be auto-provisioned so that the addition of a new MAC-VRF to the EVI requires a minimum number of single-sided provisioning touches. However, this is possible only in a limited number of cases. This section describes the provisioning tasks required for the services described in Section 3, i.e., EVI100 (VLAN-based service interfaces), EVI200 (VLAN bundle service interfaces), and EVI300 (VLAN-aware bundling service interfaces).
RFC7432]. Note that the ESI must be unique across all the PEs in the network; therefore, the auto-provisioning of the ESI is recommended only in case the CEs are managed by the operator. Otherwise, the ESI should be manually provisioned (Type 0, as in [RFC7432]) in order to avoid potential conflicts. o ES-Import Route Target (ES-Import RT): This is the RT that will be sent by PE1 and PE2, along with the ES route. Regardless of how the ESI is provisioned in PE1 and PE2, the ES-Import RT must always be auto-derived from the 6-byte MAC address portion of the ESI value. o Ethernet Segment Route Distinguisher (ES RD): This is the RD to be encoded in the ES route, and it is the Ethernet Auto-Discovery (A-D) route to be sent by PE1 and PE2 for the CE2 ESI. This RD should always be auto-derived from the PE-IP address, as described in [RFC7432]. o Multihoming type: The user must be able to provision the multihoming type to be used in the network. In our use case, the multihoming type will be set to all-active for the CE2 ESI. This piece of information is encoded in the ESI Label extended community flags and is sent by PE1 and PE2 along with the Ethernet A-D route for the CE2 ESI.
In addition, the same LACP parameters will be configured in PE1 and PE2 for the ES so that CE2 can send frames to PE1 and PE2 as though they were forming a single system. Section 4.2.
RFC7432], and it will be comprised of [PE-IP]:[zero-padded-VID]; where [PE-IP] is the IP address of the PE (a loopback address) and [zero-padded-VID] is a 2-byte value where the low-order 12 bits are the VID (VID 100 in our example) and the high-order 4 bits are zero. o The auto-derived MAC-VRF RT will be composed of [AS]:[zero-padded- VID]; where [AS] is the Autonomous System that the PE belongs to and [zero-padded-VID] is a 2- or 4-byte value where the low-order 12 bits are the VID (VID 100 in our example) and the high-order bits are zero. Note that auto-deriving the RT implies supporting a basic any-to-any topology in the EVI and using the same import and export RT in the EVI. If EVI100 is not a "unique-VLAN" instance, each individual CE-VID must be configured in each PE, and MAC-VRF RDs and RTs cannot be auto-derived; hence, they must be provisioned by the user.
Therefore, besides the CE-VID bundle range bound to EVI300 in each PE, associations between each individual CE-VID and the corresponding EVPN Ethernet Tag must be provisioned by the user. No auto-derived EVI RDs/RTs are possible. RFC7432] defines four different route types and four different extended communities. However, not all the PEs in an EVPN network must generate and process all the different routes and extended communities. Table 1 shows the routes that must be exported and imported in the use case described in this document. "Export", in this context, means that the PE must be capable of generating and exporting a given route, assuming there are no BGP policies to prevent it. In the same way, "Import" means the PE must be capable of importing and processing a given route, assuming the right RTs and policies. "N/A" means neither import nor export actions are required. +-----------------+---------------+---------------+ | BGP EVPN Routes | PE1-PE2 | PE3 | +-----------------+---------------+---------------+ | ES | Export/Import | N/A | | A-D per ESI | Export/Import | Import | | A-D per EVI | Export/Import | Import | | MAC | Export/Import | Export/Import | | Inclusive Mcast | Export/Import | Export/Import | +-----------------+---------------+---------------+ Table 1: Base EVPN Routes and Export/Import Actions PE3 is required to export only MAC and Inclusive Multicast (Mcast) routes and be able to import and process A-D routes as well as MAC and Inclusive Multicast routes. If PE3 did not support importing and processing A-D routes per ESI and per EVI, fast convergence and aliasing functions (respectively) would not be possible in this use case.
RFC7432]. Once the LAG is properly set up, the ESI for the CE2 Ethernet Segment (for example, ESI12) can be auto-generated by PE1 and PE2 from the LACP information exchanged with CE2 (ESI Type 1), as discussed in Section 4.1. Alternatively, the ESI can also be manually provisioned on PE1 and PE2 (ESI Type 0). PE1 and PE2 will auto-configure a BGP policy that will import any ES route matching the auto-derived ES-Import RT for ESI12. o Ethernet Segment route exchange and Designated Forwarder (DF) election: PE1 and PE2 will advertise a BGP Ethernet Segment route for ESI12, where the ESI RD and ES-Import RT will be auto- generated as discussed in Section 4.1.1. PE1 and PE2 will import the ES routes of each other and will run the DF election algorithm for any existing EVI (if any, at this point). PE3 will simply discard the route. Note that the DF election algorithm can support service carving so that the downstream BUM traffic from the network to CE2 can be load-balanced across PE1 and PE2 on a per-service basis. At the end of this process, the network infrastructure is ready to start deploying EVPN services. PE1 and PE2 are aware of the existence of a shared Ethernet Segment, i.e., ESI12. Section 4.2.1) and great control over each individual customer broadcast domain. We assume in this section that the range of EVIs from 1 to 4k is provisioned in the network.
RFC7432], each Ethernet A-D route per ESI is differentiated from the other routes in the set by a different Route Distinguisher (ES RD). This set will also include ESI Label extended communities with the active-standby flag set to zero (all-active multihoming type) and an ESI Label different from zero (used for split-horizon functions). These routes will be imported by the three PEs, since the RTs match the locally configured EVI RTs. The A-D routes per ESI will be used for fast convergence and split-horizon functions, as discussed in [RFC7432]. o Ethernet A-D routes per EVI (4k routes): An A-D route per EVI will be sent by PE1 and PE2 for ESI12. Each individual route includes the corresponding EVI RT and an MPLS Label to be used by PE3 for the aliasing function. These routes will be imported by the three PEs.
b. Based on the CE-VID, the frame is identified to be forwarded in the MAC-VRF-1 (EVI1) context. A source MAC lookup is done in the MAC FIB, and the sender's CE1-IP is looked up in the proxy ARP table within the MAC-VRF-1 (EVI1) context. If CE1-MAC/CE1-IP are unknown in both tables, three actions are carried out (assuming the source MAC is accepted by PE1): 1. the forwarding state is added for the CE1-MAC associated with the corresponding port and CE-VID; 2. the ARP request is snooped and the tuple CE1-MAC/CE1-IP is added to the proxy ARP table; and 3. a BGP MAC Advertisement route is triggered from PE1 containing the EVI1 RD and RT, ESI=0, Ethernet-Tag=0, and CE1-MAC/CE1-IP, along with an MPLS Label assigned to MAC- VRF-1 from the PE1 Label space. Note that depending on the implementation, the MAC FIB and proxy ARP learning processes can independently send two BGP MAC advertisements instead of one (one containing only the CE1-MAC and another one containing CE1-MAC/CE1-IP). Since we assume a MAC forwarding model, a label per MAC-VRF is normally allocated and signaled by the three PEs for MAC Advertisement routes. Based on the RT, the route is imported by PE2 and PE3, and the forwarding state plus the ARP entry are added to their MAC-VRF-1 context. From this moment on, any ARP request from CE2 or CE3 destined to CE1-IP can be directly replied to by PE1, PE2, or PE3, and ARP flooding for CE1-IP is not needed in the core. c. Since the ARP frame is a broadcast frame, it is forwarded by PE1 using the Inclusive Multicast Tree for EVI1 (CE-VID=1 tag should be kept if translation is required). Depending on the type of tree, the label stack may vary. For example, assuming ingress replication, the packet is replicated to PE2 and PE3 with the downstream allocated labels and the P2P LSP transport labels. No other labels are added to the stack. d. Assuming PE1 is the DF for EVI1 on ESI12, the frame is locally replicated to CE2. e. The MPLS-encapsulated frame gets to PE2 and PE3. Since PE2 is non-DF for EVI1 on ESI12, and there is no other CE connected to PE2, the frame is discarded. At PE3, the frame is de-encapsulated and the CE-VID is translated, if needed, and forwarded to CE3.
Any other type of BUM frame from CE1 would follow the same procedures. BUM frames from CE3 would follow the same procedures too. BUM frame example from CE2: a. An ARP request with CE-VID=1 is issued from source MAC CE2-MAC to find the MAC address of CE3-IP. b. CE2 will hash the frame and will forward it to, for example, PE2. Based on the CE-VID, the frame is identified to be forwarded in the EVI1 context. A source MAC lookup is done in the MAC FIB and the sender's CE2-IP is looked up in the proxy ARP table within the MAC-VRF-1 context. If both are unknown, three actions are carried out (assuming the source MAC is accepted by PE2): 1. the forwarding state is added for the CE2-MAC associated with the corresponding LAG/ESI and CE-VID; 2. the ARP request is snooped and the tuple CE2-MAC/CE2-IP is added to the proxy ARP table; and 3. a BGP MAC Advertisement route is triggered from PE2 containing the EVI1 RD and RT, ESI=12, Ethernet-Tag=0, and CE2-MAC/CE2-IP, along with an MPLS Label assigned from the PE2 Label space (one label per MAC-VRF). Again, depending on the implementation, the MAC FIB and proxy ARP learning processes can independently send two BGP MAC advertisements instead of one. Note that since PE3 is not part of ESI12, it will install the forwarding state for CE2-MAC as long as the A-D routes for ESI12 are also active on PE3. On the contrary, PE1 is part of ESI12, therefore PE1 will not modify the forwarding state for CE2-MAC if it has previously learned CE2-MAC locally attached to ESI12. Otherwise, it will add the forwarding state for CE2-MAC associated with the local ESI12 port. c. Assuming PE2 does not have the ARP information for CE3-IP yet, and since the ARP is a broadcast frame and PE2 is the non-DF for EVI1 on ESI12, the frame is forwarded by PE2 in the Inclusive Multicast Tree for EVI1, thus adding the ESI Label for ESI12 at the bottom of the stack. The ESI Label has been previously allocated and signaled by the A-D routes for ESI12. Note that, as per [RFC7432], if the result of the CE2 hashing is different and the frame is sent to PE1, PE1 should add the ESI Label too (PE1 is the DF for EVI1 on ESI12).
d. The MPLS-encapsulated frame gets to PE1 and PE3. PE1 de-encapsulates the Inclusive Multicast Tree Label(s) and, based on the ESI Label at the bottom of the stack, it decides to not forward the frame to the ESI12. It will pop the ESI Label and will replicate it to CE1, since CE1 is not part of the ESI identified by the ESI Label. At PE3, the Inclusive Multicast Tree Label is popped and the frame forwarded to CE3. If a P2MP LSP is used as the Inclusive Multicast Tree for EVI1, PE3 will find an ESI Label after popping the P2MP LSP Label. The ESI Label will simply be popped, since CE3 is not part of ESI12. Unicast frame example from CE3 to CE1: a. A unicast frame with CE-VID=1 is issued from source MAC CE3-MAC and destination MAC CE1-MAC (we assume PE3 has previously resolved an ARP request from CE3 to find the MAC of CE1-IP and has added CE3-MAC/CE3-IP to its proxy ARP table). b. Based on the CE-VID, the frame is identified to be forwarded in the EVI1 context. A source MAC lookup is done in the MAC FIB within the MAC-VRF-1 context and this time, since we assume CE3-MAC is known, no further actions are carried out as a result of the source lookup. A destination MAC lookup is performed next and the label stack associated with the MAC CE1-MAC is found (including the label associated with MAC-VRF-1 in PE1 and the P2P LSP Label to get to PE1). The unicast frame is then encapsulated and forwarded to PE1. c. At PE1, the packet is identified to be part of EVI1 and a destination MAC lookup is performed in the MAC-VRF-1 context. The labels are popped and the frame is forwarded to CE1 with CE-VID=1. Unicast frames from CE1 to CE3 or from CE2 to CE3 follow the same procedures described above. Unicast frame example from CE3 to CE2: a. A unicast frame with CE-VID=1 is issued from source MAC CE3-MAC and destination MAC CE2-MAC (we assume PE3 has previously resolved an ARP request from CE3 to find the MAC of CE2-IP). b. Based on the CE-VID, the frame is identified to be forwarded in the MAC-VRF-1 context. We assume CE3-MAC is known. A destination MAC lookup is performed next and PE3 finds CE2-MAC associated with PE2 on ESI12, an Ethernet Segment for which PE3 has two active A-D routes per ESI (from PE1 and PE2) and two active A-D routes for EVI1 (from PE1 and PE2). Based on a
hashing function for the frame, PE3 may decide to forward the frame using the label stack associated with PE2 (label received from the MAC Advertisement route) or the label stack associated with PE1 (label received from the A-D route per EVI for EVI1). Either way, the frame is encapsulated and sent to the remote PE. c. At PE2 (or PE1), the packet is identified to be part of EVI1 based on the bottom label, and a destination MAC lookup is performed. At either PE (PE2 or PE1), the FIB lookup yields a local ESI12 port to which the frame is sent. Unicast frames from CE1 to CE2 follow the same procedures. RFC7432].
o Ethernet A-D routes per EVI (one route): An A-D route (EVI200) will be sent by PE1 and PE2 for ESI12. This route includes the EVI200 RT and an MPLS Label to be used by PE3 for the aliasing function. This route will be imported by the three PEs. Section 6.2.2 for more information about the control- plane and forwarding-plane interaction for BUM and unicast traffic from the different CEs.
tree per customer broadcast domain can be set up. Note that ingress replication or P2MP LSPs can optionally be signaled in the PMSI Tunnel attribute and the corresponding tree be created. In the described use case, since all the CE-VIDs and Ethernet Tags are defined on the three PEs, multicast tree aggregation might make sense in order to save forwarding states. o Ethernet A-D routes per ESI (one route for ESI12): A single A-D route for ESI12 will be issued from PE1 and PE2. This route will include a single RT (RT for EVI300), an ESI Label extended community with the active-standby flag set to zero (all-active multihoming type), and an ESI Label different than zero (used by the non-DF for split-horizon functions). This route will be imported by the three PEs, since the RT matches the locally configured EVI300 RT. The A-D routes per ESI will be used for fast convergence and split-horizon functions, as described in [RFC7432]. o Ethernet A-D routes per EVI: A single A-D route (EVI300) may be sent by PE1 and PE2 for ESI12 in case no CE-VID translation is required. This route includes the EVI300 RT and an MPLS Label to be used by PE3 for the aliasing function. This route will be imported by the three PEs. Note that if CE-VID translation is required, an A-D per EVI route is required per Ethernet Tag (4k). Section 6.2.2 are as follows: o At the ingress PE, the frames are identified to be forwarded in the EVI300 context as long as their CE-VID belong to the range defined in the PE port to the CE. In addition to it, CE-VID=x is mapped to a "normalized" Ethernet-Tag=y at the MAC-VRF-300 (where x and y might be equal if no translation is needed). Qualified learning is now required (a different bridge table is allocated within MAC-VRF-300 for each Ethernet Tag). Potentially, the same MAC could be learned in two different Ethernet Tag bridge tables of the same MAC-VRF. o Any new locally learned MAC on the MAC-VRF-300/Ethernet-Tag=y interface is advertised by the ingress PE in a MAC Advertisement route using the now Ethernet Tag field (Ethernet-Tag=y) so that the remote PE learns the MAC associated with the MAC-VRF-300/
Ethernet-Tag=y FIB. Note that the Ethernet Tag field is not used in advertisements of MACs learned on VLAN-based or VLAN-bundle service interfaces. o At the ingress PE, BUM frames are sent to the corresponding flooding tree for the particular Ethernet Tag they are mapped to. Each individual Ethernet Tag can have a different flooding tree within the same EVI300. For instance, Ethernet-Tag=y can use ingress replication to get to the remote PEs, whereas Ethernet- Tag=z can use a P2MP LSP. o At the egress PE, Ethernet-Tag=y (for a given broadcast domain within MAC-VRF-300) can be translated to egress CE-VID=x. That is not possible for VLAN bundle interfaces. It is possible for VLAN- based interfaces, but it requires a separate MAC-VRF per CE-VID.