idnits 2.17.1 draft-wang-bess-evpn-frr-label-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 : ---------------------------------------------------------------------------- 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 (October 22, 2018) is 2013 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- 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 D. Eastlake 4 Intended status: Experimental Huawei Technologies 5 Expires: April 25, 2019 October 22, 2018 7 EVPN ELAN FRR Loop Prevent label 8 draft-wang-bess-evpn-frr-label-00 10 Abstract 12 This document describes how to use Fast Re-Route (FRR) labels avoid 13 loop problems in CE failures when deploying FRR protection in EVPN 14 scenarios. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC 2119 [RFC2119]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 25, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. FRR Label Extended Community . . . . . . . . . . . . . . . . 3 58 3. The Control Plane Process . . . . . . . . . . . . . . . . . . 4 59 4. The Data Plane Process . . . . . . . . . . . . . . . . . . . 4 60 5. Other considerations . . . . . . . . . . . . . . . . . . . . 5 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 64 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 In the EVPN active-active scenario, to solve the failure of a CE 70 access channel to one PE, we can deploy Fast Re-Route (FRR) 71 protection mode to achieve fast convergence. All active PEs can be 72 deployed with FRR. When a link failure occurs on the CE connection 73 to the PE, traffic can be rapidly FRRed to another PE to improve the 74 switching performance. However, if the CE device fails, both the two 75 PEs sense that their CE link is faulty at the same time. They will 76 each perform fast switching according to the FRR. Then the traffic 77 will loop between the dual PEs. If one PE detects a failure and 78 cancels the ES-AD route, the other PE, after receiving the withdrawal 79 of the ES-AD route, deletes the FRR path to the PE, and the loop is 80 eliminated. The time until the loop is eliminated may be short, but 81 during this time, the loop will cause traffic congestion between the 82 dual-homing PEs. 84 +-----+ 85 | CE2 | 86 +-----+ 87 | 88 +-----+ 89 | EVI1| 90 | PE3 | 91 +-----+ 92 / \ 93 / \ 94 / \ 95 / \ 96 / \ 97 +-----+ +-----+ 98 | PE1 | | PE2 | 99 | EVI1|-------------| EVI1| 100 +-----+ +-----+ 101 \ / 102 \ / 103 ESI1 ESI1 104 \ Trunk / 105 +\-----/+ 106 | \ / | 107 +---+---+ 108 | 109 +-----+ 110 | CE1 | 111 +-----+ 112 Figure 1: Basic networking of the EVPN all-active scenario 114 2. FRR Label Extended Community 116 The FRR Label Extended Community is a new transitive Extended 117 Community having a Type field value of 0x06 and the Sub-Type TBD. It 118 may be advertised along with MAC/IP Advertisement routes and Ethernet 119 A-D per EVI routes. 121 The FRR Label Extended Community is encoded as an 8-octet value, as 122 follows: 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Type=0x06 | Sub-Type=TBD | Flags(1 octet)| Reserved=0 | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Reserved=0 | FRR Label | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 3. The Control Plane Process 133 If we enable the FRR LABEL function for an instance, then when the PE 134 advertises the MAC-IP route or Ethernet A-D per EVI route of the 135 instance, it also carries an FRR Label Extended Community attribute. 137 When another PE on the dual-homed side receives the MAC-IP route or 138 the EVI-AD route, and uses the Label in the FRR Label Extended 139 Community attribute as the label for the Edge FRR path. The single- 140 homing-side PE receives the MAC-IP route or Ethernet A-D per EVI 141 route advertised by the PE will ignores the FRR Label Extended 142 Community attribute. 144 Because the FRR Label Extended Community attribute is an optional 145 transitve attribute, if there are RR devices or ASBR devices in the 146 network, the attributes can be transparently transmitted and 147 processed by the final PE device. 149 Taking Figure 1 as an example, the EVI1 of PE2 enables the FRR LABEL 150 function, and PE2 applies for a new label. PE2 advertises the MAC-IP 151 route and the Ethernet A-D per EVI route carries the label through 152 the FRR Label Extended Community attribute. Because CE1 is dual- 153 homed to PE1 and PE2, PE1 learns the MAC address of CE1 from the data 154 plane. Therefore, when PE1 receives the MAC-IP route or Ethernet A-D 155 per EVI route from PE2, it can generate the MAC address learned from 156 CE1 to form an edge FRR entry and the label filled in the FRR entry 157 is the FRR label. 159 For PE3, even if CE1 is dual-homed to PE1 and PE2 in single-active 160 mode, PE3 form FRR does not use the FRR label. 162 The feature is available for both EVPN ELAN service and EVPN VPWS 163 service. 165 4. The Data Plane Process 167 The PE receives the traffic from the network side and finds the 168 corresponding bridge-domain according to the Label. If the Label is 169 a normal EVI label, the MAC address is normally queried. If the 170 local outbound interface of the MAC fails, the FRR of the MAC is 171 further protected. If the Label is an FRR label, the MAC address 172 continues to be queried normally. If the local outbound interface of 173 the MAC fails, the FRR of the MAC is no longer protected. 175 5. Other considerations 177 The solution of this document is not only applicable to the EVPN 178 scenario. The traditional L3VPN can also use this solution to 179 achieve rapid loop breaking. 181 6. IANA Considerations 183 IANA is requested to assign a new type of FRR label extended 184 community with value TBD. 186 7. Security Considerations 188 TBD 190 8. Acknowledgements 192 9. Normative References 194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 195 Requirement Levels", BCP 14, RFC 2119, 196 DOI 10.17487/RFC2119, March 1997, 197 . 199 Authors' Addresses 201 Haibo (Rainsword) Wang 202 Huawei Technologies 203 Huawei Bld., No.156 Beiqing Road 204 Beijing 100085 205 China 207 Email: rainsword.wang@huawei.com 209 Donald Eastlake 3rd 210 Huawei Technologies 211 1424 Pro Shop Court 212 Davenport, FL 33896 213 USA 215 Phone: +1-508-333-2270 216 Email: d3e3e3@gmail.com