idnits 2.17.1 draft-ietf-idr-bgp-gr-notification-06.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 4, 2015) is 3095 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 Network Working Group K. Patel 3 Internet-Draft R. Fernando 4 Intended status: Standards Track Cisco Systems 5 Expires: May 7, 2016 J. Scudder 6 J. Haas 7 Juniper Networks 8 November 4, 2015 10 Notification Message support for BGP Graceful Restart 11 draft-ietf-idr-bgp-gr-notification-06.txt 13 Abstract 15 The current BGP Graceful Restart mechanism limits the usage of BGP 16 Graceful Restart to BGP protocol messages other than a BGP 17 NOTIFICATION message. This document defines an extension to the BGP 18 Graceful Restart that permits the Graceful Restart procedures to be 19 performed when the BGP speaker receives a BGP NOTIFICATION Message or 20 the Hold Time expires. This document also defines a new BGP 21 NOTIFICATION Cease Error subcode to prevent BGP speakers supporting 22 the extension defined in this document from performing a Graceful 23 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 http://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 7, 2016. 42 Copyright Notice 44 Copyright (c) 2015 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 (http://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 . . . . . . . . . . . . . . . . . . . 4 63 3.1. Sending a Hard Reset . . . . . . . . . . . . . . . . . . 4 64 3.2. Receiving a Hard Reset . . . . . . . . . . . . . . . . . 4 65 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. Rules for the Receiving Speaker . . . . . . . . . . . . . 5 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 For many classes of errors, the BGP protocol must send a NOTIFICATION 76 message and reset the peering session to handle the error condition. 77 The BGP Graceful Restart extension defined in [RFC4724] requires that 78 normal BGP procedures defined in [RFC4271] be followed when a 79 NOTIFICATION message is sent or received. This document defines an 80 extension to BGP Graceful Restart that permits the Graceful Restart 81 procedures to be performed when the BGP speaker receives a 82 NOTIFICATION message or the Hold Time expires. This permits the BGP 83 speaker to avoid flapping reachability and continue forwarding while 84 the BGP speaker restarts the session to handle errors detected in the 85 BGP protocol. 87 At a high level, this document can be summed up as follows. When a 88 BGP session is reset, both speakers operate as "Receiving Speakers" 89 according to [RFC4724], meaning they retain each other's routes. 90 This is also true for HOLDTIME expiration. The functionality can be 91 defeated using a "Hard Reset" subcode for the BGP NOTIFICATION Cease 92 Error code. If a Hard Reset is used, a full session reset is 93 performed. 95 1.1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 2. Modifications to BGP Graceful Restart Capability 103 The BGP Graceful Restart Capability is augmented to signal the 104 Graceful Restart support for BGP NOTIFICATION messages. In 105 particular, the Restart flags field and the Flags field for Address 106 Family are augmented as follows: 108 +--------------------------------------------------+ 109 | Restart Flags (4 bits) | 110 +--------------------------------------------------+ 111 | Restart Time in seconds (12 bits) | 112 +--------------------------------------------------+ 113 | Address Family Identifier (16 bits) | 114 +--------------------------------------------------+ 115 | Subsequent Address Family Identifier (8 bits) | 116 +--------------------------------------------------+ 117 | Flags for Address Family (8 bits) | 118 +--------------------------------------------------+ 119 | ... | 120 +--------------------------------------------------+ 121 | Address Family Identifier (16 bits) | 122 +--------------------------------------------------+ 123 | Subsequent Address Family Identifier (8 bits) | 124 +--------------------------------------------------+ 125 | Flags for Address Family (8 bits) | 126 +--------------------------------------------------+ 128 Restart Flags: 130 This field contains bit flags relating to restart. 132 0 1 2 3 133 +-+-+-+-+ 134 |R|N| | 135 +-+-+-+-+ 137 The second most significant bit ("N") is defined as the BGP Graceful 138 Notification bit, which is used to indicate Graceful Restart support 139 for BGP NOTIFICATION messages. A BGP speaker indicates support for 140 the procedures of this document, by advertising a Graceful Restart 141 Capability with its Graceful NOTIFICATION bit set (value 1). This 142 also implies support for the format for a BGP NOTIFICATION Cease 143 message defined in [RFC4486]. 145 Flags for Address Family: 147 This field contains bit flags relating to routes that were 148 advertised with the given AFI and SAFI. 150 0 1 2 3 4 5 6 7 151 +-+-+-+-+-+-+-+-+ 152 |F|N| Reserved | 153 +-+-+-+-+-+-+-+-+ 155 The usage of second most significant bit "N" (which was defined in a 156 previous draft version of this specification) is deprecated. This 157 bit MUST be advertised as 0 and MUST be ignored upon receipt. 159 3. BGP Hard Reset Subcode 161 A new BGP NOTIFICATION Cease message subcode is defined known as the 162 BGP Hard Reset Subcode. The value of this subcode is discussed in 163 Section 6. We refer to a BGP NOTIFICATION Cease message with the 164 Hard Reset subcode as a Hard Reset message, or just a Hard Reset. 166 3.1. Sending a Hard Reset 168 A Hard Reset message is used to indicate to a peer with which the 169 Graceful Notification flag has been exchanged, that the session is to 170 be fully terminated. 172 When sending a Hard Reset, the data portion of the NOTIFICATION is 173 encoded as follows: 175 +--------+--------+-------- 176 | ErrCode| Subcode| Data 177 +--------+--------+-------- 179 ErrCode is a BGP Error Code (as documented in the IANA BGP Error 180 Codes registry) that indicates the reason for the hard reset. 181 Subcode is a BGP Error Subcode (as documented in the IANA BGP Error 182 Subcodes registry) as appropriate for the ErrCode. Similarly, Data 183 is as appropriate for the ErrCode and Subcode. 185 3.2. Receiving a Hard Reset 187 Whenever a BGP speaker receives a Hard Reset, the speaker MUST 188 terminate the BGP session following the standard procedures in 189 [RFC4271]. 191 4. Operation 193 A BGP speaker that is willing to receive and send BGP NOTIFICATION 194 messages in Graceful mode MUST advertise the BGP Graceful 195 Notification "N" bit using the Graceful Restart Capability as defined 196 in [RFC4724]. 198 When such a BGP speaker has received the "N" bit from its peer, and 199 receives from that peer a BGP NOTIFICATION message other than a Hard 200 Reset, it MUST follow the rules for the Receiving Speaker mentioned 201 in Section 4.1. The BGP speaker generating the BGP NOTIFICATION 202 message MUST also follow the rules for the Receiving Speaker. 204 When a BGP speaker resets its session due to a HOLDTIME expiry, it 205 should generate the relevant BGP NOTIFICATION message as mentioned in 206 [RFC4271], but subsequently it MUST follow the rules for the 207 Receiving Speaker mentioned in Section 4.1. 209 A BGP speaker SHOULD NOT send a Hard Reset to a peer from which it 210 has not received the "N" bit. We note, however, that if it did so 211 the effect would be as desired in any case, since according to 212 [RFC4271] and [RFC4724] any NOTIFICATION message, whether recognized 213 or not, results in a session reset. Thus the only negative effect to 214 be expected from sending the Hard Reset to a peer that hasn't 215 advertised compliance to this specification would be that the peer 216 would be unable to properly log the associated information. 218 Once the session is re-established, both BGP speakers SHOULD set 219 their "Forwarding State" bit to 1. If the "Forwarding State" bit is 220 not set, then according to the procedures of [RFC4724] S. 4.2, the 221 relevant routes will be flushed, defeating the goals of this 222 specification. 224 4.1. Rules for the Receiving Speaker 226 [RFC4724] S. 4.2 defines rules for the Receiving Speaker. These are 227 modified as follows. 229 As part of this extension, routes from the peer previously marked as 230 stale MUST NOT be deleted, until and unless the timer mentioned in 231 the final paragraph of [RFC4724] S. 4.2 expires, or unless a Hard 232 Reset is performed. This supersedes the "consecutive restarts" 233 requirement of [RFC4724] S. 4.2. 235 In addition to the rules already specified in [RFC4724] S. 4.2 for 236 how variations in the received Graceful Restart Capability should be 237 interpreted (the paragraph that begins "Once the session is re- 238 established..."), if the Graceful Notification ("N") bit is not set 239 in the newly received Graceful Restart Capability, no new actions are 240 triggered on the Receiving Speaker -- in particular, a clear "N" bit 241 does not trigger deletion of stale routes. 243 Other than these modifications, the rules for the Receiving Speaker 244 are as specified in [RFC4724] S. 4.2. 246 5. Acknowledgements 248 The authors would like to thank Jim Uttaro for the suggestion, and 249 Bruno Decraene, Chris Hall, Paul Mattes and Robert Raszuk for their 250 review and comments. 252 6. IANA Considerations 254 IANA is requested to assign a new subcode in the "BGP Cease 255 NOTIFICATION message subcodes" registry. The suggested name for the 256 code point is "Hard Reset". The suggested value is 9. 258 7. Security Considerations 260 This extension to BGP does not change the underlying security issues 261 inherent in the existing [RFC4724] and [RFC4271]. 263 8. Normative References 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, 267 DOI 10.17487/RFC2119, March 1997, 268 . 270 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 271 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 272 DOI 10.17487/RFC4271, January 2006, 273 . 275 [RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease 276 Notification Message", RFC 4486, DOI 10.17487/RFC4486, 277 April 2006, . 279 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 280 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 281 DOI 10.17487/RFC4724, January 2007, 282 . 284 Authors' Addresses 286 Keyur Patel 287 Cisco Systems 288 170 W. Tasman Drive 289 San Jose, CA 95134 290 USA 292 Email: keyupate@cisco.com 294 Rex Fernando 295 Cisco Systems 296 170 W. Tasman Drive 297 San Jose, CA 95134 298 USA 300 Email: rex@cisco.com 302 John Scudder 303 Juniper Networks 304 1194 N. Mathilda Ave 305 Sunnyvale, CA 94089 306 USA 308 Email: jgs@juniper.net 310 Jeff Haas 311 Juniper Networks 312 1194 N. Mathilda Ave 313 Sunnyvale, CA 94089 314 USA 316 Email: jhaas@juniper.net