idnits 2.17.1 draft-scudder-bgp-multisession-00.txt: 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([MP-BGP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 74: '... Routers implementing this specification MUST also implement [MP-BGP]....' RFC 2119 keyword, line 129: '...ed AFI/SAFI code MAY be used when an O...' RFC 2119 keyword, line 135: '...ng Conflict code MAY be used when an O...' RFC 2119 keyword, line 138: '... SHOULD indicate one of the conflict...' RFC 2119 keyword, line 141: '...ng Required code MAY be used when a BG...' (22 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 2003) is 7461 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) == Missing Reference: 'BGP' is mentioned on line 300, but not defined == Missing Reference: 'Event 12' is mentioned on line 341, but not defined == Missing Reference: 'Event 19' is mentioned on line 349, but not defined == Unused Reference: 'BGP4' is defined on line 384, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. 'BGP4') (Obsoleted by RFC 4271) == Outdated reference: A later version (-26) exists of draft-ietf-idr-bgp4-20 == Outdated reference: A later version (-10) exists of draft-ietf-idr-rfc2858bis-03 == Outdated reference: A later version (-13) exists of draft-ietf-idr-restart-06 ** Obsolete normative reference: RFC 2842 (ref. 'BGP-CAP') (Obsoleted by RFC 3392) == Outdated reference: A later version (-16) exists of draft-ietf-idr-dynamic-cap-03 Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group John G. Scudder 3 Internet Draft Chandra Appanna 4 Expiration Date: May 2004 Cisco Systems 5 File name: draft-scudder-bgp-multisession-00.txt November 2003 7 Multisession BGP 8 draft-scudder-bgp-multisession-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Abstract 33 This specification augments "Multiprotocol Extensions for BGP-4" [MP- 34 BGP] by proposing a mechanism to allow multiple sessions to be used 35 between a given pair of BGP speakers. Each session is used to 36 transport routes for one or more AFI/SAFI. This provides an 37 alternative to the current [MP-BGP] approach of multiplexing routes 38 for all AFI/SAFI onto a single connection. 40 Use of this approach is expected to increase the robustness of the 41 BGP protocol as it is used to support more and more diverse AFI/SAFI. 43 1. Introduction 45 Most BGP [BGP, BGP-DRAFT] implementations only permit a single 46 ESTABLISHED connection to exist with each peer. More precisely, they 47 only permit a single ESTABLISHED connection for any given pair of IP 48 endpoints. 50 Multiprotocol BGP [MP-BGP] extends BGP to allow information for 51 multiple NLRI families and sub-families to be transported in BGP. 52 Routes for different families are distinguished by AFI and SAFI. 53 Routes for different families are commonly multiplexed onto a single 54 BGP session. 56 A common criticism of BGP is the fact that most malformed messages 57 cause the session to be terminated. While this behavior is necessary 58 for protocol correctness, one may observe that the protocol machinery 59 of a given implementation may only be defective with respect to a 60 given AFI/SAFI. Thus, it would be desirable to allow the session 61 related to that family to be terminated while leaving other AFI/SAFI 62 unaffected. As BGP is commonly deployed, this is not possible. 64 In this specification, we propose a mechanism by which multiple 65 transport sessions may be established between a pair of peers. Each 66 transport session can be used for one or more AFI/SAFI. Each session 67 is distinct from a BGP protocol point of view; an error or other 68 event on one session has no implications for any other session. All 69 protocol modifications proposed by this specification take place 70 during the OPEN exchange phase of the session, there are no 71 modifications to the operation of the protocol once a session reaches 72 ESTABLISHED state. 74 Routers implementing this specification MUST also implement [MP-BGP]. 76 2. Definitions 78 "MP-BGP capability" refers to the capability [BGP-CAP] with code 1, 79 specified in [MP-BGP] section 10. 81 A BGP speaker is said to "support" some feature or functionality (for 82 example, to support this specification, or to support a particular 83 AFI/SAFI) when the BGP implementation supports the feature AND the 84 feature has not been disabled by configuration. 86 A pair of AFI/SAFI groups is said to "conflict" when considering the 87 two groups as two sets, there is an intersection between the groups 88 but neither group is a subset of the other. 90 3. Use of BGP Capability Advertisement 92 This specification defines the Multisession capability [BGP-CAP]: 94 Capability code (1 octet): TBD 96 Capability length (1 octet): 1 98 Capability value (1 octet): Flags as below 100 0 1 2 3 4 5 6 7 101 +-+-+-+-+-+-+-+-+ 102 |G| Reserved | 103 +-+-+-+-+-+-+-+-+ 105 The most significant bit is defined as the Grouping Support (G) bit. 106 It can be used to indicate support for the ability to group multiple 107 AFI/SAFI into one session. When set (value 1) this bit indicates 108 that the BGP speaker supports grouping. 110 The remaining bits are reserved, and should be set to zero by the 111 sender and ignored by the receiver. 113 4. New NOTIFICATION Subcodes 115 [BGP, BGP-DRAFT] Section 4.5 provides a number of subcodes to the 116 NOTIFICATION message, and Section 6.2 elaborates on the use of those 117 subcodes. 119 This specification introduces two new subcodes: 121 OPEN Message Error subcodes: 123 7 - No Supported AFI/SAFI. 125 8 - Grouping Conflict 127 9 - Grouping Required 129 The No Supported AFI/SAFI code MAY be used when an OPEN message 130 contains one or more MP-BGP capabilities, none of which list an 131 AFI/SAFI supported by the local BGP speaker. It is observed that 132 this subcode may be useful for MP-BGP speakers in general, even if 133 they do not (otherwise) implement this specification. 135 The Grouping Conflict code MAY be used when an OPEN message contains 136 several MP-BGP capabilities whose AFI/SAFI conflict with one or more 137 AFI/SAFI groups configured on the local BGP speaker. The Data field 138 SHOULD indicate one of the conflicting locally-configured AFI/SAFI 139 groups, encoded as MP-BGP capabilities. 141 The Grouping Required code MAY be used when a BGP speaker which is 142 configured to require grouping attempts to establish a connection 143 with a BGP speaker which does not support grouping. (While it is 144 true that it might be possible to communicate much the same 145 information using the Unsupported Capability NOTIFICATION message, 146 this more explicit method is felt to be more transparent.) 148 The use of these subcodes is further elaborated below. 150 5. Overview of Operation 152 Until a BGP speaker has initiated or accepted one connection from a 153 given peer, it is unknown whether the peer supports this 154 specification or not. Two strategies can be considered for making 155 this initial determination -- either the BGP speaker can initially 156 assume that the peer does not support this specification, and switch 157 modes if it is discovered that it does, or vice-versa. Either 158 approach is acceptable. 160 The "Using Multisession" sections below discuss the BGP speaker's 161 behavior when the peer does support this specification or is assumed 162 to. The "Backward Compatibility" section discusses the BGP speaker's 163 behavior when the peer does not support this specification, or is 164 assumed not to. Both sections discuss how to switch to the other 165 mode. 167 A BGP speaker which supports this specification SHOULD always 168 advertise the Multisession capability, regardless of its peer's known 169 or presumed capability set. 171 5.1. Using Multisession: 173 The following subsections discuss a BGP speaker's behavior towards a 174 peer which is known or assumed to support this specification. 176 Note that if a BGP speaker only wishes to support a single AFI/SAFI 177 in its communications with a given peer only one session is needed in 178 any case, and so the "multisession" feature is moot. In such a case 179 the behavior required would be indistinguishable from that given in 180 the "backward compatibility" section below. In the following 181 sections, it is generally assumed that a BGP speaker does wish to 182 support multiple AFI/SAFI in its communications with a given peer. 184 5.1.1. Initiating Connections: 186 When a BGP speaker attempts BGP communication with its peer, it 187 initiates one connection per group of AFI/SAFI it wishes to support. 188 (This implies that a new local TCP port will be allocated for each 189 new connection.) The OPEN sent on each connection MUST include the 190 Multisession capability and one or more MP-BGP capabilities 191 indicating the AFI/SAFI to be supported on that session. If a non- 192 trivial group of AFI/SAFI (i.e., a group of two or more) is proposed, 193 the BGP speaker MUST also set the G bit of the Multisession 194 capability. Even if a trivial group of AFI/SAFI is proposed, the G 195 bit SHOULD be set if grouping is supported. 197 Note that any "group of AFI/SAFI" may be a singleton group, i.e. the 198 speaker may wish to use a separate BGP connection for each AFI/SAFI. 200 If the peer also supports this specification and also wishes to 201 support the AFI/SAFI in question, it will respond with an OPEN which 202 includes the Multisession capability and the AFI/SAFI included in the 203 active speaker's OPEN. If the active speaker's OPEN included a non- 204 trivial group of AFI/SAFI which the peer supports, then the peer's 205 Multisession capability will have the G bit set. 207 If the peer also supports this specification and wishes to support 208 some but not all of the AFI/SAFI in question, it will respond with an 209 OPEN which includes the Multisession capability and a subset of 210 AFI/SAFI included in the active speaker's OPEN. The reason for 211 listing only a subset may be because some of the AFI/SAFI are simply 212 not supported, or because the peer does not wish to support the 213 AFI/SAFI as a group (i.e. it may be configured to use a smaller 214 group). In this case, the BGP speaker MAY consider the set of 215 AFI/SAFI which were not included in the peer's OPEN to form a new 216 group, and MAY try to initiate a new session using that group. 218 If the peer also supports this specification but does not support 219 grouping, and a non-trivial group of AFI/SAFI has been proposed, then 220 it will respond as given in the previous paragraph but with the 221 additional proviso that the G bit will be clear. In this case, the 222 BGP speaker MAY accept the connection as given in the previous 223 paragraph, or it MAY reply with a NOTIFICATION message with ERROR 224 Code OPEN Message Error and Error Subcode Grouping Required, and the 225 connection will be closed. 227 If the peer does not wish to support the AFI/SAFI in question, it 228 will reply with a NOTIFICATION message with Error Code OPEN Message 229 Error, and Error Subcode No Supported AFI/SAFI, and the connection 230 will be closed. 232 A BGP speaker SHOULD NOT attempt to initiate connections for any 233 AFI/SAFI for which a connection already exists. 235 If the peer does not support this specification, it will respond with 236 an OPEN which does not include the Multisession capability. In this 237 case the connection SHOULD be terminated, and future connections to 238 the peer should be attempted in the "backward compatibility" mode 239 discussed below. 241 5.1.2. Accepting Connections: 243 When processing a connection attempt, the BGP speaker MUST wait until 244 the peer's OPEN message has been received before proceeding. This is 245 at variance with the behavior specified in the finite state machine 246 (FSM) of [BGP-DRAFT], but is interoperable with that FSM. The FSM 247 changes are specified in a later section. 249 Once the peer's OPEN message has been received, if it includes the 250 Multisession capability and one or more MP-BGP capabilities 251 indicating a group of AFI/SAFI which the BGP speaker wishes to 252 support, then the BGP speaker responds with an OPEN message which 253 includes the Multisession capability and one or more MP-BGP 254 capabilities indicating the same AFI/SAFI. 256 If the OPEN includes the Multisession capability and one or more MP- 257 BGP capabilities indicating a group of AFI/SAFI which conflicts with 258 an AFI/SAFI grouping that has been configured on the BGP speaker then 259 the BGP speaker MAY reply with an OPEN listing a set of AFI/SAFI 260 which intersect with those proposed by the peer (in effect overriding 261 the locally configured set) or it MAY close the connection with a 262 NOTIFICATION message with Error Code OPEN Message Error and Error 263 Subcode Grouping Conflict. The former behavior is suggested as the 264 default if grouping is supported. 266 If the BGP speaker does not support AFI/SAFI grouping it MAY reply 267 with an OPEN listing one of the AFI/SAFI out of those proposed by the 268 peer. It SHOULD also set the G bit in the Multisession capability to 269 zero. 271 If the received OPEN message does not include any MP-BGP capability 272 indicating an AFI/SAFI the BGP speaker wishes to support, it should 273 close the connection with a NOTIFICATION message with Error Code OPEN 274 Message Error and Error Subcode No Supported AFI/SAFI. 276 If the received OPEN message does not include the Multisession 277 capability, then the peer does not support this specification. The 278 connection MAY be continued in the "backward compatibility" mode 279 discussed below, or it MAY be terminated and future connections to 280 the peer attempted in the "backward compatibility" mode. 282 5.1.3. Collision Detection, Graceful Restart: 284 [BGP, BGP-DRAFT] Section 6.8 (BGP connection collision detection) 285 considers a pair of connections to have collided if the source and 286 destination IP addresses of both connections match. With respect to 287 peers which support this specification, the AFI/SAFI groups 288 associated with the connections must also intersect for them to be 289 considered to have collided. 291 This consideration also applies to Section 6.2 of [BGP-GR], when 292 determining whether a new connection should be considered equivalent 293 to a reset of a previous TCP session. 295 5.2. Backward Compatibility: 297 This subsection discusses a BGP speaker's behavior towards a peer 298 which is known or assumed not to support this specification. In 299 short, the BGP speaker's behavior towards such a peer should be as 300 otherwise defined for the BGP protocol, according to [BGP, BGP-DRAFT] 301 and any other extension supported by the BGP speaker. 303 As previously mentioned, the BGP speaker SHOULD always advertise the 304 Multisession capability in its OPEN message, even towards "backward 305 compatibility" peers. 307 If, in opening a BGP connection with such a peer, an OPEN which 308 includes the Multisession capability is received from the peer, then 309 the peer SHOULD be changed to "multisession" mode. How this is done 310 depends on whether the BGP speaker has already sent an OPEN or not -- 312 If the BGP speaker has not yet sent an OPEN to the peer, then the 313 connection MAY be continued in the "multisession" mode discussed 314 above, or it MAY be terminated and future connections to the peer 315 attempted in "multisession" mode. 317 If the BGP speaker has sent an OPEN to the peer, then the current 318 session SHOULD be terminated and future connections to the peer 319 attempted in "multisession" mode. 321 Use of techniques such as [BGP-DYN-CAP] for on-the-fly switching of 322 session modes are beyond the scope of this document. 324 6. State Machine 326 As mentioned under "accepting connections" above, this specification 327 modifies the BGP finite state machine, albeit in a backward- 328 compatible fashion. 330 In addition, note that one state machine is considered to exist for 331 each of the connections which may exist to a given peer. This 332 implies that, for example, any session flap dampening that may exist 333 is performed per AFI/SAFI. 335 The specific state machine modifications to [BGP-DRAFT] Section 8.2.2 336 are as follows. 338 6.1. Modifications to Connect State and Active State 340 In the actions in response to the events Open Delay timer expires 341 [Event 12] and TCP connection succeeds [Event 16 or Event 17], an 342 OPEN is not sent and the state changes to WaitForOpen and not to 343 OpenSent. 345 6.2. Addition of WaitForOpen State, Deletion of OpenSent State 347 The WaitForOpen state is the same in all respects to OpenSent, except 348 for the action in response to reception of a valid OPEN message 349 [Event 19]. In that event, the local system sends an OPEN message 350 prior to sending a KEEPALIVE message. 352 The OpenSent state is deleted. All references to OpenSent are 353 replaced by references to WaitForOpen. 355 7. Discussion 357 Note that many BGP implementations already permit multiple sessions 358 to be used between a given pair of routers, typically by configuring 359 multiple IP addresses on each router and configuring each session to 360 be bound to a different IP address. The principal contribution of 361 this specification is to allow multiple sessions to be created 362 automatically, without additional configuration overhead or address 363 consumption. 365 In addition to the simple mode of supporting one AFI/SAFI per 366 connection, the procedures described here also permit arbitrary 367 grouping of AFI/SAFI onto BGP connections. For such grouping to 368 function pleasingly, both peers participating in a connection need to 369 agree on what AFI/SAFI groupings will be used. If conflicting 370 groupings are configured, the connections may not establish, or more 371 connections may be established than were expected (in the degenerate 372 case, one connection per AFI/SAFI could be established despite 373 configured groupings). We observe that the potential for misbehavior 374 in the presence of conflicting configuration is not unusual in BGP, 375 and that support for, and configuration of grouping is purely 376 optional. 378 8. Acknowledgements 380 To be supplied. 382 9. References 384 [BGP4] 385 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)," RFC 386 1771, March 1995. 388 [BGP-DRAFT] 389 Rekhter, Y., T. Li and S. Hares, "A Border Gateway Protocol 4 390 (BGP-4)," Work in Progress (draft-ietf-idr-bgp4-20), April 2003. 392 [MP-BGP] 393 Bates, T., R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol Exten- 394 sions for BGP-4," Work in Progress (draft-ietf-idr-rfc2858bis-03), 395 July 2003. 397 [BGP-GR] 398 Sangli, S., Y. Rekhter, R. Fernando, J. Scudder, E. Chen, "Graceful 399 Restart Mechanism for BGP," Work in Progress (draft-ietf-idr- 400 restart-06), January 2003. 402 [BGP-CAP] 403 Chandra, R., J. Scudder, "Capabilities Advertisement with BGP-4," 404 RFC 2842, May 2000. 406 [BGP-DYN-CAP] 407 Chen, E. and S. Sangli, "Dynamic Capability for BGP-4," Work in 408 Progress (draft-ietf-idr-dynamic-cap-03), December 2002. 410 10. Security Considerations 412 This document introduces no new security vulnerabilities to BGP or 413 other specifications referenced in this document. 415 11. IANA Considerations 417 TBD 419 12. Authors' Addresses 421 John G. Scudder 422 Cisco Systems, Inc. 423 100 S. Main Suite 200 424 Ann Arbor, MI 48104 425 Email: jgs@cisco.com 427 Chandra Appanna 428 Cisco Systems, Inc. 429 170 West Tasman Drive 430 San Jose, CA 95134 431 e-mail: achandra@cisco.com 433 13. Full Copyright Statement 435 Copyright (C) The Internet Society (2003). All Rights Reserved. 437 This document and translations of it may be copied and furnished to 438 others, and derivative works that comment on or otherwise explain it 439 or assist in its implementation may be prepared, copied, published 440 and distributed, in whole or in part, without restriction of any 441 kind, provided that the above copyright notice and this paragraph are 442 included on all such copies and derivative works. However, this doc- 443 ument itself may not be modified in any way, such as by removing the 444 copyright notice or references to the Internet Society or other 445 Internet organizations, except as needed for the purpose of develop- 446 ing Internet standards in which case the procedures for copyrights 447 defined in the Internet Standards process must be followed, or as 448 required to translate it into languages other than English. 450 The limited permissions granted above are perpetual and will not be 451 revoked by the Internet Society or its successors or assigns. 453 This document and the information contained herein is provided on an 454 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 455 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 456 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 457 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 458 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.