Network Working Group G. Liu Internet-Draft H. Wang Intended status: Standards Track Huawei Technologies Expires: January 9, 2020 July 08, 2019 EVPN DEFAULT MAC draft-glendon-bess-evpn-default-mac-00 Abstract A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) with all-active links. This draft specifies a mechanism of default mac to reduce amounts of advertising mac route and enhance EVPN network reliability. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 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 January 9, 2020. Copyright Notice Copyright (c) 2019 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 Liu & Wang Expires January 9, 2020 [Page 1] Internet-Draft EVPN DEFAULT MAC July 2019 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Situation Anyalisis . . . . . . . . . . . . . . . . . . . 2 1.2. Alternative Solutions . . . . . . . . . . . . . . . . . . 3 1.3. Design Requirement . . . . . . . . . . . . . . . . . . . 3 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Default MAC Capability negotiation . . . . . . . . . . . . . 5 4. Default MAC Actions . . . . . . . . . . . . . . . . . . . . . 6 4.1. Mac Route Extension . . . . . . . . . . . . . . . . . . . 6 4.2. Default MAC Flow Transmission . . . . . . . . . . . . . . 6 5. Application Senario . . . . . . . . . . . . . . . . . . . . . 7 5.1. Remote Interaction . . . . . . . . . . . . . . . . . . . 7 5.2. Local Interaction . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) with links used in the all-active redundancy mode. That mode is where a device is multihomed to a group of two or more PEs and where all PEs in such a redundancy group can forward traffic to/from the multihomed device or network for a given VLAN (RFC7209). This draft specifies a mechanism of default mac to reduce amounts of advertising mac route and enhance EVPN network reliability. 1.1. Situation Anyalisis One of the biggest features of EVPN is to transfer the VPLS network side MAC address learning and publishing process from the data plane to the control plane.But it also brings obvious drawbacks. Firstly, compared with the route aggregation in the EVPN L3VPN scenario, the MAC address of the control plane cannot be aggregated, which results in a large overhead for large-scale user MAC advertisements. Secondly, different from routing, the local MAC address will age Liu & Wang Expires January 9, 2020 [Page 2] Internet-Draft EVPN DEFAULT MAC July 2019 periodically, causing intermittent MAC revoke routing in all EVPN network. This kind of route revocation is directed to the EVPN network, which has a great impact on the performance of the network. At last, EVPN advertises all user MACs to all reachable neighbors. For a single device, the MAC capacity is equal to the sum of MACs sent by all neighbors. However, the mac capacity of a single device is limited. The risk of insufficient MAC is widespread. MAC Once exceeded, the EVPN network data traffic will be flooded. 1.2. Alternative Solutions The MAC routing in 1.1 is based on the risk that the flooding of the EVPN neighbors on the control plane may cause flooding of the network traffic. Without modifying the basic principles of protocol interaction and traffic forwarding, there are two main solutions for mitigating risks: 1) Statically limit the number of local MAC learning on the AC side of the routing source device. This limitation can be either interface-based or broardcast domain-based. This solution has a certain protection effect on the large-size MAC traffic injection on the access side. 2) For the routing initiator device to limit the number of PEER-level MAC routes to be advertised, the solution is especially applicable to scenarios where the user MAC traffic is not large but the number of EVPN neighbors is large. A scene with a large number of user MAC addresses and a large number of EVPN neighbors needs to be combined with 1) for protection. 1.3. Design Requirement Although the user local MAC restriction and the neighbor-based MAC restriction mentioned in 1.2 have an inhibitory effect on the size of the entire network MAC route, the disadvantages are obvious: 1) The number of access users and the number of neighbors in each device in the network are different, and the order of magnitude may vary greatly. Therefore, the network administrator must be aware of the dynamic changes of users and neighbors, and adjust the MAC limit value in real time. The cost of maintenance is very high. 2) When the network environment is unstable, there may be a large number of illegal user MAC attacks. The device cannot identify the illegal MAC address and the legal MAC address. The illegal MAC address causes the global MAC address to reach the upper limit. The data traffic destined for the legitimate user MAC on the network side continues to be flooded. Liu & Wang Expires January 9, 2020 [Page 3] Internet-Draft EVPN DEFAULT MAC July 2019 In order to avoid the problem that the number of network MAC routes increases exponentially with the number of users and neighbors, the solution of default MAC route generation and release is proposed by referring to the default route scheme of the L3VPN scenario. Draft ietf-bess-dci-evpn-overlay-10#section-3.5.1 only mentions the concept of all-zero MAC routing, but does not describe the application scenarios and implementation principles of all-zero MAC. The purpose of this draft is to describe the default MAC capability negotiation, default MAC routing sending and receiving, default MAC application scenario, default MAC mobility and so on completely based on all-zero MAC. 1.4. Terminology 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 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. "LOCAL PE": The local PE refers to the CSG PE. The local PE needs to be configured with the default MAC route receiving enable. "REMOTE PE": The remote PE refers to th RSG PE. The remote PE needs to be configured with the default MAC route sending enable. "default mac": Similar to the default route, it is used to guide the forwarding behavior when the unicast traffic misses the detailed MAC entry. 2. Solution Overview The program includes the following points: 1) The default MAC advertisement is not the default behavior of the device. You need to manually configure the default MAC route sending enable (for the route sender) and the receive enable (for the route receiver). The EVPN neighbors use the MAC route to implement the default MAC capability negotiation. 2) default mac routing sending and receiving needs to be supported. Unicast traffic additionally matches the default mac in case of detailed MAC mismatching. 3) After the default MAC capability negotiation is successful, AC interworking (including the same PE and cross-PE) needs to be supported. Liu & Wang Expires January 9, 2020 [Page 4] Internet-Draft EVPN DEFAULT MAC July 2019 3. Default MAC Capability negotiation Although the default MAC belongs to the device global capability, considering the simplicity of the protocol extension, the MAC-IP route carries the Layer 2 Attributes extended community to support the default mac negotiation between the route sender and receiver. The extention of the "Reserved" field is needed. The Layer 2 Attributes extended community defined here is defined as follows: +-------------------------------------------+ | Type (0x06) / Sub-type (0x04) (2 octets) | +-------------------------------------------+ | Control Flags (2 octets) | +-------------------------------------------+ | L2 MTU (2 octets) | +-------------------------------------------+ | Reserved (2 octets) | +-------------------------------------------+ Figure 1: EVPN Layer 2 Attributes Extended Community 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. The extention of the "Reserved" field The first bit in the "Reserved" field is used to indicate whether the default MAC route is enabled on the route sender. Name Meaning -------------------------------------------------- ------------- D If set to 1, this flag indicates that default mac advertising capabilicy is enabled by the advertising PE. If the default mac advertising capability is not enabled, then the bit must be set to 0. For the receiving end PE, it is necessary to determine whether to allow crossover based on the default MAC route receiving enable configuration. If only the D bit is set and the receiving end PE default MAC route receiving is enabled, the received route can finally crossed successfully. From the perspective of route Liu & Wang Expires January 9, 2020 [Page 5] Internet-Draft EVPN DEFAULT MAC July 2019 optimization, if the default MAC route sending enable is not configured on the sender, the default MAC route may not be sent. 4. Default MAC Actions 4.1. Mac Route Extension Based on the D bit in the Layer 2 attributes extended community defined in Section 3, the default MAC route is released by the special 0 mac and Layer 2 attributes extended community. The extended MAC routing format is as follows: +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ |Ethernet Segment Identifier (10 octets)| +---------------------------------------+ | Ethernet Tag ID (4 octets) | +---------------------------------------+ | MAC Address Length (=48) | +---------------------------------------+ | MAC Address (=0) | +---------------------------------------+ | IP Address Length (1 octet) | +---------------------------------------+ | IP Address (0, 4, or 16 octets) | +---------------------------------------+ | MPLS Label1 (3 octets) | +---------------------------------------+ | MPLS Label2 (0 or 3 octets) | +---------------------------------------+ Figure 3. Extended Mac Route Format The Ethernet Tag ID, MAC Address Length, MAC Address, IP Address Length, and IP Address fields are still considered to be part of the prefix in the NLRI. At the same time, the MAC address field must be filled in all zero. 4.2. Default MAC Flow Transmission For the data traffic from the network side to the access side, the BUM traffic still goes through the broadcast process, and unicast traffic preferentially matches the detailed MAC, and the broadcast process goes on for mismatching. For data traffic from the access side to the network side, broadcast and multicast traffic still go through the broadcast process. The priority control of unicast traffic is as follows: Liu & Wang Expires January 9, 2020 [Page 6] Internet-Draft EVPN DEFAULT MAC July 2019 1) Query the detailed MAC entry, if it matches, the traffic is forwarded according to the detailed MAC entry, otherwise go to 2); 2) Query the default MAC entry, if it matches, forward the traffic according to the default MAC entry, otherwise go to 3); 3) Neither hit the detailed MAC entry nor hit the default MAC entry, indicating that the device does not enable the MAC route receiving capability and is unknown to unicast, and can only go through the broadcast process. 5. Application Senario 5.1. Remote Interaction The remote-side interaction refers to the interworking between the users of different PEs. For the unicast traffic from the local PE to the remote PE, the local PE hits the default MAC address and goes to the remote PE. The unicast traffic of the local PE takes precedence over the detailed MAC address. If the detailed MAC is missed, the broadcast is performed. For the case where the local PE is dual-homed to two remote PEs, there exists two senarios: 1) In the dual-active scenario, the 0 MAC routes or the 0 MAC route/ EVI-AD routes sent by the remote PE1 and the remote PE2 form a load- sharing relationship on the local PE. 2) For the single-live scenario, the 0 MAC routes or the 0 MAC route/ EVI-AD routes sent by the remote PE1 and the remote PE2 form a master/slave relationship on the local PE. Based on the implementation of 1) and 2), the local PE can be instructed to go to the remote PE for unicast traffic with ms-level fault fast switch. For the case where the remote PE is dual-homed to two local PEs, the existing dual-homing technology is completely inherited, and no additional scenario expansion is required. For ARP/ND pickup, the local ARP/ND learning extension is required to generate a 0 MAC ARP/ND pickup entry. After the remote PE receives the ARP/ND route, the extension supports the generation of a 0 MAC ARP/ND pickup entry. For the E-Tree function, the flag corresponding to the Root and Leaf roles is carried in the MAC route as the E-Tree extended community Liu & Wang Expires January 9, 2020 [Page 7] Internet-Draft EVPN DEFAULT MAC July 2019 attribute content, and the default MAC route advertisement and reception processing is not additionally processed. 5.2. Local Interaction Local interaction refers to the interworking of user traffic on the same PE. To prevent local traffic from hitting the default MAC address, set the MAC aging time to be greater than the ARP aging time on the local PE. For example, the default ARP aging time is 20 minutes, then the MAC aging time can be configured to 30 minutes. As a result, MAC address entries for local interworking are always present. You do not need to consider the impact of matching the default MAC address. When the MAC address aging time is less than 20 minutes, once the destination MAC address is aged out, the local PE will match the default MAC address. The solution may be: The access side is flooded, and the default MAC address is taken on the network side. Therefore, once the destination user goes online, the flooding on the access side will disappear. However, the MAC address of the remote interworking will continue to flood, and the impact on the network may only be reduced by configuring BUM suppression. 6. Security Considerations By default, the MAC route is an abnormal route. The route receiving router may not support the forwarding process based on the default MAC route. Forcibly receiving the 0 MAC route may cause the forwarding exception. Therefore, if the MAC route receiving capacity is not configured, 0 MAC routes must be discarded. 7. Acknowledgements The author of this document would like to thank Yuan Gao, Yang Huang, Tong Zhu for their comments and review of this document. 8. Contributors The following individuals gave significant contributions to this document: Haibo Wang Huawei Technologies rainsword.wang@huawei.com Liu & Wang Expires January 9, 2020 [Page 8] Internet-Draft EVPN DEFAULT MAC July 2019 9. 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, . Authors' Addresses GuoLiang Huawei Technologies 101 software Avenue, Yuhua District Nanjing 210012 China Email: liuguoliang@huawei.com Haibo Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 10095 China Email: rainsword.wang@huawei.com Liu & Wang Expires January 9, 2020 [Page 9]