idnits 2.17.00 (12 Aug 2021) /tmp/idnits25896/draft-ietf-idr-bgp-bfd-strict-mode-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 date (September 21, 2019) is 973 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 (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR WorkGroup M. Zheng 3 Internet-Draft Indivdual Contributor 4 Intended status: Standards Track A. Lindem 5 Expires: March 24, 2020 Cisco Systems 6 J. Haas 7 Juniper Networks, Inc. 8 September 21, 2019 10 BGP BFD Strict-Mode 11 draft-ietf-idr-bgp-bfd-strict-mode-00 13 Abstract 15 This document specifies extensions to RFC4271 BGP-4 that enable a BGP 16 speaker to negotiate additional Bidirectional Forwarding Detection 17 (BFD) extensions using a BGP capability. This BFD capability enables 18 a BGP speaker to prevent a BGP session from being established until a 19 BFD session is established. It is referred to as BGP BFD "strict- 20 mode". BGP BFD strict-mode will be supported when both the local 21 speaker and its remote peer are BFD strict-mode capable. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 24, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. BFD Capability . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Manageability Considerations . . . . . . . . . . . . . . . . 5 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 65 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 Bidirectional Forwarding Detection BFD [RFC5882] enables routers to 71 monitor data plane connectivity and to detect faults in the 72 bidirectional forwarding path between them. This capability is 73 leveraged by routing protocols such as BGP [RFC4271] to rapidly react 74 to topology changes in the face of path failures. 76 The BFD interaction with BGP is specified in Section 10.2 of 77 [RFC5882]. When BFD is enabled for a BGP neighbor, faults in the 78 bidirectional forwarding detected by BFD result in session 79 termination. It is possible in some failure scenarios for the 80 network to be in a state such that a BGP session may be established 81 but a BFD session cannot be established. In some other scenarios, it 82 may be possible to establish a BGP session, but a degraded or poor- 83 quality link may result in the corresponding BFD session going up and 84 down frequently. 86 To avoid situations which result in routing churn and to minimize the 87 impact of network interruptions, it will be beneficial to disallow 88 BGP to establish a session until BFD session is successfully 89 established and has stabilized. We refer to this mode of operation 90 as BGP BFD "strict-mode". However, always using "strict-mode" would 91 preclude BGP operation in an environment where not all routers 92 support BFD strict-mode or have BFD enabled. This document defines 93 BGP "strict-mode" operation as preventing BGP session establishment 94 until both the local and remove speakers have a stable BFD session. 95 The document also specifies the BGP protocol extensions for BGP 96 capability [RFC5492] for announcing BFD parameters including a BGP 97 speaker's support for "strict-mode", i.e., requiring a BFD session 98 for BGP session establishment. 100 2. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 3. BFD Capability 110 The BGP Capability [RFC5492] for BFD parameters will allow a BGP 111 speaker's BFD capabilities including its support for BFD strict-mode. 112 This capability is defined as follows: 114 Capability code: TBD 116 Capability length: 1 octet 118 Capability value: Consists of 1 octet BFD flags as follows: 120 +--------------------------------------------------+ 121 | BFD Flags (8 bits) | 122 +--------------------------------------------------+ 124 The use and meaning of the fields are as follows: 126 BFD Flags: This field contains bit flags relating to BFD. 128 0 1 2 3 4 5 6 7 129 +-+-+-+-+-+-+-+-+ 130 |S| Reserved | 131 +-+-+-+-+-+-+-+-+ 133 The most significant bit is defined as state of Strict-Mode ("Strict- 134 Mode", or "S") bit, which can be used by a BGP speaker to signal its 135 support for BFD Strict-mode. When set (value 1), this bit indicates 136 that the BGP speaker has the BFD "Strict-mode" enabled. If both 137 local BGP speaker and its peer have BFD strict-mode enabled, then BGP 138 session establishment will be prevented until a BFD session is 139 established between the peering addresses. A BGP speaker with BFD 140 strict-mode enabled MUST advertise the BFD capability with "S" bit 141 set. 143 The remaining bits are reserved and SHOULD be set to zero by the 144 sender and MUST be ignored by the receiver. 146 4. Operation 148 A BGP speaker which supports capabilities advertisement and has BFD 149 strict-mode enabled MUST include the BGP BFD capability with the "S" 150 Bit set in the BGP capabilities it advertises. 152 A BGP speaker which supports BFD capability, examines the list of 153 capabilities present in the Capabilities BFD Parameter that the 154 speaker receives from its peer. If both the local and remote BGP 155 speakers have BFD strict-mode enabled, the BGP finite state machine 156 does not transition to the Established state from OpenSent or 157 OpenConfirm state [RFC4271] until the BFD session is in the Up state 158 (see below for AdminDown state). This means that a KEEPALIVE message 159 is not sent nor is the KeepaliveTimer set. 161 If the BFD session does not transition to the Up state, and the 162 HoldTimer has been negotiated to a non-zero value, the BGP FSM will 163 close the session appropriately. If the HoldTimer has been 164 negotiated to a zero value, the session should be closed after a time 165 of X. This time X is referred as "BGP BFD Hold time". The proposed 166 default BGP BFD Hold time value is 30 seconds. The BGP BFD Hold time 167 value is configurable. 169 If BFD session is in the AdminDown state, then the BGP finite state 170 machine will proceed normally without input from BFD. This means 171 that BFD session "AdminDown" state WILL NOT prevent the BGP state 172 transition to Established state from OpenConfirm. 174 Once the BFD session has transitioned to the Up state, the BGP FSM 175 may proceed to transition to the Established state from the OpenSent 176 or OpenConfirm state appropriately. I.e. a KEEPALIVE message is 177 sent, and the KeepaliveTimer is started. 179 If either BGP peer has not advertised the BFD Capability with strict- 180 mode enabled, then a BFD session WILL NOT be required for the BGP 181 session to reach Established state. This does not preclude usage of 182 BFD after BGP session establishment [RFC5882]. 184 5. Manageability Considerations 186 Auto-configuration is possible for the enabling BGP BFD restrict- 187 mode. However, the configuration automation is out of the scope of 188 this document. 190 A BGP NOTIFICATION message subcode indicating BFD Hold timer 191 expiration may be required for network management. (To be discussed 192 in the next revision of this document.) 194 6. Security Considerations 196 The mechanism defined in this document interacts with the BGP finite 197 state machine when so configured. The security considerations of BFD 198 thus become considerations for BGP-4 [RFC4271] so used. The use of 199 the BFD Authentication mechanism defined in [RFC5880] is thus 200 RECOMMENDED when used to protect BGP-4 [RFC4271]. 202 7. IANA Considerations 204 This document defines a new BGP capability - BFD Capability. The 205 Capability Code for BFD Capability is TBD. 207 IANA is requested to establish a "BGP BFD Capability Flags" registry 208 within the "Border Gateway Protocol (BGP) Parameters" grouping. The 209 Registration Procedure should be Standards Action, the initial values 210 as follows: 212 +--------------+---------------+------------+---------------+ 213 | Bit Position | Name | Short Name | Reference | 214 +--------------+---------------+------------+---------------+ 215 | 0 | Strict-Mode | S | this document | 216 | 1-7 | Unassigned | | this document | 217 +--------------+---------------+------------+---------------+ 219 8. Acknowledgement 221 The authors would like to acknowledge the review and inputs from 222 Shyam Sethuram, Mohammed Mirza, Bruno Decraene, and Carlos Pignataro. 224 9. Normative References 226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 227 Requirement Levels", BCP 14, RFC 2119, 228 DOI 10.17487/RFC2119, March 1997, 229 . 231 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 232 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 233 DOI 10.17487/RFC4271, January 2006, 234 . 236 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 237 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 238 2009, . 240 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 241 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 242 . 244 [RFC5882] Katz, D. and D. Ward, "Generic Application of 245 Bidirectional Forwarding Detection (BFD)", RFC 5882, 246 DOI 10.17487/RFC5882, June 2010, 247 . 249 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 250 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 251 May 2017, . 253 Authors' Addresses 255 Mercia Zheng 256 Indivdual Contributor 258 Email: merciaz.ietf@gmail.com 260 Acee Lindem 261 Cisco Systems 262 301 Midenhall Way 263 GARY, NC 27513 264 UNITED STATES 266 Email: acee@cisco.com 267 Jeffrey Haas 268 Juniper Networks, Inc. 269 1133 Innovation Way 270 SUNNYVALE, CALIFORNIA 94089 271 UNITED STATES 273 Email: jhaas@juniper.net