idnits 2.17.00 (12 Aug 2021) /tmp/idnits15315/draft-ietf-idr-bgp-gr-notification-16.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 (Using the creation date from RFC4724, updated by this document, for RFC5378 checks: 2000-12-19) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 27, 2018) is 1264 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) ** Obsolete normative reference: RFC 8203 (Obsoleted by RFC 9003) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force K. Patel 3 Internet-Draft Arrcus 4 Updates: 4724 (if approved) R. Fernando 5 Intended status: Standards Track Cisco Systems 6 Expires: May 31, 2019 J. Scudder 7 J. Haas 8 Juniper Networks 9 November 27, 2018 11 Notification Message support for BGP Graceful Restart 12 draft-ietf-idr-bgp-gr-notification-16.txt 14 Abstract 16 The BGP Graceful Restart mechanism defined in RFC 4724 limits the 17 usage of BGP Graceful Restart to BGP protocol messages other than a 18 BGP NOTIFICATION message. This document updates RFC 4724 by defining 19 an extension that permits the Graceful Restart procedures to be 20 performed when the BGP speaker receives a BGP NOTIFICATION Message or 21 the Hold Time expires. This document also defines a new BGP 22 NOTIFICATION Cease Error subcode whose effect is to request a full 23 session restart instead of a Graceful Restart. 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 May 31, 2019. 42 Copyright Notice 44 Copyright (c) 2018 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Modifications to BGP Graceful Restart Capability . . . . . . 3 62 3. BGP Hard Reset Subcode . . . . . . . . . . . . . . . . . . . 3 63 3.1. Sending a Hard Reset . . . . . . . . . . . . . . . . . . 4 64 3.2. Receiving a Hard Reset . . . . . . . . . . . . . . . . . 4 65 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Rules for the Receiving Speaker . . . . . . . . . . . . . 5 67 5. Use of Hard Reset . . . . . . . . . . . . . . . . . . . . . . 6 68 5.1. When to Send Hard Reset . . . . . . . . . . . . . . . . . 6 69 5.2. Interaction With Other Specifications . . . . . . . . . . 7 70 6. Management Considerations . . . . . . . . . . . . . . . . . . 7 71 7. Operational Considerations . . . . . . . . . . . . . . . . . 7 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 11. Normative References . . . . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 For many classes of errors, the BGP protocol must send a NOTIFICATION 81 message and reset the peering session to handle the error condition. 82 The BGP Graceful Restart extension defined in [RFC4724] requires that 83 normal BGP procedures defined in [RFC4271] be followed when a 84 NOTIFICATION message is sent or received. This document defines an 85 extension to BGP Graceful Restart that permits the Graceful Restart 86 procedures to be performed when the BGP speaker receives a 87 NOTIFICATION message or the Hold Time expires. This permits the BGP 88 speaker to avoid flapping reachability and continue forwarding while 89 the BGP speaker restarts the session to handle errors detected in the 90 BGP protocol. 92 At a high level, this document can be summed up as follows. When a 93 BGP session is reset, both speakers operate as "Receiving Speakers" 94 according to [RFC4724], meaning they retain each other's routes. 95 This is also true for HOLDTIME expiration. The functionality can be 96 defeated using a "Hard Reset" subcode for the BGP NOTIFICATION Cease 97 Error code. If a Hard Reset is used, a full session reset is 98 performed. 100 1.1. 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 2. Modifications to BGP Graceful Restart Capability 110 The BGP Graceful Restart Capability is augmented to signal the 111 Graceful Restart support for BGP NOTIFICATION messages. The Restart 112 Flags field is augmented as follows (following the diagram from 113 section 3 of [RFC4724]): 115 Restart Flags: 117 This field contains bit flags relating to restart. 119 0 1 2 3 120 +-+-+-+-+ 121 |R|N| | 122 +-+-+-+-+ 124 The most significant ("Restart State", or "R") bit is defined in 125 [RFC4724]. 127 The second most significant bit ("N") is defined as the BGP Graceful 128 Notification bit, which is used to indicate Graceful Restart support 129 for BGP NOTIFICATION messages. A BGP speaker indicates support for 130 the procedures of this document, by advertising a Graceful Restart 131 Capability with its Graceful Notification bit set (value 1). 133 If a BGP speaker that previously advertised a given set of Graceful 134 Restart parameters opens a new session with a different set of 135 parameters, these new parameters apply once the session has 136 transitioned into ESTABLISHED state. 138 3. BGP Hard Reset Subcode 140 We define a new BGP NOTIFICATION Cease message subcode, called the 141 BGP Hard Reset Subcode. The value of this subcode is discussed in 142 Section 9. We refer to a BGP NOTIFICATION Cease message with the 143 Hard Reset subcode as a Hard Reset message, or just a Hard Reset. 145 When the "N" bit has been exchanged by two peers, to distinguish them 146 from Hard Reset we refer to any NOTIFICATION messages other than Hard 147 Reset as "Graceful", since such messages invoke Graceful Restart 148 semantics. 150 3.1. Sending a Hard Reset 152 A Hard Reset message is used to indicate to a peer with which the 153 Graceful Notification bit has been exchanged, that the session is to 154 be fully terminated. 156 When sending a Hard Reset, the data portion of the NOTIFICATION is 157 encoded as follows: 159 +--------+--------+-------- 160 | ErrCode| Subcode| Data 161 +--------+--------+-------- 163 ErrCode is a BGP Error Code (as documented in the IANA BGP Error 164 Codes registry) that indicates the reason for the Hard Reset. 165 Subcode is a BGP Error Subcode (as documented in the IANA BGP Error 166 Subcodes registry) as appropriate for the ErrCode. Similarly, Data 167 is as appropriate for the ErrCode and Subcode. In short, the Hard 168 Reset encapsulates another NOTIFICATION message in its data portion. 170 3.2. Receiving a Hard Reset 172 Whenever a BGP speaker receives a Hard Reset, the speaker MUST 173 terminate the BGP session following the standard procedures in 174 [RFC4271]. 176 4. Operation 178 A BGP speaker that is willing to receive and send BGP NOTIFICATION 179 messages according to the procedures of this document MUST advertise 180 the BGP Graceful Notification "N" bit using the Graceful Restart 181 Capability as defined in [RFC4724]. 183 When such a BGP speaker has received the "N" bit from its peer, and 184 receives from that peer a BGP NOTIFICATION message other than a Hard 185 Reset, it MUST follow the rules for the Receiving Speaker mentioned 186 in Section 4.1. The BGP speaker generating the BGP NOTIFICATION 187 message MUST also follow the rules for the Receiving Speaker. 189 When a BGP speaker resets its session due to a HOLDTIME expiry, it 190 should generate the relevant BGP NOTIFICATION message as mentioned in 191 [RFC4271], but subsequently it MUST follow the rules for the 192 Receiving Speaker mentioned in Section 4.1. 194 A BGP speaker SHOULD NOT send a Hard Reset to a peer from which it 195 has not received the "N" bit. We note, however, that if it did so 196 the effect would be as desired in any case, since according to 197 [RFC4271] and [RFC4724] any NOTIFICATION message, whether recognized 198 or not, results in a session reset. Thus the only negative effect to 199 be expected from sending the Hard Reset to a peer that hasn't 200 advertised compliance to this specification would be that the peer 201 would be unable to properly log the associated information. 203 Once the session is re-established, both BGP speakers SHOULD set 204 their "Forwarding State" bit to 1. If the "Forwarding State" bit is 205 not set, then according to the procedures of [RFC4724] section 4.2, 206 the relevant routes will be flushed, defeating the goals of this 207 specification. 209 4.1. Rules for the Receiving Speaker 211 [RFC4724] section 4.2 defines rules for the Receiving Speaker. These 212 are modified as follows. 214 The sentence "To deal with possible consecutive restarts, a route 215 (from the peer) previously marked as stale MUST be deleted" only 216 applies when the "N" bit has not been exchanged with the peer: 218 OLD: When the Receiving Speaker detects termination of the TCP 219 session for a BGP session with a peer that has advertised the 220 Graceful Restart Capability, it MUST retain the routes received 221 from the peer for all the address families that were previously 222 received in the Graceful Restart Capability and MUST mark them 223 as stale routing information. To deal with possible consecutive 224 restarts, a route (from the peer) previously marked as stale 225 MUST be deleted. The router MUST NOT differentiate between 226 stale and other routing information during forwarding. 228 NEW: When the Receiving Speaker detects termination of the TCP 229 session for a BGP session with a peer that has advertised the 230 Graceful Restart Capability, it MUST retain the routes received 231 from the peer for all the address families that were previously 232 received in the Graceful Restart Capability and MUST mark them 233 as stale routing information. The router MUST NOT differentiate 234 between stale and other routing information during forwarding. 235 If the "N" bit has not been exchanged with the peer, then to 236 deal with possible consecutive restarts, a route (from the peer) 237 previously marked as stale MUST be deleted. 239 The stale timer is given a formal name and made mandatory: 241 OLD: To put an upper bound on the amount of time a router retains the 242 stale routes, an implementation MAY support a (configurable) 243 timer that imposes this upper bound. 245 NEW: To put an upper bound on the amount of time a router retains the 246 stale routes, an implementation MUST support a (configurable) 247 timer, called the "stale timer", that imposes this upper bound. 248 A suggested default value for the stale timer is 180 seconds. 249 An implementation MAY provide the option to disable the timer 250 (i.e., to provide an infinite retention time) but MUST NOT do so 251 by default. 253 5. Use of Hard Reset 255 5.1. When to Send Hard Reset 257 Although when to send a Hard Reset is an implementation-specific 258 decision, we offer some advice. Many Cease notification subcodes 259 represent permanent or long-term rather than transient session 260 termination, and as such it's appropriate to use Hard Reset with 261 them. At time of publication, Cease subcodes 1-9 were defined. 263 +-------+------------------------------------+----------------------+ 264 | Value | Name | Suggested Behavior | 265 +-------+------------------------------------+----------------------+ 266 | 1 | Maximum Number of Prefixes Reached | Hard Reset | 267 | 2 | Administrative Shutdown | Hard Reset | 268 | 3 | Peer De-configured | Hard Reset | 269 | 4 | Administrative Reset | Provide user control | 270 | 5 | Connection Rejected | Graceful Cease | 271 | 6 | Other Configuration Change | Graceful Cease | 272 | 7 | Connection Collision Resolution | Graceful Cease | 273 | 8 | Out of Resources | Graceful Cease | 274 | 9 | Hard Reset | Hard Reset | 275 +-------+------------------------------------+----------------------+ 277 Suggestions for Cease Subcode Behavior 279 These suggestions are only that, suggestions, not requirements. It's 280 the nature of BGP implementations that the mapping of internal states 281 to BGP NOTIFICATION codes and subcodes is not always perfect. The 282 guiding principle for the implementor should be that if there is no 283 realistic hope that forwarding can continue or that the session will 284 be re-established within the deadline, Hard Reset should be used. 286 For all other NOTIFICATION codes other than Cease, use of Hard Reset 287 does not appear to be indicated. 289 5.2. Interaction With Other Specifications 291 "BGP Administrative Shutdown Communication" [RFC8203] specifies use 292 of the data portion of the Administrative Shutdown or Administrative 293 Reset Cease to convey a short message. When [RFC8203] is used in 294 conjunction with Hard Reset, the subcode of the outermost Cease MUST 295 be Hard Reset, with the Administrative Shutdown or Reset Cease 296 encapsulated within. The encapsulated administrative shutdown 297 message MUST subsequently be processed according to [RFC8203]. 299 6. Management Considerations 301 When reporting a Hard Reset to network management, the error code and 302 subcode reported MUST be Cease, Hard Reset. If the network 303 management layer in use permits it, the information carried in the 304 Data portion SHOULD be reported as well. 306 7. Operational Considerations 308 Note that long (or infinite) retention time may cause operational 309 issues, and should be enabled with care. 311 8. Acknowledgements 313 The authors would like to thank Jim Uttaro for the suggestion, and 314 Emmanuel Baccelli, Bruno Decraene, Chris Hall, Warren Kumari, Paul 315 Mattes, Robert Raszuk, and Alvaro Retana for their review and 316 comments. 318 9. IANA Considerations 320 IANA has temporarily assigned subcode 9, named "Hard Reset", in the 321 "BGP Cease NOTIFICATION message subcodes" registry. Upon publication 322 of this document as an RFC, IANA is requested to make this allocation 323 permanent. 325 IANA is requested to establish a registry within the "Border Gateway 326 Protocol (BGP) Parameters" grouping, to be called "BGP Graceful 327 Restart Flags". The Registration Procedure should be Standards 328 Action, the reference this document and [RFC4724], and the initial 329 values as follows: 331 +--------------+---------------+------------+---------------+ 332 | Bit Position | Name | Short Name | Reference | 333 +--------------+---------------+------------+---------------+ 334 | 0 | Restart State | R | [RFC4724] | 335 | 1 | Notification | N | this document | 336 | 2, 3 | unassigned | | this document | 337 +--------------+---------------+------------+---------------+ 339 IANA is requested to establish a registry within the "Border Gateway 340 Protocol (BGP) Parameters" grouping, to be called "BGP Graceful 341 Restart Flags for Address Family". The Registration Procedure should 342 be Standards Action, the reference this document and [RFC4724], and 343 the initial values as follows: 345 +--------------+------------------+------------+---------------+ 346 | Bit Position | Name | Short Name | Reference | 347 +--------------+------------------+------------+---------------+ 348 | 0 | Forwarding State | F | [RFC4724] | 349 | 1-7 | unassigned | | this document | 350 +--------------+------------------+------------+---------------+ 352 10. Security Considerations 354 This specification doesn't change the basic security model inherent 355 in [RFC4724], with the exception that the protection against repeated 356 resets is relaxed. To mitigate the consequent risk that an attacker 357 could use repeated session resets to prevent stale routes from ever 358 being deleted, we make the stale routes timer mandatory (in practice 359 it is already ubiquitous). To the extent [RFC4724] might be said to 360 help defend against denials of service by making the control plane 361 more resilient, this extension may modestly increase that resilience; 362 however, there are enough confounding and deployment-specific factors 363 that no general claims can be made. 365 11. Normative References 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, 369 DOI 10.17487/RFC2119, March 1997, 370 . 372 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 373 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 374 DOI 10.17487/RFC4271, January 2006, 375 . 377 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 378 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 379 DOI 10.17487/RFC4724, January 2007, 380 . 382 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 383 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 384 May 2017, . 386 [RFC8203] Snijders, J., Heitz, J., and J. Scudder, "BGP 387 Administrative Shutdown Communication", RFC 8203, 388 DOI 10.17487/RFC8203, July 2017, 389 . 391 Authors' Addresses 393 Keyur Patel 394 Arrcus 396 Email: keyur@arrcus.com 398 Rex Fernando 399 Cisco Systems 400 170 W. Tasman Drive 401 San Jose, CA 95134 402 USA 404 Email: rex@cisco.com 406 John Scudder 407 Juniper Networks 408 1194 N. Mathilda Ave 409 Sunnyvale, CA 94089 410 USA 412 Email: jgs@juniper.net 414 Jeff Haas 415 Juniper Networks 416 1194 N. Mathilda Ave 417 Sunnyvale, CA 94089 418 USA 420 Email: jhaas@juniper.net