Network Working Group G. Liu Internet-Draft H. Wang Intended status: Standards Track Huawei Technologies Expires: April 30, 2020 October 28, 2019 EVPN ALL-ACTIVE ANYCAST DETECTION draft-glendon-bess-evpn-all-active-detection-00 Abstract A principal feature of EVPN is the ability to support universal detection including ping/trace, twamp, 2544, 1564 and so on. This draft specifies a mechanism of valid universal detection in all- active anycast scenes based on connectivity negotiations to avoid detection interruption due to the inconsistency between the request packet path and the response packet path. 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 April 30, 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 Liu & Wang Expires April 30, 2020 [Page 1] Internet-Draft EVPN ALL-ACTIVE ANYCAST DETECTION October 2019 (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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Situation Anyalisis . . . . . . . . . . . . . . . . . . . 3 1.2. Alternative Solutions . . . . . . . . . . . . . . . . . . 3 1.3. Design Requirement . . . . . . . . . . . . . . . . . . . 3 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Conectivity negotiation . . . . . . . . . . . . . . . . . . . 4 4. Detection Protocol Extension . . . . . . . . . . . . . . . . 5 4.1. Ping Packets Extension . . . . . . . . . . . . . . . . . 6 4.2. 2544 packets extension . . . . . . . . . . . . . . . . . 6 5. Application Senario . . . . . . . . . . . . . . . . . . . . . 7 5.1. EVPN over VXLAN . . . . . . . . . . . . . . . . . . . . . 7 5.2. EVPN over SRV6 . . . . . . . . . . . . . . . . . . . . . 7 5.3. Limitations . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction A principal feature of EVPN is the ability to support universal detection including ping/trace, twamp, 2544, 1564 and so on. Universal detection may occur in single-active scenes or in all- active scenes. The all-active scene is proposed in EVPN [RFC7432] . The draft draft-eastlake-bess-enhance-evpn-all-active specifies an improvement to load balancing all-active links. But these two documents do not mention the detection method of the all-active anycast scenes. This draft proposes a mechanism of valid universal detection in all-active anycast scenes based on connectivity negotiations to avoid detection interruption due to the inconsistency between the request packet path and the response packet path. Liu & Wang Expires April 30, 2020 [Page 2] Internet-Draft EVPN ALL-ACTIVE ANYCAST DETECTION October 2019 1.1. Situation Anyalisis Based on [RFC7432] and the draft draft-eastlake-bess-enhance-evpn- all-active, after the request packet is sent from one of the local PEs that are multi-homed by the CE, the remote PE converts the request packet into a response packet. In the case of the anycast route is reachable in anycast VXLAN tunnel or anycast SRV6 tunnel, the response message is sent to any PE that is multi-homed by the CE. If the PE that receives the response packet overlaps with the PE that sends the request packet, the detection is completed normally and the result is valid. If not, the detection process will be interrupted and the result is invalid. 1.2. Alternative Solutions A possible solution is to use the detection packet as a special data packet to unconditionally copy the packet to all reachable paths. The response packet finally arrives at the initiator of the detection packet, and the detection will still succeed, but the drawbacks of this implementation are also obvious: 1) A large number of redundant protocol packets may occur in a short period of time on the EVPN network. If a packet attack is detected, the effective bandwidth may be heavily occupied. 2) The response packet requires unconditional replication, which may result in a loop between the multi-homed access PE and the remote PE, resulting in continuous degradation of network quality. 1.3. Design Requirement The connectivity negotiation occurs between the dual-homed PEs. After the negotiation is successful, the detection packet that is extended and carries the multi-homing source address information specifies the endpoint of the detection response packet. The response packet is accurately passed back to the detection initiation PE node. 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. "CE": Customer edge device. It is used to connect a user and a PE device. Liu & Wang Expires April 30, 2020 [Page 3] Internet-Draft EVPN ALL-ACTIVE ANYCAST DETECTION October 2019 "PE": Provider edge device. It is a unique access point for users to access the carrier network. "the local PE": The detection packet initiator and endpoint. The local PEs may be single-homed or multi-homed by the CE. "the remote PE": The detection packet reflector used to converting the request packet to the response packet. 2. Solution Overview The draft includes the following technical points: 1) Detection packets sending and receiving are not the default behavior of the device. It is needed to manually configure the connectivity negotiation enable switch for the route sender and the route receiver. The EVPN neighbours use the inclusive route or the prefix route to implement connectivity negotiation. 2) Detection request packets needs to be extended to include the bypass source ip address based on the bypass channel between one multi-homed PE and the other multi-homed PE, then any multi-homed PE will know the endpoint of the detection response packets. 3) The application scenarios include EVPN over vxlan and EVPN over SRV6. VXLAN includes VXLAN4 and VXLAN6. 3. Conectivity negotiation Although Connectivity negotiation belongs to the device-level global capability, considering the simplicity of the protocol extension, the connectivity negotiation enable switch may be configured based on EVPN instances. To reduce the number of connectivity negotiation packets, the Layer 3 VXLAN or SRV6 scenario connectivity negotiation function is implemented based on the EVPN prefix route by adding all- active extended community attribute with the IP address equal to 0, the Layer 2 VXLAN or SRV6 scenario connectivity negotiation function is implemented based on the EVPN inclusive route by adding all-active extended community attribute. The C bit of the first "Reserved" field is in correspondence with the negotiation switch. The all- active extended community defined here is defined as follows: Liu & Wang Expires April 30, 2020 [Page 4] Internet-Draft EVPN ALL-ACTIVE ANYCAST DETECTION October 2019 +-------------------------------------------+ | Type (0x06) / Sub-type (2 octets) | +-------------------------------------------+ | Reserved (2 octets) | +-------------------------------------------+ | Reserved (2 octets) | +-------------------------------------------+ | Reserved (2 octets) | +-------------------------------------------+ Figure 1: All-Active Extended Community 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |C| | +-+-+-+-+-+-+-+-+ Figure 2. The C bit of the first "Reserved" field The first bit in the "Reserved" field is marked as C bit and is used to indicate whether the detection negotiation is enabled on the route sender. If C bit is set to 1, this flag indicates the connectivity negotiation is enabled by the advertising PE. If the connectivity negotiation is not enabled, then the C bit must be set to 0. For the receiving all-active PE, it is necessary to determine whether to allow crossover based on the detection negotiation enable configuration. If only the C bit is set and the detection negotiation is enabled, the received route can finally crossed successfully. From the perspective of route optimization, if the connectivity negotiation is not enabled on the sender, the connectivity negotiation route may not be sent. 4. Detection Protocol Extension There are various detection protocols. In this chapter, ping packets and 2544 packets are used as examples to describe the extension of the detection packets for EVPN all-active scenes. Liu & Wang Expires April 30, 2020 [Page 5] Internet-Draft EVPN ALL-ACTIVE ANYCAST DETECTION October 2019 4.1. Ping Packets Extension In order to support ping connectivity detection based on EVPN instances, ping packets need to be extended shown as figure 3. 0 7|8 15|16 31| +-------------------------------------------------------+ | Type(0 or 8)| Code(0) | CheckSum | +-------------------------------------------------------+ | Identifier | Sequence | +-------------------------------------------------------+ | bypass ipv4/ipv6 address | +-------------------------------------------------------+ | bypass ipv6 address | +-------------------------------------------------------+ | bypass ipv6 address | +-------------------------------------------------------+ | bypass ipv6 address | +-------------------------------------------------------+ | other option data | +-------------------------------------------------------+ Figure 3. Extended Ping Packets Format The first 4 bytes or 16 bytes of the ICMP header optional data can be used as the source IP address of the multi-homed PE bypass tunnel. 4.2. 2544 packets extension In order to support 2544 detection based on EVPN instances, 2544 packets need to be extended shown as figure 4. +-----------------------------------------------------------------------------------+-------------------+ | ETH(VLAN) | | | | (reserved) | TX_Timestamp | RX_Timestamp | Bypass Source | | PPP | IPV4 | UDP | OPCODE |------------------------------------------| IP Address | | HDLC | | | | PAYLOAD | | |-----------------------------------------------------------------------------------| 4 or 16 bytes | | 14(+4+4) | 20Byte | 8Byte | 1Byte | 3Byte | 8Byte | 8Byte | | | 4Byte | | | | | | | | | 4Byte | | | | | | | | |------------------------------------------------------ 64Byte ---------------------| | |---------------------------2544 testing attributes---------------------------------|-------------------| Figure 4. Extended 2544 Packets Format The first 4 bytes or 16 bytes immediately following the measuring attributes can be used as the source IP address of the multi-homed PE bypass tunnel. Liu & Wang Expires April 30, 2020 [Page 6] Internet-Draft EVPN ALL-ACTIVE ANYCAST DETECTION October 2019 5. Application Senario 5.1. EVPN over VXLAN CE is multi-homed to local PE1/PE2 and PE3 is the remote device. Firstly, On the initial PE1 device, PE1 sends a detection request packet carrying the bypass vxlan source IPV4 address(vxlan4 for IPV4 address, vxlan6 for IPV6 address) to PE3. Secondly, PE3 terminates the detection request packet, sends a detection response packet which copies the source bypass vxlan IP address in the request packet. If PE1 receives the response packet, Only when the PE1/PE2 connectivity negotiation succeeds, PE1 compares the source IP address of the bypass vxlan tunnel between PE1 and PE2 with the new IP address carried in the response packet. Because the result is that the two IP addresses are exactly equal, the response packet is sent to the CPU for processing and the final detection is successful. If PE2 receives the response packet, PE2 also compares the source IP address of the bypass vxlan tunnel between the PE1 and the PE2 with the newly carried IP address in the response packet. Although the result is that the two IP addresses are not equal, fortunately, the bypass VXLAN tunnel between PE1 and PE2 is reachable, PE2 sends the response packet to PE1 since PE1 is the endpoint of the detection response packet indicated by the new IP address carried in the response packet. After the response packet is delivered to PE1, PE1 compares the source IP address of the bypass vxlan tunnel between PE1 and PE2 with the IP address carried in the response packet. What's exciting is that PE1 is a Terminator. The response packet is sent to the CPU for processing and the final detection is successful. 5.2. EVPN over SRV6 The universal detection process of EVPN over SRV6 is very similar to EVPN over vxlan. The difference is that the length of new IP address extended in the response packet must be 16 bytes in the SRV6 scene while the length of new IP address may be 4 bytes or 16 bytes. In addition, the tunnel between the multi-homed PEs is no longer a vxlan tunnel but an SRV6 BE or SRV6 Policy tunnel. 5.3. Limitations The examples and principles of this draft are focused on the dual- homing scenario. For multi-homing scenarios, vxlan tunnels or srv6 tunnels are established between every two PEs among all-active PEs. Liu & Wang Expires April 30, 2020 [Page 7] Internet-Draft EVPN ALL-ACTIVE ANYCAST DETECTION October 2019 Of course, connectivity negotiation must also occur between every two PEs. 6. Security Considerations For general EVPN Security Considerations, see [RFC7432]. 7. IANA Considerations This document does not require new codepoints. 8. Contributors The following individuals gave significant contributions to this document: Haibo Wang Huawei Technologies rainsword.wang@huawei.com 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 April 30, 2020 [Page 8]