idnits 2.17.1 draft-wang-bess-evpn-frr-label-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 12, 2021) is 1018 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group H. Wang 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track D. Eastlake 5 Expires: January 13, 2022 Futurewei Technologies 6 T. Zhu 7 Huawei Technologies 8 July 12, 2021 10 EVPN ELAN FRR Loop Prevent label 11 draft-wang-bess-evpn-frr-label-01 13 Abstract 15 This document describes how to use Fast Re-Route (FRR) labels avoid 16 traffic loop in CE failures when deploying FRR protection in EVPN 17 scenarios. 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 RFC 2119 [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 2. FRR Label Extended Community . . . . . . . . . . . . . . . . 3 61 3. The Control Plane Process . . . . . . . . . . . . . . . . . . 4 62 4. The Data Plane Process . . . . . . . . . . . . . . . . . . . 4 63 5. Other considerations . . . . . . . . . . . . . . . . . . . . 5 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 67 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 In the EVPN active-active scenario, to solve the failure of a CE 73 access channel to one PE, we can deploy Fast Re-Route (FRR) 74 protection mode to achieve fast convergence. All active PEs can be 75 deployed with FRR. When a link failure occurs on the CE connection 76 to the PE, traffic can be rapidly FRR to another PE to improve the 77 switching performance. However, if the CE device fails, both the two 78 PEs sense that their CE link is faulty at the same time. They will 79 each perform fast switching according to the FRR. Then the traffic 80 will loop between the dual PEs. 82 If one PE detects a failure and withdraw the ES-AD route, the other 83 PE, after receiving the withdrawal of the ES-AD route, deletes the 84 FRR path to the PE, and the loop is eliminated. The time until the 85 loop is eliminated may be short, but during this time, the loop will 86 cause traffic congestion between the dual-homing PEs. 88 +-----+ 89 | CE2 | 90 +-----+ 91 | 92 +-----+ 93 | EVI1| 94 | PE3 | 95 +-----+ 96 / \ 97 / \ 98 / \ 99 / \ 100 / \ 101 +-----+ +-----+ 102 | PE1 | | PE2 | 103 | EVI1|-------------| EVI1| 104 +-----+ +-----+ 105 \ / 106 \ / 107 ESI1 ESI1 108 \ Trunk / 109 +\-----/+ 110 | \ / | 111 +---+---+ 112 | 113 +-----+ 114 | CE1 | 115 +-----+ 116 Figure 1: Basic networking of the EVPN all-active scenario 118 2. FRR Label Extended Community 120 The FRR Label Extended Community is a new transitive Extended 121 Community having a Type field value of 0x06 and the Sub-Type TBD. It 122 may be advertised along with MAC/IP Advertisement routes and Ethernet 123 A-D per EVI routes. 125 The FRR Label Extended Community is encoded as an 8-octet value, as 126 follows: 128 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Type=0x06 | Sub-Type=TBD | Flags(1 octet)| Reserved=0 | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Reserved=0 | FRR Label | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 3. The Control Plane Process 137 If we enable the FRR LABEL function for an instance, then when the PE 138 advertises the MAC-IP route or Ethernet A-D per EVI route of the 139 instance, it also carries an FRR Label Extended Community attribute. 141 When another PE on the dual-homed side receives the MAC-IP route or 142 the EVI-AD route, and uses the Label in the FRR Label Extended 143 Community attribute as the label for the Edge FRR path. The single- 144 homing-side PE receives the MAC-IP route or Ethernet A-D per EVI 145 route advertised by the PE will ignores the FRR Label Extended 146 Community attribute. 148 Because the FRR Label Extended Community attribute is an optional 149 transitve attribute, if there are RR devices or ASBR devices in the 150 network, the attributes can be transparently transmitted and 151 processed by the final PE device. 153 Taking Figure 1 as an example, the EVI1 of PE2 enables the FRR LABEL 154 function, and PE2 applies for a new label. PE2 advertises the MAC-IP 155 route and the Ethernet A-D per EVI route carries the label through 156 the FRR Label Extended Community attribute. Because CE1 is dual- 157 homed to PE1 and PE2, PE1 learns the MAC address of CE1 from the data 158 plane. Therefore, when PE1 receives the MAC-IP route or Ethernet A-D 159 per EVI route from PE2, it can generate the MAC address learned from 160 CE1 to form an edge FRR entry and the label filled in the FRR entry 161 is the FRR label. 163 For PE3, even if CE1 is dual-homed to PE1 and PE2 in single-active 164 mode, PE3 form FRR does not use the FRR label. 166 The feature is available for EVPN ELAN service , EVPN VPWS and EVPN 167 L3VPN service. 169 4. The Data Plane Process 171 The PE receives the traffic from the network side and finds the 172 corresponding bridge-domain according to the Label. If the Label is 173 a normal EVI label, the MAC address is normally queried. If the 174 local outbound interface of the MAC fails, the FRR of the MAC is 175 further protected. If the Label is an FRR label, the MAC address 176 continues to be queried normally. If the local outbound interface of 177 the MAC fails, the FRR of the MAC is no longer protected. 179 Taking Figure 1 as an example. CE2 send traffic to CE1, traffic 180 arrived PE3 will encapsulate PE2 's EVI label and send to PE1. 181 Traffic arrived at PE1 and use the EVI label to lookup MAC table, but 182 find the out-interface is failed. PE1 will do MAC FRR for that and 183 encapsulate the FRR label, which is advertised by PE2. Traffic 184 arrived at PE2 and use the FRR label to lookup MAC table. The 185 traffic will send to CE1 according to the MAC infomation. When the 186 MAC's out-interface is failed, the traffic will dropped to avoid 187 traffic loop. 189 5. Other considerations 191 The solution of this document is not only applicable to the EVPN 192 scenario. The traditional L3VPN can also use this solution to 193 achieve rapid loop breaking. 195 6. IANA Considerations 197 IANA is requested to assign a new type of FRR label extended 198 community with value TBD. 200 7. Security Considerations 202 TBD 204 8. Acknowledgements 206 9. Normative References 208 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 209 Requirement Levels", BCP 14, RFC 2119, 210 DOI 10.17487/RFC2119, March 1997, 211 . 213 Authors' Addresses 215 Haibo Wang 216 Huawei Technologies 217 Huawei Campus, No. 156 Beiqing Road 218 Beijing 100095 219 China 221 Email: rainsword.wang@huawei.com 222 Donald E. Eastlake 223 Futurewei Technologies 224 2386 Panoramic Circle 225 Apopka FL 32703 226 USA 228 Phone: +1-508-333-2270 229 Email: d3e3e3@gmail.com 231 Tong Zhu 232 Huawei Technologies 233 101 software Avenue, Yuhua District 234 Nanjing 210012 235 China 237 Email: zhu.tong@huawei.com