Network Working Group A. Sajassi, Ed. Internet-Draft G. Badoni Intended status: Standards Track P. Warade Expires: September 10, 2020 S. Pasupula Cisco J. Drake Juniper J. Rabadan Nokia March 9, 2020 L3 Aliasing and Mass Withdrawal Support for EVPN draft-sajassi-bess-evpn-ip-aliasing-01 Abstract This document proposes an extension to do Aliasing and Backup paths for EVPN layer-3 routes in an IP-VRF. The solution leverages the use of EVPN Ethernet Segments for an efficient layer-3 load-balancing and fast convergence in case of failures. 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 September 10, 2020. Copyright Notice Copyright (c) 2020 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 Sajassi, et al. Expires September 10, 2020 [Page 1] Internet-Draft IP Aliasing Support for EVPN March 2020 carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Ethernet Segments for Host Routes in Symmetric IRB . . . 3 1.2. Ethernet Segments for Prefix routes in IP-VRF-to-IP-VRF use-cases . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology and Conventions . . . . . . . . . . . . . . . 6 2. IP Aliasing and Backup Path . . . . . . . . . . . . . . . . . 7 2.1. Constructing Ethernet A-D per EVPN Instance Route . . . . 8 3. Fast Convergence for Routed Traffic . . . . . . . . . . . . . 9 3.1. Constructing Ethernet A-D per Ethernet Segment Route . . 10 3.1.1. Ethernet A-D Route Targets . . . . . . . . . . . . . 10 3.2. Avoiding convergence issues by synchronizing IP prefixes 10 3.3. Handling Silent Host MAC/IP route IP Aliasing . . . . . . 11 3.4. MAC Aging . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Determining Reachability to Unicast IP Addresses . . . . . . 12 4.1. Local Learning . . . . . . . . . . . . . . . . . . . . . 12 4.2. Remote Learning . . . . . . . . . . . . . . . . . . . . . 12 4.3. Constructing MAC/IP Address Advertisement . . . . . . . . 12 4.3.1. Route Resolution . . . . . . . . . . . . . . . . . . 12 5. Forwarding Unicast Packets . . . . . . . . . . . . . . . . . 13 6. Load Balancing of Unicast Packets . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction This document proposes an extension to do Aliasing and Backup paths for EVPN layer-3 routes in an IP-VRF. The solution leverages the use of EVPN Ethernet Segments for an efficient layer-3 load-balancing and fast convergence in case of failures in two use-cases: a. Inter-subnet-forwarding for host routes in symmetric IRB b. IP-VRF to IP-VRF host or prefix based forwarding Sajassi, et al. Expires September 10, 2020 [Page 2] Internet-Draft IP Aliasing Support for EVPN March 2020 1.1. Ethernet Segments for Host Routes in Symmetric IRB Consider a pair of multi-homing PEs, PE1 and PE2, as illustrated in Figure 1. Let there be a host H1 attached to them. Consider PE3 and a host H3 attached to it. +----------------+ | EVPN | +------+ | | PE1 | +---> | +------+ | RT2 | | | | IP1 +--+---+ +---+ | ES1 +------+ ESI1 | PE3 | H1+--+CE1+--+ | | +-+H3 +---+ | +------+ | | | | PE2 | +--+---+ +------+ | | | | | +------+ | | | +----------------+ Figure 1: Inter-subnet traffic between Multihoming PEs and Remote PE With Asymmetric IRB [I-D.ietf-bess-evpn-inter-subnet-forwarding], if H3 sends inter-subnet traffic to H1, routing will happen at PE3. PE3 will be attached to the destination IRB interface and will trigger ARP/ND requests if it does not have an ARP/ND adjacency to H1. A subsequent routing lookup will resolve the destination MAC to H1's MAC address. Furthermore, H1's MAC will point to an ECMP EVPN destination on PE1 and PE2, either due to host route advertisement from both PE1 and PE2, or due to Ethernet Segment MAC Aliasing as detailed in [RFC7432]. With Symmetric IRB [I-D.ietf-bess-evpn-inter-subnet-forwarding], if H3 sends inter-subnet traffic to H1, a routing lookup will happen at PE3's IP-VRF and this routing lookup will not yield the destination IRB interface and therefore MAC Aliasing is not possible. In order to have per-flow load balancing for H3's routed traffic to H1, an IP ECMP list (to PE1/PE2) needs to be associated to H1's host route in the IP-VRF route-table. If H1 is locally learned only at one of the multi-homing PEs, PE1 or PE2, due to LAG hashing, PE3 will not be able to build an IP ECMP list for the H1 host route. With the extension described in this document, PE3's IP-VRF becomes Ethernet-Segment-aware and builds an IP ECMP list for H1 based on the Sajassi, et al. Expires September 10, 2020 [Page 3] Internet-Draft IP Aliasing Support for EVPN March 2020 advertisement of ES1 along with H1 in a MAC/IP route and the availability of ES1 on PE1 and PE2. In order to know that PE1 and PE2 are attached to ES1, PE3 needs to import AD per ES and AD per EVI routes that PE1/PE2 advertise for ES1. This extension is referred to as "IP Aliasing". If ES1 is configured as "single-active" as opposed to "all-active" in the previous paragraph, this document describes how PE3 can build a primary and backup IP path for H1. In both cases, IP Aliasing and IP backup paths, fast convergence and mass withdraw capabilities are supported in case of failures on the multi-homing PEs. 1.2. Ethernet Segments for Prefix routes in IP-VRF-to-IP-VRF use-cases This document also allows the use of Ethernet Segments in EVPN IP Prefix routes (or routes type 5) [I-D.ietf-bess-evpn-prefix-advertisement] for the purpose of IP Aliasing or IP backup paths. As an example, consider the scenario in Figure 2 in which PE1 and PE2 are multi-homed to CE1. However, and contrary to CE1 in Figure 1, in this case CE1 uses layer-3 links to get connected to PE1 and PE2 in different BDs, and a BGP session established between CE1's loopback address and PE1's IRB address. In these use-cases, typically CE1 supports a single BGP session to one of the PEs (through which it advertises a number of IP Prefixes seating behind itself) and yet, it is desired that remote PEs (e.g., PE3) can build an IP ECMP list or backup IP list including additional PEs (e.g., PE2 in Figure 2). Sajassi, et al. Expires September 10, 2020 [Page 4] Internet-Draft IP Aliasing Support for EVPN March 2020 +-----------------------+ | EVPN | PE1 | | +-------------------+ | | IRB1 | | | +---+ +------+ | -------> | +-----------|BD1|---|IPVRF1| | RT5 | eBGP | | +---+ | | | 50.0/24 | PE3 +------------------------>10.1 +------+ | ESI1 +--------------+ | | +-------------------+ |+------+ | +-----+10.2 | | ^ ||IPVRF1| +---+| | CE1 |-----+ ES1 | | || |-|BD3|--H4 | |-----+ | +----------|+------+ +---+| +-----+20.2 | PE2 | +-----| | lo1 | +--------------+----+ | +--------------+ 1.1.1.1 | | IRB2 | | | Prefixes: | | +---+ +------+ | | | 50.0/24 +-----------|BD2|---|IPVRF1| |<--+ | 60.0/24 | +---+ | | | | | 20.1 +------+ | | +-------------------+ | | | +-----------------------+ Figure 2: Layer-3 Multihoming PEs and Remote PE In order to achieve IP Aliasing or IP Backup path from PE3, PE1 and PE2 interfaces are associated to the same virtual Ethernet Segment (ES1) even though they are attached to different BDs. All the IP Prefixes learned from CE1 are installed in PE1's IP-VRF and subsequently advertised from PE1 as EVPN IP Prefix routes encoding ESI-1 in the Ethernet Segment field. Upon configuration of ES1, both PE1 and PE2 advertise an AD per ES route for ESI1, indicating if the ES works in single-active or all- active mode, as per [RFC7432]. These AD per ES routes are sent along with the set of route-targets of the IP-VRFs attached to the Ethernet Segment. In addition, both PEs advertise an AD per EVI route with the route- target of IP-VRF1, indicating the availability of the IP-VRF to forward routed IP traffic to CE1. PE3 will install the IP Prefix routes associated to ESI1, where ESI1 is resolved to an IP ECMP list (or IP primary and backup paths) formed upon the reception of the AD routes for ESI1. As in the previous example, fast convergence and mass withdrawal capabilities are supported based on the advertisement and withdrawal of the AD per EVI/ES routes. Sajassi, et al. Expires September 10, 2020 [Page 5] Internet-Draft IP Aliasing Support for EVPN March 2020 1.3. Terminology and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. - IRB: Integrated Routing and Bridging - IRB Interface: A virtual interface that connects the bridging module and the routing module on an NVE. - BD: or Broadcast Domain. An EVI may be comprised of one BD (VLAN- based or VLAN Bundle services) or multiple BDs (VLAN-aware Bundle services). - Bridge Table: An instantiation of a broadcast domain on a MAC-VRF. - CE: Customer Edge device, e.g., a host, router, or switch. - EVI: An EVPN instance spanning the Provider Edge (PE) devices participating in that EVPN. - MAC-VRF: A Virtual Routing and Forwarding table for Media Access Control (MAC) addresses on a PE. - Ethernet Segment (ES): When a customer site (device or network) is connected to one or more PEs via a set of Ethernet links, then that set of links is referred to as an 'Ethernet segment'. - Ethernet Segment Identifier (ESI): A unique non-zero identifier that identifies an Ethernet segment is called an 'Ethernet Segment Identifier'. - LACP: Link Aggregation Control Protocol. - PE: Provider Edge device. - Single-Active Redundancy Mode: When only a single PE, among all the PEs attached to an Ethernet segment, is allowed to forward traffic to/from that Ethernet segment for a given VLAN, then the Ethernet segment is defined to be operating in Single-Active redundancy mode. - All-Active Redundancy Mode: When all PEs attached to an Ethernet segment are allowed to forward known unicast traffic to/from that Sajassi, et al. Expires September 10, 2020 [Page 6] Internet-Draft IP Aliasing Support for EVPN March 2020 Ethernet segment for a given VLAN, then the Ethernet segment is defined to be operating in All-Active redundancy mode. - AD per EVI: refers to the Auto-Discovery per EVPN instance routes (type 1). Specified in [RFC7432], they allow for the auto- discovery of all the EVIs attached to a given ES on a given PE. - AD per ES: refers to the Auto-Discovery per ES routes (type 1). Specified in [RFC7432], they allow for the auto-discovery of all the Ethernet Segments attached to a given PE, as well as their characteristics. - VNF: Virtual Network Function. 2. IP Aliasing and Backup Path MAC/IP routes are learned by PEs on the access side via a control plane protocol like ARP/ND, whereas IP Prefix routes are learned by the PEs via a routing protocol, typically BGP (ipv4/ipv6 families). Without IP Aliasing, in case where a CE is multihomed to multiple PE nodes using a LAG and is running in All-Active Redundancy Mode, the Host IP will be learned and advertised in the MAC/IP Advertisement only by the PE that receives the ARP packet. As a result, the remote PE sees only one next-hop for the Host IP and forwards traffic to that advertising PE. Hence, the remote PE is not be able to effectively load balance the traffic towards the multihomed Ethernet Segment. In a similar way, where the CE is multihomed to multiple nodes using a group of active layer-3 interfaces but it uses fewer routing protocol adjacencies than multihoming PEs, the CE IP Prefix routes will be learned and advertised by only the PE(s) that has(have) a routing protocol adjacency with the CE. For example, if we consider the scenario in Figure 2 PE3 sees only one next-hop for CE1 Prefix routes and PE3 is not able to local balance the traffic to CE1. To address this issue, the concept of Aliasing that was introduced [RFC7432] can be extended for Layer 3 routes as well. The PE SHOULD advertise reachability to an IP-VRF instance on a given ES for IP routes using the existing AD per ES/EVI routes. In this case, the EVPN instance is the IP-VRF table to which the host IP address or IP Prefix belongs. This will henceforth be referred to as the IP AD per ES/EVI route. A remote PE that receives an IP route with a non reserved ESI SHOULD consider it reachable by all PEs that have advertised the IP AD per ES/EVI advertisement route for the IP-VRF. An IP AD per ES/EVI route Sajassi, et al. Expires September 10, 2020 [Page 7] Internet-Draft IP Aliasing Support for EVPN March 2020 is considered to be "for the IP-VRF" if it contains the IP-VRF route- target(s). The IP AD per ES route must have the Single-Active bit in the flags of the ESI Label extended community set to 0 for Aliasing to take effect. Otherwise the receiving PE will process the routes for Primary and Backup IP paths. The IP AD per ES route cannot be used for route forwarding until the associated IP AD per ES route is received. In case of Single-Active redundancy mode, the remote PE SHOULD use the IP AD per EVI route EVPN Layer 2 attribute extended community as mentioned in [RFC8214] in combination with the IP AD per ES route to determine the Backup Path for the IP addresses for the given IP VRF context. This alternate path SHOULD be installed as a backup path for the IP address. 2.1. Constructing Ethernet A-D per EVPN Instance Route This document proposes the advertisement of IP AD per EVI routes for IP-VRFs to enable Aliasing or Backup paths for IP addresses. The usage/construction of this route remains similar to that described in [RFC7432] with a few notable exceptions as below. - The Route-Distinguisher should be set to the corresponding IP-VRF context. - The Ethernet Tag should be set to 0. - The IP AD per EVI/ES routes SHOULD carry one or more IP VRF Route- Targets (RT) attributes. - The IP AD per EVI route MUST carry the Router's MAC Extended Community attribute [I-D.ietf-bess-evpn-prefix-advertisement] if the encapsulation among the PE IP-VRFs correspond to that of an Ethernet NVO tunnel. - The MPLS Label usage SHOULD be used as described in [RFC7432] and [RFC8365]. - In case of IP Aliasing, all the PEs that are attached to the same ES will advertise P=1 in the Layer 2 attribute extended community [RFC8214]. - When IP Primary/Backup paths are desired, the Primary PE will advertise P=1 in the Layer 2 extended community, whereas the best Backup PE will advertise P=0, B=1. Sajassi, et al. Expires September 10, 2020 [Page 8] Internet-Draft IP Aliasing Support for EVPN March 2020 o The Primary PE SHOULD be the PE that learns the IP prefix at the access side. o The Primary PE MAY be determined by policy or MAY be elected by a DF Election as in [RFC8584] It is important to note that the prefix for an IP AD per EVI and a layer 2 AD per-EVI may be identical. However, since the Route- Distinguisher (RD) of the IP AD per EVI is set to the corresponding IP-VRF context and the RD of the layer-2 AD per EVI is set to the corresponding MAC-VRF context, the import will happen in the respective IP-VRFs and MAC-VRFs and hence, the prefix will not be overwritten. 3. Fast Convergence for Routed Traffic Host or Prefix reachability is learned via the BGP-EVPN control plane over the MPLS/NVO network. All the host or prefix routes that are connected behind an ES are advertised by the PEs belonging to the redundancy group. A remote PE receiving these routes can loose reachability from any of the PEs either due node reload or core failure or access failure for that PE. To alleviate this, EVPN defines a mechanism to efficiently and quickly signal to remote PE nodes, the need to update their forwarding tables upon the occurrence of a failure in connectivity to an Ethernet segment. This is done by having each PE advertise a set of one or more IP AD per ES routes for each locally attached Ethernet segment (refer to Section 3.1 below for details on how these routes are constructed). A PE may need to advertise more than one IP AD per ES route for a given ES because the ES may be in a multiplicity of IP-VRFs and the Route-Targets for all of these IP-VRFs may not fit into a single route. Advertising a set of IP AD per ES routes for the ES allows each route to contain a subset of the complete set of Route Targets. Each IP AD per ES route is differentiated from the other routes in the set by a different Route Distinguisher (RD). Upon failure in connectivity to the attached ES, the PE withdraws the corresponding set of IP AD per ES routes. This triggers all PEs that receive the withdrawal to update their next-hop adjacencies for all IP addresses associated with the Ethernet Segment in question, across IP-VRFs. If no other PE has advertised an IP AD per ES route for the same Ethernet Segment, then the PE that received the withdrawal simply invalidates the IP entries for that segment. Otherwise, the PE updates its next-hop adjacencies accordingly. Sajassi, et al. Expires September 10, 2020 [Page 9] Internet-Draft IP Aliasing Support for EVPN March 2020 These routes should be processed with higher priority than other EVPN MAC/IP or IP Prefix route withdrawals upon failure. Similar priority processing is needed even on the intermediate Route Reflectors. This document is therefore addressing the mass withdrawal behavior for routed traffic. For Layer 2 traffic, refer to Section 8.2 of [RFC7432]. 3.1. Constructing Ethernet A-D per Ethernet Segment Route This section describes the procedures used to construct the Ethernet A-D per ES route, which is used for fast convergence (as discussed in Section 3). The usage/construction of this route remains similar to that described in section 8.2.1. of [RFC7432] with a few notable exceptions as explained in following sections. 3.1.1. Ethernet A-D Route Targets Each IP Ethernet A-D per ES route MUST carry one or more Route Targets (RTs). The set of IP AD routes per ES MUST carry the entire set of IP-VRF RTs for all the IP-VRFs attached to the ES, in addition to MAC VRF RTs for all the EVPN instances to which the Ethernet Segment belongs. 3.2. Avoiding convergence issues by synchronizing IP prefixes Consider a pair of multi-homing PEs, PE1 and PE2. Let there be a host H1 attached to them. Consider PE3 and a host H3 attached to it. If the host H1 is learned on both the PEs, the ECMP path list is formed on PE3 pointing to (PE1/PE2). Traffic from H3 to H1 is not impacted even if one of the PEs becomes unreachable as the path list gets corrected upon receiving the mass withdrawal route (IP AD per ES route). In a case where H1 is locally learned only on PE1 due to LAG hashing or a single routing protocol adjacency to PE1, at PE3, H1 has ECMP path list (PE1/PE2) using Aliasing as described in this document. Traffic from H3 can reach H1 via either PE1 or PE2. On PE2, all the remote MAC/IP or IP Prefix routes belonging to the same Ethernet Segment that are advertised by the ES peer (e.g., PE1) should be synchronized and installed locally on PE2 but not advertised as local routes by BGP-EVPN. When the traffic from H3 reaches PE2, PE2 will be able forward the traffic to H1 without any convergence delay (caused by triggering ARP/ND to H1 or to the next- hop to reach H1). The synchronization of the ES MAC/IP or IP Prefix Sajassi, et al. Expires September 10, 2020 [Page 10] Internet-Draft IP Aliasing Support for EVPN March 2020 routes across all PEs of the same Ethernet Segment is important to solve convergence issues. 3.3. Handling Silent Host MAC/IP route IP Aliasing Considering the example of Figure 1 for IP Aliasing, if the reachability of PE1 is lost, PE3 will update the ECMP list for H1 to PE2, upon receiving mass withdrawal from PE1. If host H1 is also withdrawn from PE1, then the same route is withdrawn from PE2 and PE3. Hence traffic from H3 to H1 is blackholed till H1 is re-learned on PE2. This blackholing can be much worse if the H1 behaves like a silent host. IP address of H1 will not be re-learned on PE2 till H1 ARP/ND messages or some traffic triggers ARP/ND for H1. PE2 can detect the failure of PE1's reachability in different ways: a. When core failure or node reboot happens on PE1, the next hop tracking to PE1 in the underlay routing protocols can help detect the failure.. b. Upon access failure, PE1 withdraws the IP AD per ES/EVI routes and PE2 can use this as a trigger to detect failure. Thus to avoid blackholing, when PE2 detects loss of reachability to PE1, it should trigger ARP/ND requests for all remote IP prefixes received from PE1 across all affected IP-VRFs. This will force host H1 to reply to the solicited ARP/ND messages from PE2 and refresh both MAC and IP for the corresponding host in its tables. Even in core failure scenario on PE1, PE1 must withdraw all its local layer-2 connectivity, as Layer-2 traffic should not be received by PE1. So when ARP/ND is triggered from PE2 the replies from host H1 can only be received by PE2. Thus H1 will be learned as local route and also advertised from PE2. It is recommended to have a staggered or delayed deletion of the IP routes from PE1, so that ARP/ND refresh can happen on PE2 before the deletion. 3.4. MAC Aging In the same example as in section 3.3, PE1 would do ARP/ND refresh for H1 before it ages out. During this process, H1 on can age out genuinely or due to the ARP/ND reply landing on PE2. PE1 must withdraw the local entry from BGP when H1 entry ages out. PE1 Sajassi, et al. Expires September 10, 2020 [Page 11] Internet-Draft IP Aliasing Support for EVPN March 2020 deletes the entry from the local forwarding only when there are no remote synced entries. 4. Determining Reachability to Unicast IP Addresses 4.1. Local Learning The procedures for local learning do not change from [RFC7432] or [I-D.ietf-bess-evpn-prefix-advertisement]. 4.2. Remote Learning The procedures for remote learning do not change from [RFC7432] or [I-D.ietf-bess-evpn-prefix-advertisement]. 4.3. Constructing MAC/IP Address Advertisement The procedures for constructing MAC/IP Address or IP Prefix Advertisements do not change from [RFC7432] or [I-D.ietf-bess-evpn-prefix-advertisement]. 4.3.1. Route Resolution If the ESI field is set to reserved values of 0 or MAX-ESI, the IP route resolution MUST be based on the MAC/IP or IP Prefix route alone. If the ESI field is set to a non-reserved ESI, the IP route resolution MUST happen only when both the MAC/IP or IP Prefix route and the associated set of IP AD per ES routes have been received. To illustrate this with an example, consider a pair of multi-homed PEs, PE1 and PE2, connected to an all-active Ethernet Segment. A given host with IP address H1 is learned by PE1 but not by PE2. When the MAC/IP or IP Prefix advertisement route from PE1 and a set of IP AD per ES and IP AD per EVI routes from PE1 and PE2 are received, then (1) PE3 can forward traffic destined to H1 to both PE1 and PE2. If after (1) PE1 withdraws the IP AD per ES route, then PE3 will forward the traffic to PE2 only. If after (1) PE2 withdraws the IP AD per ES route, then PE3 will forward the traffic to PE1 only. If after (1) PE1 withdraws the MAC/IP or IP Prefix route, then PE3 will do delayed deletion of H1, as described in section 3.3. If after (1) PE2 advertised the MAC/IP or IP Prefix route, but PE1 withdraws it, PE3 will continue forwarding to both PE1 and PE2 as Sajassi, et al. Expires September 10, 2020 [Page 12] Internet-Draft IP Aliasing Support for EVPN March 2020 long as it has the IP AD per ES and the IP AD per EVI route from both. 5. Forwarding Unicast Packets Refer to Section 5 in [I-D.ietf-bess-evpn-inter-subnet-forwarding] and [I-D.ietf-bess-evpn-prefix-advertisement]. 6. Load Balancing of Unicast Packets The procedures for load balancing of Unicast Packets do not change from [RFC7432] 7. Security Considerations The mechanisms in this document use EVPN control plane as defined in [RFC7432]. Security considerations described in [RFC7432] are equally applicable. This document uses MPLS and IP-based tunnel technologies to support data plane transport. Security considerations described in [RFC7432] and in [RFC8365] are equally applicable. 8. IANA Considerations 9. Contributors 10. Acknowledgments 11. References 11.1. Normative References [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, . [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. Rabadan, "Virtual Private Wire Service Support in Ethernet VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, . [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, . Sajassi, et al. Expires September 10, 2020 [Page 13] Internet-Draft IP Aliasing Support for EVPN March 2020 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet VPN Designated Forwarder Election Extensibility", RFC 8584, DOI 10.17487/RFC8584, April 2019, . 11.2. Informative References [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", draft- ietf-bess-evpn-inter-subnet-forwarding-08 (work in progress), March 2019. [I-D.ietf-bess-evpn-prefix-advertisement] Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- bess-evpn-prefix-advertisement-11 (work in progress), May 2018. Authors' Addresses Ali Sajassi (editor) Cisco MILPITAS, CALIFORNIA 95035 UNITED STATES Email: sajassi@cisco.com G. Badoni Cisco MILPITAS, CALIFORNIA 95035 UNITED STATES Email: gbadoni@cisco.com Sajassi, et al. Expires September 10, 2020 [Page 14] Internet-Draft IP Aliasing Support for EVPN March 2020 P. Warade Cisco MILPITAS, CALIFORNIA 95035 UNITED STATES Email: pwarade@cisco.com S. Pasupula Cisco MILPITAS, CALIFORNIA 95035 UNITED STATES Email: surpasup@cisco.com John E Drake Juniper Email: jdrake@juniper.net Jorge Rabadan Nokia Email: jorge.rabadan@nokia.com Sajassi, et al. Expires September 10, 2020 [Page 15]