idnits 2.17.1 draft-glendon-bess-evpn-all-active-detection-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 37 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 28, 2019) is 1639 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 138, but not defined == Missing Reference: 'RFC8174' is mentioned on line 138, but not defined Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Liu 3 Internet-Draft H. Wang 4 Intended status: Standards Track Huawei Technologies 5 Expires: April 30, 2020 October 28, 2019 7 EVPN ALL-ACTIVE ANYCAST DETECTION 8 draft-glendon-bess-evpn-all-active-detection-00 10 Abstract 12 A principal feature of EVPN is the ability to support universal 13 detection including ping/trace, twamp, 2544, 1564 and so on. This 14 draft specifies a mechanism of valid universal detection in all- 15 active anycast scenes based on connectivity negotiations to avoid 16 detection interruption due to the inconsistency between the request 17 packet path and the response packet path. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 30, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Situation Anyalisis . . . . . . . . . . . . . . . . . . . 3 61 1.2. Alternative Solutions . . . . . . . . . . . . . . . . . . 3 62 1.3. Design Requirement . . . . . . . . . . . . . . . . . . . 3 63 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Conectivity negotiation . . . . . . . . . . . . . . . . . . . 4 66 4. Detection Protocol Extension . . . . . . . . . . . . . . . . 5 67 4.1. Ping Packets Extension . . . . . . . . . . . . . . . . . 6 68 4.2. 2544 packets extension . . . . . . . . . . . . . . . . . 6 69 5. Application Senario . . . . . . . . . . . . . . . . . . . . . 7 70 5.1. EVPN over VXLAN . . . . . . . . . . . . . . . . . . . . . 7 71 5.2. EVPN over SRV6 . . . . . . . . . . . . . . . . . . . . . 7 72 5.3. Limitations . . . . . . . . . . . . . . . . . . . . . . . 7 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 A principal feature of EVPN is the ability to support universal 82 detection including ping/trace, twamp, 2544, 1564 and so on. 83 Universal detection may occur in single-active scenes or in all- 84 active scenes. The all-active scene is proposed in EVPN [RFC7432] . 85 The draft draft-eastlake-bess-enhance-evpn-all-active specifies an 86 improvement to load balancing all-active links. But these two 87 documents do not mention the detection method of the all-active 88 anycast scenes. This draft proposes a mechanism of valid universal 89 detection in all-active anycast scenes based on connectivity 90 negotiations to avoid detection interruption due to the inconsistency 91 between the request packet path and the response packet path. 93 1.1. Situation Anyalisis 95 Based on [RFC7432] and the draft draft-eastlake-bess-enhance-evpn- 96 all-active, after the request packet is sent from one of the local 97 PEs that are multi-homed by the CE, the remote PE converts the 98 request packet into a response packet. In the case of the anycast 99 route is reachable in anycast VXLAN tunnel or anycast SRV6 tunnel, 100 the response message is sent to any PE that is multi-homed by the CE. 101 If the PE that receives the response packet overlaps with the PE that 102 sends the request packet, the detection is completed normally and the 103 result is valid. If not, the detection process will be interrupted 104 and the result is invalid. 106 1.2. Alternative Solutions 108 A possible solution is to use the detection packet as a special data 109 packet to unconditionally copy the packet to all reachable paths. 110 The response packet finally arrives at the initiator of the detection 111 packet, and the detection will still succeed, but the drawbacks of 112 this implementation are also obvious: 114 1) A large number of redundant protocol packets may occur in a short 115 period of time on the EVPN network. If a packet attack is detected, 116 the effective bandwidth may be heavily occupied. 118 2) The response packet requires unconditional replication, which may 119 result in a loop between the multi-homed access PE and the remote PE, 120 resulting in continuous degradation of network quality. 122 1.3. Design Requirement 124 The connectivity negotiation occurs between the dual-homed PEs. 125 After the negotiation is successful, the detection packet that is 126 extended and carries the multi-homing source address information 127 specifies the endpoint of the detection response packet. The 128 response packet is accurately passed back to the detection initiation 129 PE node. 131 1.4. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in 136 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 "CE": Customer edge device. It is used to connect a user and a PE 140 device. 142 "PE": Provider edge device. It is a unique access point for users to 143 access the carrier network. 145 "the local PE": The detection packet initiator and endpoint. The 146 local PEs may be single-homed or multi-homed by the CE. 148 "the remote PE": The detection packet reflector used to converting 149 the request packet to the response packet. 151 2. Solution Overview 153 The draft includes the following technical points: 155 1) Detection packets sending and receiving are not the default 156 behavior of the device. It is needed to manually configure the 157 connectivity negotiation enable switch for the route sender and the 158 route receiver. The EVPN neighbours use the inclusive route or the 159 prefix route to implement connectivity negotiation. 161 2) Detection request packets needs to be extended to include the 162 bypass source ip address based on the bypass channel between one 163 multi-homed PE and the other multi-homed PE, then any multi-homed PE 164 will know the endpoint of the detection response packets. 166 3) The application scenarios include EVPN over vxlan and EVPN over 167 SRV6. VXLAN includes VXLAN4 and VXLAN6. 169 3. Conectivity negotiation 171 Although Connectivity negotiation belongs to the device-level global 172 capability, considering the simplicity of the protocol extension, the 173 connectivity negotiation enable switch may be configured based on 174 EVPN instances. To reduce the number of connectivity negotiation 175 packets, the Layer 3 VXLAN or SRV6 scenario connectivity negotiation 176 function is implemented based on the EVPN prefix route by adding all- 177 active extended community attribute with the IP address equal to 0, 178 the Layer 2 VXLAN or SRV6 scenario connectivity negotiation function 179 is implemented based on the EVPN inclusive route by adding all-active 180 extended community attribute. The C bit of the first "Reserved" 181 field is in correspondence with the negotiation switch. The all- 182 active extended community defined here is defined as follows: 184 +-------------------------------------------+ 185 | Type (0x06) / Sub-type (2 octets) | 186 +-------------------------------------------+ 187 | Reserved (2 octets) | 188 +-------------------------------------------+ 189 | Reserved (2 octets) | 190 +-------------------------------------------+ 191 | Reserved (2 octets) | 192 +-------------------------------------------+ 194 Figure 1: All-Active Extended Community 196 0 1 2 3 4 5 6 7 197 +-+-+-+-+-+-+-+-+ 198 |C| | 199 +-+-+-+-+-+-+-+-+ 201 Figure 2. The C bit of the first "Reserved" field 203 The first bit in the "Reserved" field is marked as C bit and is used 204 to indicate whether the detection negotiation is enabled on the route 205 sender. 207 If C bit is set to 1, this flag indicates the connectivity 208 negotiation is enabled by the advertising PE. 210 If the connectivity negotiation is not enabled, then the C bit must 211 be set to 0. 213 For the receiving all-active PE, it is necessary to determine whether 214 to allow crossover based on the detection negotiation enable 215 configuration. If only the C bit is set and the detection 216 negotiation is enabled, the received route can finally crossed 217 successfully. From the perspective of route optimization, if the 218 connectivity negotiation is not enabled on the sender, the 219 connectivity negotiation route may not be sent. 221 4. Detection Protocol Extension 223 There are various detection protocols. In this chapter, ping packets 224 and 2544 packets are used as examples to describe the extension of 225 the detection packets for EVPN all-active scenes. 227 4.1. Ping Packets Extension 229 In order to support ping connectivity detection based on EVPN 230 instances, ping packets need to be extended shown as figure 3. 232 0 7|8 15|16 31| 233 +-------------------------------------------------------+ 234 | Type(0 or 8)| Code(0) | CheckSum | 235 +-------------------------------------------------------+ 236 | Identifier | Sequence | 237 +-------------------------------------------------------+ 238 | bypass ipv4/ipv6 address | 239 +-------------------------------------------------------+ 240 | bypass ipv6 address | 241 +-------------------------------------------------------+ 242 | bypass ipv6 address | 243 +-------------------------------------------------------+ 244 | bypass ipv6 address | 245 +-------------------------------------------------------+ 246 | other option data | 247 +-------------------------------------------------------+ 248 Figure 3. Extended Ping Packets Format 250 The first 4 bytes or 16 bytes of the ICMP header optional data can be 251 used as the source IP address of the multi-homed PE bypass tunnel. 253 4.2. 2544 packets extension 255 In order to support 2544 detection based on EVPN instances, 2544 256 packets need to be extended shown as figure 4. 258 +-----------------------------------------------------------------------------------+-------------------+ 259 | ETH(VLAN) | | | | (reserved) | TX_Timestamp | RX_Timestamp | Bypass Source | 260 | PPP | IPV4 | UDP | OPCODE |------------------------------------------| IP Address | 261 | HDLC | | | | PAYLOAD | | 262 |-----------------------------------------------------------------------------------| 4 or 16 bytes | 263 | 14(+4+4) | 20Byte | 8Byte | 1Byte | 3Byte | 8Byte | 8Byte | | 264 | 4Byte | | | | | | | | 265 | 4Byte | | | | | | | | 266 |------------------------------------------------------ 64Byte ---------------------| | 267 |---------------------------2544 testing attributes---------------------------------|-------------------| 268 Figure 4. Extended 2544 Packets Format 270 The first 4 bytes or 16 bytes immediately following the measuring 271 attributes can be used as the source IP address of the multi-homed PE 272 bypass tunnel. 274 5. Application Senario 276 5.1. EVPN over VXLAN 278 CE is multi-homed to local PE1/PE2 and PE3 is the remote device. 280 Firstly, On the initial PE1 device, PE1 sends a detection request 281 packet carrying the bypass vxlan source IPV4 address(vxlan4 for IPV4 282 address, vxlan6 for IPV6 address) to PE3. 284 Secondly, PE3 terminates the detection request packet, sends a 285 detection response packet which copies the source bypass vxlan IP 286 address in the request packet. 288 If PE1 receives the response packet, Only when the PE1/PE2 289 connectivity negotiation succeeds, PE1 compares the source IP address 290 of the bypass vxlan tunnel between PE1 and PE2 with the new IP 291 address carried in the response packet. Because the result is that 292 the two IP addresses are exactly equal, the response packet is sent 293 to the CPU for processing and the final detection is successful. 295 If PE2 receives the response packet, PE2 also compares the source IP 296 address of the bypass vxlan tunnel between the PE1 and the PE2 with 297 the newly carried IP address in the response packet. Although the 298 result is that the two IP addresses are not equal, fortunately, the 299 bypass VXLAN tunnel between PE1 and PE2 is reachable, PE2 sends the 300 response packet to PE1 since PE1 is the endpoint of the detection 301 response packet indicated by the new IP address carried in the 302 response packet. After the response packet is delivered to PE1, PE1 303 compares the source IP address of the bypass vxlan tunnel between PE1 304 and PE2 with the IP address carried in the response packet. What's 305 exciting is that PE1 is a Terminator. The response packet is sent to 306 the CPU for processing and the final detection is successful. 308 5.2. EVPN over SRV6 310 The universal detection process of EVPN over SRV6 is very similar to 311 EVPN over vxlan. The difference is that the length of new IP address 312 extended in the response packet must be 16 bytes in the SRV6 scene 313 while the length of new IP address may be 4 bytes or 16 bytes. In 314 addition, the tunnel between the multi-homed PEs is no longer a vxlan 315 tunnel but an SRV6 BE or SRV6 Policy tunnel. 317 5.3. Limitations 319 The examples and principles of this draft are focused on the dual- 320 homing scenario. For multi-homing scenarios, vxlan tunnels or srv6 321 tunnels are established between every two PEs among all-active PEs. 323 Of course, connectivity negotiation must also occur between every two 324 PEs. 326 6. Security Considerations 328 For general EVPN Security Considerations, see [RFC7432]. 330 7. IANA Considerations 332 This document does not require new codepoints. 334 8. Contributors 336 The following individuals gave significant contributions to this 337 document: 339 Haibo Wang 341 Huawei Technologies 343 rainsword.wang@huawei.com 345 9. References 347 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 348 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 349 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 350 2015, . 352 Authors' Addresses 354 GuoLiang 355 Huawei Technologies 356 101 software Avenue, Yuhua District 357 Nanjing 210012 358 China 360 Email: liuguoliang@huawei.com 362 Haibo 363 Huawei Technologies 364 Huawei Bld., No.156 Beiqing Rd. 365 Beijing 10095 366 China 368 Email: rainsword.wang@huawei.com