idnits 2.17.1 draft-ward-bgp4-ibb-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 455 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 19 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'BGP-CAP' on line 329 looks like a reference -- Missing reference section? 'BGP-4' on line 346 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force David Ward 2 Internet Draft Internet Engineering 3 Group, LLC 4 draft-ward-bgp4-ibb-00.txt 5 John Scudder 6 Internet Engineering 7 Group, LLC 8 June, 1999 10 BGP Notification Cease: I'll Be Back 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 1. Abstract 36 Many recent router architectures decouple the routing engine from 37 the forwarding engine, so that packet forwarding can continue even 38 if routing software is not active. The current definition of the 39 BGP protocol does not support this. We propose a new variety of 40 CEASE NOTIFICATION message (IBB) which indicates to a peer that the 41 router sending the notification expects to be able to continue 42 forwarding traffic for a certain period of time without an 43 established BGP peering session. We also propose a new OPEN 44 message (ICB) that if received during the HOLDTIME period, does not 45 require conventional reestablishment of the BGP peering session. 46 These capabilities are useful for orderly and non-intrusive routing 47 software updates, operating system updates, AS number migration, 48 redundancy and catastrophic event handling. 50 Ward, Scudder Internet Draft June 1999 page 1 52 June, 1999 54 2. Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 58 this document are to be interpreted as described in RFC-2119. 60 3.Introduction 62 Goals: 64 a. Continued forwarding in the absence of an Established BGP 65 peering session 66 b. Traffic shall continue to flow over the preferred path which 67 would be used if the BGP speaker had not closed the session 68 c. Routes will not be flapped. 70 Applications: 72 a. Support minimally intrusive upgrade of routing software, 73 operating system, hardware, etc. 74 b. Support minimally intrusive AS, IP, interface, etc. renumbering 75 c. Support minimally intrusive catastrophic software events 77 4. Operation 79 IBB introduces a new OPEN option, a new CEASE NOTIFICATION option, 80 and a new Capabilities Negotiation [BGP-CAP] option. 82 BGP operation is modified as follows: 84 4.1. Capability Negotiation 86 IBB must be negotiated at session startup time using Capability 87 Negotiation. (See Section 5 for discussion of why this is 88 necessary.) 90 The capability encoding for IBB is as follows: 92 Capability Code: TBD (1 octet) 93 Capability Length: 6 (1 octet) 94 Capability Value: 95 Flags: reserved, must be transmitted as zero (2 octets) 96 Maximum IBB timeout in seconds: (2 octets unsigned) 97 Maximum route refresh timeout in seconds: (2 octets 98 unsigned) 100 The IBB and route refresh timeouts specify the maximum timeout 101 values the BGP speaker is willing to accept. The maximum timeout 102 values are a matter of local configuration. 360 seconds is 103 suggested as a reasonable default value for both maxima. The 104 actual timeouts which will be used are based on the timeouts 105 proposed in the IBB CEASE and ICB OPEN; see below. 107 Ward, Scudder Internet Draft June 1999 page 2 109 June, 1999 111 4.2. Closing a Session With IBB CEASE 113 After IBB has been successfully negotiated, if a BGP speaker wants 114 to temporarily disconnect the session but is capable of continuing 115 to forward packets, it MAY close the session using a special CEASE 116 NOTIFICATION message called the _I'll be back_, or IBB CEASE. The 117 IBB CEASE adds the following option to the standard CEASE 118 NOTIFICATION message: 120 Error code = 6 (Cease) (one octet) 121 Error subcode = 1 (IBB) (one octet) 122 Flags = Reserved, must be sent as zero (two octets unsigned) 123 Data0 = IBB timeout in seconds (two octets unsigned) 124 Data1 = not used (two octets unsigned) 126 The semantics of the IBB CEASE are that the sender, 128 a. Will attempt to reestablish the session prior to the expiration 129 of the IBB timeout, and 130 b. Will be able to continue forwarding packets in the interim. 132 A BGP speaker MUST NOT send an IBB CEASE unless these criteria are 133 met. It MUST be possible for a router administrator to cause a BGP 134 session to be closed with a conventional CEASE instead of an IBB 135 CEASE. 137 When a BGP speaker has multiple IBGP peers to which it will send an 138 IBB CEASE, it MUST NOT set the IBB timeout as a value greater than 139 the minimum of all maximum IBB timeout values negotiated by the 140 IBGP peers. A BGP speaker MUST NOT send an IBB CEASE to any IBGP 141 peer unless all IBGP peers have successfully negotiated the IBB 142 option. (See Section 5 for discussion of why this is necessary, and 143 for a discussion of special considerations for route reflectors.) 145 The IBB timeout selected SHOULD NOT greatly exceed the time needed 146 for the BGP speaker to re-initiate its BGP connections; i.e. it has 147 the sense of a _reboot time._ It MUST NOT exceed the maximum value 148 established by the peer during capability negotiation. (There are 149 further restrictions for IBGP peers; see previous paragraph.) 151 Upon receiving the IBB CEASE, the connection to the peer which sent 152 the CEASE should be closed, just as with a normal CEASE. However, 153 in place of marking the routes from the peer as invalid, as 154 specified in section 6 of the BGP specification [BGP-4], the routes 155 are scheduled for later cleanup as follows: 157 a. Create a timer scheduled to expire at the lesser of the IBB 158 timeout received in the CEASE and the locally-configured 159 maximum. If the received IBB timeout exceeds the locally- 160 configured maximum, an error SHOULD be logged. 161 b. Mark the routes from the peer which sent the CEASE to be deleted 162 when the timer expires. 164 Ward, Scudder Internet Draft June 1999 page 3 166 June, 1999 168 c. If the IBB timeout expires, delete all marked routes 169 immediately. 170 d. If a new session is opened with the peer without the ICB option 171 (see below) being used, or if a session is attempted but fails 172 (i.e., an error is detected before the session enters 173 ESTABLISHED state) delete all marked routes immediately, and 174 cancel the timer. 176 4.3. Opening a Session With OPEN ICB 178 When a peer which sent an IBB CEASE wishes to establish a new 179 session, it must do so by negotiating IBB as specified in section 180 4.1, with the addition of the _I Came Back_ (or ICB) OPEN 181 parameter, which is encoded as follows: 183 Parm. Type: TBD (one octet) 184 Parm. Length: 3 (one octet) 185 Parm. Value: Route refresh timeout in seconds (two octets 186 unsigned) 187 Flags: Reserved, must be sent as zero (one octet unsigned) 189 An OPEN carrying the ICB parameter is known as an ICB OPEN. The 190 semantics of the ICB OPEN are that the sender, 192 a. Previously sent an IBB CEASE, or terminated the previous session 193 without sending a CEASE (e.g., due to a crash), 194 b. Has preserved the forwarding table it had prior to sending the 195 preceding IBB CEASE (the _old forwarding table_), and 196 c. Will not remove any NLRI from the old forwarding table prior to 197 the expiration of the route refresh timeout. (Note that it MAY 198 update the NLRI, however.) 200 A BGP speaker MUST NOT send an ICB OPEN unless these criteria are 201 met. A BGP speaker SHOULD NOT send an IBGP peer a route refresh 202 timeout value which exceeds the minimum of the previously- 203 negotiated route refresh timeouts for all IBGP peers. Note that 204 this MAY require writing route refresh timeout values to stable 205 storage as they are negotiated. (See Section 5 for discussion of 206 why this is advisable.) 208 The route refresh timeout value should be selected such that 209 routing will typically have reconverged prior to its expiration. 210 The exact means of selecting the value are implementation-specific, 211 but MAY include manual configuration or heuristics based on the 212 size of the Loc-RIB prior to session restart. 180 seconds MAY be 213 used as a reasonable default value. 215 When an ICB OPEN is received: 217 a. If there is a pending IBB timer, the timer is rescheduled to 218 expire at the lesser of the route refresh timeout and the 219 locally-configured maximum. 221 Ward, Scudder Internet Draft June 1999 page 4 223 June, 1999 225 b. If there is not a pending IBB timer, but there is already a 226 session in ESTABLISHED state with the peer from which the ICB 227 OPEN was received, and if that session had negotiated IBB, then 228 the ESTABLISHED session should be terminated immediately, as if 229 an IBB CEASE had been received. (The effect will be to create a 230 timer with a timeout value as given in (a), and to enqueue the 231 peer's routes on that timer.) This rule provides for, e.g., 232 non-intrusive transition from a primary to a backup route 233 processor in the event of the failure of the primary in a router 234 with redundant route processors. 236 If a BGP session is begun with a peer whose previous session 237 terminated with an IBB CEASE, if the new session does not begin 238 with an ICB OPEN, then the pending IBB timer should immediately be 239 expired, i.e. the peer's old routes should immediately be flushed. 240 Likewise, if a session is begun which terminates with an error 241 (i.e., a condition which causes the connection to be terminated 242 with a NOTIFICATION code other than CEASE) before reaching 243 ESTABLISHED state, the peer's old routes should be flushed. 245 Under normal circumstances, the connection to the peer should be 246 re-established in less than the IBB timeout period. When new 247 routes are received from the peer, they may either depict wholly 248 new NLRI (in which case they are added to the Adj-RIB-In as per the 249 BGP specification) or they may depict NLRI which are already 250 present in the Adj-RIB-In waiting on the deletion timer. In this 251 case, the marked route is replaced by the refreshing route. Such 252 routes are said to have been refreshed, and are no longer 253 candidates for deletion when the route refresh timer expires. 255 A _previous session_ as discussed in this section is defined as a 256 session with a BGP speaker whose IP address is the same as the IP 257 address of the new session. Note that router ID SHOULD NOT be used 258 to determine if a session is the _previous session_; this 259 facilitates using IBB to non-intrusively change the router ID of a 260 BGP speaker. 262 4.4. Route Reflectors 264 Note that it is only necessary that all direct IBGP peers of the 265 BGP speaker support IBB, not all IBGP speakers in the routing 266 domain if route reflection is in use. If route reflection is in 267 use, then if an IBB cease is sent to a reflector which implements 268 IBB, then the reflector simply won't propagate withdrawals until 269 the timeout period expires. 271 The reflector itself is a special case. It MAY send an IBB notify 272 to any subset of peers which all support IBB -- that is, if all the 273 reflector's clients support IBB, an IBB cease MAY be sent to all 274 the clients. If all the regular peers support IBB, an IBB cease 275 MAY be sent to those peers. 277 Ward, Scudder Internet Draft June 1999 page 5 279 June, 1999 281 5. Deployment 283 The IBB cease may be used with external BGP peers with impunity. 284 In the IBGP case, it's only safe to use IBB if all IBGP neighbors 285 of the BGP speaker understand the IBB cease. To understand why 286 this is the case, consider the following topology: 288 B 289 / \ 290 A D 291 \ / 292 C 294 The topology is fully IBGP meshed; the diagram shows physical 295 topology. 297 A injects prefix X with Localpref 200 298 B injects prefix X with Localpref 100 299 A and D support IBB 300 B and C do not 301 C's shortest path to B is through D. 302 D's shortest path to A is through C. 304 Suppose A sends a CEASE/IBB to B, C and D. D will retain A's route 305 to X, with a next hop of C. C, however, will remove A's route to 306 X, and will instead select B's route, with a next hop of D. A 307 routing loop ensues. 309 To avoid this situation, the IBB cease must not be sent to an IBGP 310 peer unless the capability has been negotiated (see BGP-CAP). The 311 same scenario holds true if different IBB timers are used for the 312 different peers. For this reason, this specification mandates that 313 the same IBB timer, which is known to be acceptable to all IBGP 314 peers, be used for all IBGP peers when sending IBB CEASEs. 316 A similar scenario holds true if different refresh timers are used 317 by the different peers _- consider the case where A does not 318 refresh prefix X, D has a refresh timer of 100 seconds, and C has a 319 refresh timer of 50 seconds. For this reason, this specification 320 suggests that the same refresh timer, which is known to be 321 acceptable to all IBGP peers, be used for all IBGP peers when 322 sending ICB OPENs. 324 6. References 326 [BGP-4] "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter and T. 327 Li, RFC1771, March 1995. 329 [BGP-CAP] "Capabilities Negotiation with BGP-4", R. Chandra and J. 330 Scudder, Internet Draft, April 1998. 332 7. Acknowledgements 334 Ward, Scudder Internet Draft June 1999 page 6 336 June, 1999 338 Many people have contributed valuable ideas to this draft. Enke 339 Chen, Yakov Rekhter, Paul Traina and Curtis Villamizer provided 340 particularly valuable comments. Special thanks are given to Wayne 341 Mesard of Sun Microsysytems, Inc. Thanks to Matthew C. Jones and 342 Ralph Jensen for their review comments. 344 8. Security Considerations 346 This extension to BGP has the same security considerations as [BGP- 347 4]. 349 9. Author's Addresses 351 David Ward 352 Internet Engineering Group, LLC 353 122 South Main Street, Suite 280 354 Ann Arbor, MI 48104 355 dward@ieng.com 357 John Scudder 358 Internet Engineering Group, LLC 359 122 South Main Street, Suite 280 360 Ann Arbor, MI 48104 361 jgs@ieng.com 363 Ward, Scudder Internet Draft June 1999 page 7 365 June, 1999 367 Full Copyright Statement 369 "Copyright (C) The Internet Society (date). All Rights Reserved. 370 This document and translations of it may be copied and furnished to 371 others, and derivative works that comment on or otherwise explain 372 it or assist in its implementation may be prepared, copied, 373 published and distributed, in whole or in part, without restriction 374 of any kind, provided that the above copyright notice and this 375 paragraph are included on all such copies and derivative works. 376 However, this document itself may not be modified in any way, such 377 as by removing the copyright notice or references to the Internet 378 Society or other Internet organizations, except as needed for the 379 purpose of developing Internet standards in which case the 380 procedures for copyrights defined in the Internet Standards process 381 must be followed, or as required to translate it into languages 382 other than English. 384 The limited permissions granted above are perpetual and will not be 385 revoked by the Internet Society or its successors or assigns. 387 This document and the information contained herein is provided on 388 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 389 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 390 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 391 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 392 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 394 Ward, Scudder Internet Draft June 1999 page 8