idnits 2.17.1 draft-glendon-bess-evpn-trusted-mac-02.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. 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 date (July 12, 2021) is 1011 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) == Unused Reference: 'I-D.snr-bess-evpn-loop-protect' is defined on line 347, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-snr-bess-evpn-loop-protect (ref. 'I-D.snr-bess-evpn-loop-protect') Summary: 2 errors (**), 0 flaws (~~), 3 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 T. Zhu 5 Expires: January 13, 2022 Huawei Technologies 6 July 12, 2021 8 EVPN LOOP PREVENTION BASED ON TRUSTED MAC 9 draft-glendon-bess-evpn-trusted-mac-02 11 Abstract 13 A principal feature of EVPN is the ability to support MAC duplication 14 detection based on MAC Mobility Extended Community. This draft 15 specifies a mechanism of valid loop prevention based on trusted MAC 16 to avoid servce interruption of the specifed source or destination 17 MAC address due to "black-holing". 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 January 13, 2022. 42 Copyright Notice 44 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . 2 61 1.2. Alternative Solutions . . . . . . . . . . . . . . . . . . 3 62 1.3. Design Requirement . . . . . . . . . . . . . . . . . . . 3 63 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Trusted MAC Capability negotiation . . . . . . . . . . . . . 4 66 4. Trusted MAC Actions . . . . . . . . . . . . . . . . . . . . . 5 67 4.1. Flag Extension . . . . . . . . . . . . . . . . . . . . . 5 68 4.2. Trusted MAC Generation and Delivery . . . . . . . . . . . 6 69 5. Application Senario . . . . . . . . . . . . . . . . . . . . . 6 70 5.1. Trusted MAC and Sticky MAC . . . . . . . . . . . . . . . 6 71 5.2. Trusted MAC and Dynamic MAC . . . . . . . . . . . . . . . 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 MAC duplication 82 dection based on MAC Mobility extended Community. The MAC 83 duplication detection is proposed in EVPN [RFC7432]. The draft 84 [draft-snr-bess-evpn-loop-protect] re-uses and enhances the MAC 85 duplication solution specified in EVPN [RFC7432]. This draft is a 86 further enhancement for [RFC7432] and [draft-snr-bess-evpn-loop- 87 protect]. Trusted MAC is proposed to avoid servce interruption of 88 the specifed source or destination MAC address due to "black-holing". 90 1.1. Situation Anyalisis 92 Based on [RFC7432], when the MAC duplication threshold is met(MAC 93 moving for 5 times in 180 minutes in default), the PE MUST alert the 94 operator and stop sending and processing any MAC/IP advertisement 95 routes for that MAC address, but the other PEs in the EVI will 96 forward the traffic for the duplicated MAC address to one of the PEs 97 that have advertised it. In order to prevent loop and not just 98 detect loop, it is necessary to introduce a new mechanism, [draft- 99 snr-bess-evpn-loop-protect] proposes the idea of "black-holing". 100 "Black-holing" is a good means of service isolation, however, the 101 user's real intention is that the system has the ability to recognize 102 the real AC port or peer neighbour of the MAC after detecting MAC 103 duplication successfully. 105 1.2. Alternative Solutions 107 Sticky MAC address is proposed in section 15.2 [RFC7432]. There are 108 scenarios in which it is desired to configure static MAC addresses so 109 that they are not subjected to MAC moves. In such scenarios, these 110 MAC addresses are advertised with the MAC mobility extended community 111 where the flags field is set to 1 and the sequence number is set to 112 zero. Static MAC can be used to prevent loop without service 113 interruption, but the following problems come: 115 1) In most scenarios, the user MAC is unpredictable, and it is 116 impossible to predict the AC port or the peer neighbour for the user 117 accessing to the specific PE. 119 2) Even if we can predict on the AC port or the peer neighbor that 120 the user accesses, what should I do if the static MAC that is learned 121 locally and the sticky MAC route that is received from the peer 122 neighbour coexist at the same time? Customers are hard to 123 understand, regardless of whether to choose local MAC or remote MAC. 125 1.3. Design Requirement 127 This draft proposes a new method to prevent loop based on trusted 128 MAC. The generation of trusted MAC belongs to the local behavior of 129 the PE. After the generation of trusted MAC, it is delivered to the 130 EVPN neighbour through the EVPN route, and the MAC duplication 131 detection mechanism based on the MAC mobility extended community is 132 extended to finally generate a truly reliable MAC outbound interface 133 or EVPN neighbour. Loop prevention comes true finally. 135 1.4. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in 140 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 "PE": Provider edge device. It is a unique access point for users to 144 access the carrier network. 146 "AC": A physical or logical link. It is used to connect a user edge 147 device and a PE device. 149 "trusted MAC": The MAC entry to the AC port or EVPN neighbour. It is 150 generated based on the user's trusted traffic. 152 2. Solution Overview 154 The draft includes the following technical points: 156 1) Trusted MAC sending and receiving is not the default behavior of 157 the device. It is needed to manually configure the trusted MAC route 158 sending enable (for the route sender) and the receiving enable (for 159 the route receiver). The EVPN neighbours use the MAC route to 160 implement trusted MAC capability negotiation. 162 2) Trusted MAC needs to be generated based on certain rules, then MAC 163 mobility extended community is extended to add T bit for supporting 164 trusted MAC delivery. 166 3) After trusted MAC negotiation and delivery, the MAC duplication 167 detection mechanism between trusted MAC and static MAC needs to be 168 supported. MAC duplication between trusted MAC and dynamic MAC is 169 also a consideration. 171 3. Trusted MAC Capability negotiation 173 Although trusted MAC belongs to the device-level global capability, 174 considering the simplicity of the protocol extension, the UMR 175 (Unknown MAC Route, [RFC7543]) carries the MAC mobility extended 176 community to support trusted MAC negotiation between the route sender 177 and the receiver. The extension of the "Flags" field is needed. The 178 MAC mobility extended community defined here is defined as follows: 180 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Type=0x06 | Sub-Type=0x00 |Flags(1 octet) | Reserved=0 | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Sequence Number | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Figure 1: MAC Mobility Extended Community 188 0 1 2 3 4 5 6 7 189 +-+-+-+-+-+-+-+-+ 190 | |T|S| 191 +-+-+-+-+-+-+-+-+ 193 Figure 2. The extension of the "Flags" field 195 The bit 6 in the "Flags" field is marked as T bit and is used to 196 indicate whether the trusted MAC route is enabled on the route 197 sender. 199 Name Meaning 201 -------------------------------------------------- ------------- 203 T If set to 1, this flag indicates that trusted MAC advertising 204 capabilicy is enabled by the advertising PE. 206 If the trusted MAC advertising capability is not enabled, then the T 207 bit must be set to 0. 209 For the receiving PE, it is necessary to determine whether to allow 210 crossover based on the trusted MAC receiving enable configuration. 211 If only the T bit is set and the trusted MAC route receiving for the 212 receiving PE is enabled, the received route can finally crossed 213 successfully. From the perspective of route optimization, if the 214 trusted MAC route sending enable is not configured on the sender, the 215 trusted MAC negotiation route may not be sent. 217 4. Trusted MAC Actions 219 4.1. Flag Extension 221 In order to distinguish between dynamic MAC, static MAC and trusted 222 MAC, the flags field in MAC mobility extended community shown as 223 section 3 figure 1 needs to extend new value. 225 Name Meaning 227 -------------------------------------------------- ------------- 229 If Flag T-bit is set to 1 and S-bit is set to 1, it indicates that 230 trusted sticky MAC is advertised to the remote PE. 232 If only flag T-bit is set to 1, it indicates that trusted dynamic MAC 233 is advertised to the remote PE. 235 4.2. Trusted MAC Generation and Delivery 237 The generation of trusted MAC belongs to the local behavior of the 238 PE. Generally speaking, the stable MAC out port or EVPN neighbor in 239 the specified period of the first time learned locally is defined as 240 trusted MAC. The specified period can be assigned to a default 241 value, such as 60 seconds. The value of the period may be modified 242 to other values, for example, 1 minutes, 5 minutes or else. Once the 243 local trusted MAC is generated, it will not be overwritten by the 244 other dynamic MAC, but it can be overwritten by static MAC. Since 245 trusted MAC is still in the category of dynamic MAC, trusted MAC 246 aging needs to support. 248 There exists several limitations for trusted MAC generation and 249 delivery: 251 1) In a very poor network environment, the specified MAC may have a 252 persistent mobility after the MAC entry is generated for the first 253 time. In this case, trusted MAC may not be generated. Static MAC 254 may only be used to restrict the forwarding behavior of the user's 255 traffic. 257 2) After trusted MAC is generated, if the generation cycle of the 258 trusted MAC is dynamically modified, the generated trusted MAC will 259 not be deleted automatically in order to reduce the impact on the 260 existing MAC duplication detection mechanism based on trusted MAC. 261 If only trusted MAC is manually deleted or aged, the system will 262 generate a new trusted MAC based on the modified period. 264 3) After trusted MAC is generated, if the specified MAC is 265 reconfigured as a static MAC, the MAC route carrying the MAC mobility 266 extended community with flags=1 will be re-advertised, so the result 267 of the MAC duplication detection may be changed. 269 4) After trusted MAC is generated, if the specified MAC is 270 reconfigured as a black-holing MAC, the previously advertised trusted 271 MAC route needs to be withdrew to prevent invalid network traffic 272 caused by the black-holing MAC. 274 5. Application Senario 276 5.1. Trusted MAC and Sticky MAC 278 The sticky MAC may be configured on the PE or be received from the 279 other PEs, when trusted MAC and sticky MAC coexist in the same PE, 280 There exist two sub-scenarios: 282 1) Only one sticky MAC exists beyond trusted MAC. The only sticky 283 MAC guides the user's traffic and will survive forever until sticky 284 MAC is manually deleted. 286 2) Several sticky MACs exist beyond trusted MAC. When there exists a 287 local static MAC, since the local static MAC is unique, the user's 288 traffic is preferentially guided according to the local MAC. When 289 there exists no local static MAC, the same PE may receive the same 290 sticky MAC from different EVPN neighbours. Therefore, the PE selects 291 the sticky MAC route from the neighbour with th smallest original ip 292 address to guide the final user's traffic. 294 In the above two sub-scenarios, the coexistence between trusted MAC 295 and sticky MAC triggers the MAC duplication alarm, and all trusted 296 MACs are eventually ignored. 298 5.2. Trusted MAC and Dynamic MAC 300 The coexistence of trusted MAC and dynamic MAC occurs when there is 301 no sticky MAC in the system, There exist two sub-scenarios: 303 1) Only one trusted MAC (local or remote) exists beyond dynamic MAC. 304 The only trusted MAC guides the user's traffic and will age when the 305 user's traffic based on the trusted MAC (source MAC or desination 306 MAC) disappears. 308 2) Several trust MACs exist beyond dynamic MAC. The locally learned 309 trusted MAC or the trusted MAC route received from the remote PE have 310 higher priority than the normal dynamic MAC. After detecting the MAC 311 duplication, the locally learned trust MAC or the trusted MAC route 312 with the larger serial number is used to guide the final user's 313 traffic. 315 Note: If the local PE receives the trusted MAC route with the same 316 serial number from different neighbours, the route received from the 317 neighbour with the smallest original ip is selected to participate in 318 the MAC duplication detection. 320 5.3. Limitations 322 the default MAC route received from the other PE cannot participate 323 in the MAC duplication detection. In this case, the traffic-based 324 MAC duplication detection mechanism can only be used on the access 325 side. Similarly, the priority of sticky MAC is higher than trusted 326 MAC, the priority of trusted MAC is higher than dynamic MAC. 328 6. Security Considerations 330 When multiple network elements in the same network detect the MAC 331 duplication at the same time, trusted MAC may cause the traffic 332 between the network elements to loop. The probability of this 333 situation is relatively small. Perhaps the user's traffic can only 334 be isolated by black holing in order to reduce the whole network 335 security risk. 337 7. IANA Considerations 339 NA 341 8. Contributors 343 NA 345 9. References 347 [I-D.snr-bess-evpn-loop-protect] 348 Rabadan, J., Sathappan, S., Nagaraj, K., Bueno, J., and J. 349 M. Crespo, "Loop Protection in EVPN networks", draft-snr- 350 bess-evpn-loop-protect-04 (work in progress), August 2019. 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, 354 DOI 10.17487/RFC2119, March 1997, 355 . 357 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 358 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 359 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 360 2015, . 362 [RFC7543] Jeng, H., Jalil, L., Bonica, R., Patel, K., and L. Yong, 363 "Covering Prefixes Outbound Route Filter for BGP-4", 364 RFC 7543, DOI 10.17487/RFC7543, May 2015, 365 . 367 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 368 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 369 May 2017, . 371 Authors' Addresses 372 GuoLiang Liu 373 Huawei Technologies 374 No.101 Software Avenue, Yuhuatai District 375 Nanjing 210012 376 China 378 Email: liuguoliang@huawei.com 380 Haibo Wang 381 Huawei Technologies 382 Huawei Bld., No.156 Beiqing Rd. 383 Beijing 10095 384 China 386 Email: rainsword.wang@huawei.com 388 Tong Zhu 389 Huawei Technologies 390 No.101 Software Avenue, Yuhuatai District 391 Nanjing 210012 392 China 394 Email: zhu.tong@huawei.com