idnits 2.17.1 draft-zwm-bess-es-failover-03.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 date (November 15, 2020) is 1230 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) == Outdated reference: A later version (-11) exists of draft-ietf-bess-evpn-lsp-ping-03 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 WG Z. Zhang 3 Internet-Draft Y. Wang 4 Intended status: Standards Track G. Mirsky 5 Expires: May 19, 2021 ZTE Corporation 6 November 15, 2020 8 Bidirectional Forwarding Detection (BFD) for EVPN Ethernet Segment 9 Failover Use Case 10 draft-zwm-bess-es-failover-03 12 Abstract 14 This document introduces a method for fast switchover of Designated 15 Forwarder for Ethernet Segment failover by using Bidirectional 16 Forwarding Detection protocol. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 19, 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions used in this document . . . . . . . . . . . . . . 3 54 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. BDF changes . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 [RFC7432] introduces Ethernet Virtual Private Network (EVPN) 67 technology. Designated Forwarder (DF) election procedures for multi- 68 homing Ethernet Segments has been described in it. When PE (provider 69 edge) receives BUM (Broadcast, Unknown Unicast and Multicast) flows, 70 only DF forwards the BUM flows to CE (customer edge). Non-DFs do not 71 forward the BUM flows in order to avoid duplication. If the link 72 between DF and CE fails, another PE will forward the BUM flows after 73 it is elected as DF. 75 [RFC8584] defines the DF election framework, including that Backup 76 Designated Forwarder (BDF) can be elected as the next best for the 77 role. But before the BDF is elected as DF, the BUM flows are 78 discarded after the link between DF and CE fails. 80 +-----+ 81 +-----X----+ PE1 | 82 | +--+--+ 83 | 84 +-+--+ 85 | CE | 86 +-+--+ 87 | 88 | +--+--+ 89 +----------+ PE2 | 90 +-----+ 92 For example, CE is multihomed to PE1 and PE2. PE1 is elected as DF. 93 All BUM flows are forwarded by PE1 when the link between PE1 and CE 94 is operational. When the link between PE1 and CE fails, the BUM 95 flows are discarded until PE2 is elected as DF. 97 This document will use terminology defined in [RFC7432] and 98 [I-D.ietf-bess-evpn-lsp-ping]. 100 2. Conventions used in this document 102 2.1. Terminology 104 BFD: Bidirectional Forwarding Detection 106 BDF: Backup Designted Forwarder 108 DF: Designated Forwarder 110 BUM: Broadcast, Unknown unicast, and Multicast 112 PE: Provider Edge 114 EVPN: Ethernet Virtual Private Network 116 CE: Customer Edge 118 ES: Ethernet Segment 120 ESI: Ethernet Segment Identifier 122 2.2. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 3. Proposal 132 In order to avoid the BUM packet loss on BDF after the link between 133 DF and CE fails, a data-plane detection function is needed for DF 134 fast switchover. [RFC5884] provides mechanisms for using LSP Ping to 135 bootstrap a BFD session. [I-D.ietf-bess-evpn-lsp-ping] introduces 136 four new Target FEC Stack sub-TLVs that are included in the LSP-Ping 137 Echo Request packet. This document uses the mechanisms defined in 138 [RFC5884] and the EVPN Ethernet Auto-Discovery (AD) sub-TLV defined 139 in [I-D.ietf-bess-evpn-lsp-ping] to provide DF fast switchover by 140 data-plane failure detection. 142 An LSP-Ping Echo Request message which carries EVPN AD Sub-TLV 143 associated with the DF-CE Ethernet Segment Identifier (ESI) is used 144 to bootstrap the BFD session between BDF and DF. After the BFD 145 session is built, when the Ethernet Segment (ES) fault occurs on DF- 146 CE link, BDF detects the fault by the state change BFD control packet 147 sent by DF, or BDF detects the fault when the detection timer 148 expires. Then BDF becomes DF and will forward the BUM flows to CE. 150 4. Specification 152 [I-D.ietf-bess-evpn-lsp-ping] section 4.3 defines an Ethernet AD sub- 153 TLV as a new Target FEC Stack sub-TLV. It is carried in the LSP-Ping 154 Echo Request message. BDF generates an LSP-Ping Echo Request message 155 which carries the associated ES AD sub-TLV. And BDF sends the 156 message with a local discriminator assigned by BDF for this BFD 157 session to DF. DF responds with the BFD control packet with 'Your 158 discriminator' set to the discriminator value received in the Echo 159 request message from the BDF. BDF can demultiplex the BFD session 160 based on the received 'Your Discriminator' field. 162 After the BFD session is established, when the link between DF and CE 163 fails, DF MUST send a BFD control packet with the value of State 164 field set to AdminDown through the established BFD session to BDF. 165 If DF is not operational, BDF also detects the failure when the BFD 166 detection time expires. Then BDF becomes DF immediately and forwards 167 the BUM flows to CE. 169 When the ES between 'old' DF and CE recovers, the BFD session MAY be 170 reused or a new BFD session can be established for the ES failover 171 monitor. 173 For the same example in last section, PE2 generates an LSP-Ping Echo 174 Request message which carries the associated ES AD sub-TLV and sends 175 the message with an assigned local discriminator to DF. PE1 responds 176 with a BFD control packet with 'Your Discriminator' set to the 177 received discriminator from PE2. PE2 can demultiplex the BFD session 178 based on the received 'Your Discriminator' field. 180 When the link between PE1 and CE fails, PE1 sends a BFD control 181 packet with the state set to AdminDown to PE2 through the BFD 182 session. If the packet is lost, PE2 also can detect the fault by the 183 session detection time expiration. PE2 becomes DF immediately, then 184 the BUM packets can be forwarded to CE. 186 The value of bfd.DetectMult (detect multiplier) determines when a BFD 187 system detects a failure. Once BDF detects the loss of the number, 188 equal to the detect multiplier, of consecutive BFD messages for the 189 session between DF and BDF are lost, the BDF will elect itself as DF. 190 Then, BUM flows are duplicated because of the two DFs. To avoid this 191 situation, the bfd.DetectMult MUST be set to more than 1 (common 192 default value is 3). 194 4.1. BDF changes 196 If a new router, which can become new BDF, joins the network, the 197 'old' BDF MUST send a number of consecutive BFD messages with the 198 State set to AdminDown to DF, then DF will remove this BFD session. 199 When DF receives a new session request from the new BDF, DF 200 establishes a new BFD session with the new BDF. 202 5. Security Considerations 204 This document does not introduce any new security considerations 205 other than already discussed in [RFC7432] and [RFC5884]. 207 6. IANA Considerations 209 There is no IANA consideration. 211 7. Normative References 213 [I-D.ietf-bess-evpn-lsp-ping] 214 Jain, P., Salam, S., Sajassi, A., Boutros, S., and G. 215 Mirsky, "LSP-Ping Mechanisms for EVPN and PBB-EVPN", 216 draft-ietf-bess-evpn-lsp-ping-03 (work in progress), 217 August 2020. 219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 220 Requirement Levels", BCP 14, RFC 2119, 221 DOI 10.17487/RFC2119, March 1997, 222 . 224 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 225 "Bidirectional Forwarding Detection (BFD) for MPLS Label 226 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 227 June 2010, . 229 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 230 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 231 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 232 2015, . 234 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 235 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 236 May 2017, . 238 [RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, 239 J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet 240 VPN Designated Forwarder Election Extensibility", 241 RFC 8584, DOI 10.17487/RFC8584, April 2019, 242 . 244 Authors' Addresses 246 Zheng(Sandy) Zhang 247 ZTE Corporation 248 No. 50 Software Ave, Yuhuatai Distinct 249 Nanjing 250 China 252 Email: zhang.zheng@zte.com.cn 254 Yubao Wang 255 ZTE Corporation 256 No. 50 Software Ave, Yuhuatai Distinct 257 Nanjing 258 China 260 Email: wang.yubao2@zte.com.cn 262 Greg Mirsky 263 ZTE Corporation 265 Email: gregimirsky@gmail.com