idnits 2.17.1 draft-merciaz-idr-bgp-bfd-strict-mode-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 date (April 3, 2019) is 1850 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 A. Lindem 4 Intended status: Standards Track Cisco Systems 5 Expires: October 5, 2019 April 3, 2019 7 BGP BFD Strict-Mode 8 draft-merciaz-idr-bgp-bfd-strict-mode-01 10 Abstract 12 This document specifies extensions to RFC4271 BGP-4 that enable a BGP 13 speaker to signal additional Bidirectional Forwarding Detection (BFD) 14 extensions using an optional parameter BFD capability. This BFD 15 capability enables a BGP speaker to prevent a BGP session from being 16 established until a BFD session is established. It is referred to as 17 BGP BFD "strict-mode". BGP BFD strict-mode will be supported when 18 both the local speaker and its remote peer are BFD strict-mode 19 capable, Otherwise, a BGP speaker and its peer should not require a 20 BFD session for BGP session establishment. 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 http://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 October 5, 2019. 39 Copyright Notice 41 Copyright (c) 2019 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 (http://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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. BFD Capability . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 4 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 64 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 Bidirectional Forwarding Detection BFD [RFC5882] enables routers to 70 monitor data plane connectivity and to detect faults in the 71 bidirectional forwarding path between them. This capability is 72 leveraged by routing protocols such as BGP [RFC4271] to rapidly react 73 to topology changes in the face of path failures. 75 The BFD interaction with BGP is specified in Section 10.2 of 76 [RFC5882]. When BFD is enabled for a BGP neighbor, faults in the 77 bidirectional forwarding detected by BFD result in session 78 termination. It is possible in some failure scenarios for the 79 network to be in a state such that a BGP session may be established 80 but a BFD session cannot be established. In some other scenarios, it 81 may be possible to establish a BGP session, but a degraded or poor- 82 quality link may result in the corresponding BFD session going up and 83 down frequently. 85 To avoid situations which result in routing churn and to minimize the 86 impact of network interruptions, it will be beneficial to disallow 87 BGP to establish a neighbor session until s BFD session is 88 successfully established and has stabilized. We refer to this mode 89 of operation as BGP BFD "strict-mode". However, always using 90 "strict-mode" would preclude BGP operation in an environment where 91 not all routers support BFD strict-mode or have BFD enabled. This 92 document defines BGP "strict-mode" operation as preventing BGP 93 session establishment until both the local and remove speakers have a 94 stable BFD session. The document also specifies the BGP protocol 95 extensions for BGP capability [RFC5492] for announcing BFD parameters 96 including a BGP speaker's support for "strict-mode", i.e., requiring 97 a BFD session for BGP session establishment. 99 2. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 3. BFD Capability 109 The BGP Capability [RFC5492] for BFD parameters will allow a BGP 110 speaker's BFD capabilities including its support for BFD strict-mode. 111 This capability is defined as follows: 113 Capability code: TBD 115 Capability length: 1 octet 117 Capability value: Consists of 1 octet BFD flags as follows: 119 +--------------------------------------------------+ 120 | BFD Flags (8 bits) | 121 +--------------------------------------------------+ 123 The use and meaning of the fields are as follows: 125 BFD Flags: This field contains bit flags relating to BFD. 127 0 1 2 3 4 5 6 7 128 +-+-+-+-+-+-+-+-+ 129 |S| Reserved | 130 +-+-+-+-+-+-+-+-+ 132 The most significant bit is defined as state of Strict-Mode ("Strict- 133 Mode", or "S") bit, which can be used by a BGP speaker to signal its 134 support for BFD Strict-mode. When set (value 1), this bit indicates 135 that the BGP speaker has the BFD "Strict-mode" enabled. If both 136 local BGP speaker and its peer have BFD strict-mode enabled, then BGP 137 session establishment will be prevented until a BFD session is 138 established between the peering addresses. A BGP speaker with BFD 139 strict-mode enabled MUST advertise the BFD capability with "S" bit 140 set. 142 The remaining bits are reserved and SHOULD be set to zero by the 143 sender and MUST be ignored by the receiver. 145 4. Operation 147 A BGP speaker that supports capabilities advertisement sends an OPEN 148 message to its BGP peer, the message MAY include an Optional 149 Parameter, called Capabilities. The parameter lists the capabilities 150 supported by the speaker. By following BGP capabilities 151 advertisement procedures defined in [RFC5492], BFD capability 152 advertisement for strict-mode is advertised to BGP peers. 154 If both BGP speakers advertise the BFD capability with the strict- 155 mode bit set, then the BGP state machine will be held in OpenConfirm 156 state [RFC4271] until a BFD session is established or the BGP session 157 is terminated for some other reason (e.g., the BGP Hold time expires. 159 A BGP speaker which supports capabilities advertisement and has BFD 160 strict-mode enabled MUST include the BGP BFD capability with the "S" 161 Bit set in the BGP capabilities it advertises. 163 A BGP speaker which supports BFD capability advertisement, examines 164 the list of capabilities present in the Capabilities BFD Parameter 165 that the speaker receives from its peer. If both the local and 166 remote BGP speakers BFD strict-mode enabled, then the BGP session 167 will be held in OpenConfirm state until a BFD session is established 168 between the two BGP speaker or the BGP session terminates for some 169 other reason, e.g., the BGP hold timer expires. If either peer has 170 not advertised the BFD Capability with strict-mode enabled, then a 171 BFD session WILL NOT be required for the BGP session to reach 172 Established state. This does not preclude usage of BFD after BGP 173 session establishment [RFC5882]. 175 5. Backward Compatibility 177 The BFD capability will not introduce any backward compatibility will 178 not result in any backward compatibility issues as long as the 179 procedures in [RFC5492] and Section 4 are followed. As per 180 [RFC5492], a BGP speaker which does not support the BFD capability 181 will ignore the BFD capability. If a BGP speaker advertising the 182 capability receives the Unsupported Capability NOTIFICATION message 183 and terminates the BGP session, the BGP speaker advertising the BFD 184 capability SHOULD simply attempt to reestablish the BGP session with 185 the BFD capability omitted. 187 6. Security Considerations 189 This specification doesn't change the basic security model inherent 190 in [RFC4271]. However, it does introduce a new indirect attack 191 vector for BGP since it is now dependent on BFD. 193 7. IANA Considerations 195 This document defines a new BGP capability - BFD Capability. The 196 Capability Code for BFD Capability is TBD. 198 IANA is requested to establish a "BGP BFD Capability Flags" registry 199 within the "Border Gateway Protocol (BGP) Parameters" grouping. The 200 Registration Procedure should be Standards Action, the initial values 201 as follows: 203 +--------------+---------------+------------+---------------+ 204 | Bit Position | Name | Short Name | Reference | 205 +--------------+---------------+------------+---------------+ 206 | 0 | Strict-Mode | S | this document | 207 | 1-7 | Unassigned | | this document | 208 +--------------+---------------+------------+---------------+ 210 8. Acknowledgement 212 The authors would like to acknowledge the review and inputs from 213 Shyam Sethuram, Mohammed Mirza, and Bruno Decraene. 215 9. Normative References 217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 218 Requirement Levels", BCP 14, RFC 2119, 219 DOI 10.17487/RFC2119, March 1997, . 222 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 223 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 224 DOI 10.17487/RFC4271, January 2006, . 227 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 228 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 229 2009, . 231 [RFC5882] Katz, D. and D. Ward, "Generic Application of 232 Bidirectional Forwarding Detection (BFD)", RFC 5882, 233 DOI 10.17487/RFC5882, June 2010, . 236 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 237 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 238 May 2017, . 240 Authors' Addresses 242 Mercia Zheng 243 Cisco Systems 244 821 Alder Drive, 245 MILPITAS, CALIFORNIA 95035 246 UNITED STATES 248 Email: merciaz@cisco.com 250 Acee Lindem 251 Cisco Systems 252 821 Alder Drive, 253 MILPITAS, CALIFORNIA 95035 254 UNITED STATES 256 Email: acee@cisco.com