idnits 2.17.1 draft-ietf-idr-bgp-multisession-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2009) is 5401 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: 'Event 12' is mentioned on line 562, but not defined == Missing Reference: 'Event 19' is mentioned on line 570, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-idr-dynamic-cap-09 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Scudder 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track C. Appanna 5 Expires: January 13, 2010 Cisco Systems 6 July 12, 2009 8 Multisession BGP 9 draft-ietf-idr-bgp-multisession-04 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on January 13, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This specification augments "Multiprotocol Extensions for BGP-4" (MP- 58 BGP) by proposing a mechanism to facilitate the use of multiple 59 sessions between a given pair of BGP speakers. Each session is used 60 to transport routes related by some session-based attribute such as 61 AFI/SAFI. This provides an alternative to the MP-BGP approach of 62 multiplexing all routes onto a single connection. 64 Use of this approach is expected to provide finer-grained fault 65 management and isolation as the BGP protocol is used to support more 66 and more diverse services. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 72 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Use of BGP Capability Advertisement . . . . . . . . . . . . . 6 74 4. New NOTIFICATION Subcodes . . . . . . . . . . . . . . . . . . 7 75 5. Overview of Operation . . . . . . . . . . . . . . . . . . . . 8 76 5.1. Using Multisession . . . . . . . . . . . . . . . . . . . . 9 77 5.1.1. Initiating Connections . . . . . . . . . . . . . . . . 9 78 5.1.1.1. Continuing a Redirected Connection . . . . . . . . 11 79 5.1.2. Accepting Connections . . . . . . . . . . . . . . . . 11 80 5.1.3. Collision Detection, Graceful Restart . . . . . . . . 12 81 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 12 82 7. State Machine . . . . . . . . . . . . . . . . . . . . . . . . 13 83 7.1. Modifications to Connect State and Active State . . . . . 13 84 7.2. Addition of WaitForOpen State, Deletion of OpenSent 85 State . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 89 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 92 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 95 1. Introduction 97 Most BGP [RFC4271] implementations only permit a single ESTABLISHED 98 connection to exist with each peer. More precisely, they only permit 99 a single ESTABLISHED connection for any given pair of IP endpoints. 101 BGP Capabilities [RFC5492] extend BGP to allow diverse information 102 (encoded as "capabilities") to be associated with a session. In some 103 cases, a capability may relate to the operation of the protocol 104 machinery; an example is Route Refresh [RFC2918]. However, in other 105 cases a capability may relate specifically to some common 106 distinguishing characteristic of the routes carried over the session; 107 an example is Multiprotocol BGP [RFC4760]. 109 Multiprotocol BGP [RFC4760] extends BGP to allow information for 110 multiple NLRI families and sub-families to be transported in BGP. 111 Routes for different families are distinguished by AFI and SAFI. 112 Routes for different families are commonly multiplexed onto a single 113 BGP session. 115 A common criticism of BGP is the fact that most malformed messages 116 cause the session to be terminated. While this behavior is necessary 117 for protocol correctness, one may observe that the protocol machinery 118 of a given implementation may only be defective with respect to a 119 given AFI/SAFI. Thus, it would be desirable to allow the session 120 related to that family to be terminated while leaving other AFI/SAFI 121 unaffected. As BGP is commonly deployed, this is not possible. 123 A second criticism of BGP is that it is difficult or in some cases 124 impossible to manage control plane resource contention when BGP is 125 used to support diverse services over a single session. In contrast, 126 if a single BGP session carries only information for a single service 127 (or related set of services) it may be easier to manage such 128 contention. 130 In this specification, we propose a mechanism by which multiple 131 transport sessions may be established between a pair of peers. Each 132 transport session is identified by a distinct set of BGP 133 capabilities, notably the MP-BGP capability. 135 Each session is distinct from a BGP protocol point of view; an error 136 or other event on one session has no implications for any other 137 session. All protocol modifications proposed by this specification 138 take place during the OPEN exchange phase of the session, there are 139 no modifications to the operation of the protocol once a session 140 reaches ESTABLISHED state. 142 Although AFI/SAFI is perhaps the most obvious way to group sets of 143 routes being exchanged between BGP peers, sessions can also be 144 distinguished by other BGP capabilities. In general, any capability 145 used in this fashion would be expected to have semantics of 146 identifying some common distinguishing characteristic of a set of 147 routes, just as AFI/SAFI does; however, specifics are beyond the 148 scope of this document. For the sake of clarity, we generally use 149 the MP-BGP capability (or interchangeably, AFI/SAFI) in this 150 document. Such use is illustrative and is not intended to be 151 limiting. 153 Routers implementing this specification MUST also implement the base 154 criteria that is used to define sessions. For example if AFI/SAFI 155 based sessions are desired then routers implementing this 156 specification MUST also implement MP-BGP [RFC4760]. 158 1.1. Requirements Language 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119 [RFC2119]. 164 2. Definitions 166 "MP-BGP capability" refers to the capability [RFC5492] with code 1, 167 specified in MP-BGP [RFC4760] section 8. 169 A BGP speaker is said to "support" some feature or functionality (for 170 example, to support this specification, or to support a particular 171 AFI/SAFI) when the BGP implementation supports the feature AND the 172 feature has not been disabled by configuration. 174 The Session Identifier is a capability or group of capabilities that 175 will be used to differentiate individual BGP sessions between two IP 176 endpoints. When the AFI/SAFI is used to distinguish sessions, the 177 MP-BGP capability is the session identifier. 179 A pair of session identifiers are said to conflict when considering 180 them as two sets, there is an intersection between them either in the 181 capabilities or the values contained within the capabilities, but 182 neither is a subset of the other. For example, a pair of MP-BGP 183 capabilities is said to "conflict" when considering them as two sets 184 (of AFI/SAFI values), there is an intersection between the sets but 185 neither set is a subset of the other. 187 A BGP speaker is said to be the "active" speaker for a given 188 connection if it was the party that initiated the transport open. 189 The active speaker's transport endpoint will typically use an 190 ephemeral port number. 192 A BGP speaker is said to be the "passive" speaker for a given 193 connection if it was the party that received the transport open. The 194 passive speaker's transport endpoint typically uses the well-known 195 BGP port number, 179, but this document introduces an exception 196 detailed in Section 5.1.1.1. 198 3. Use of BGP Capability Advertisement 200 This specification defines the Multisession capability [RFC5492]: 202 Capability code (1 octet): 68 204 Capability length (1 octet): variable 206 Capability value (1 octet): Flags followed by the list of 207 capabilities that define a session. 209 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 210 +-+-+-+-+-+-+-+-+ 211 |G|R| Reserved | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Port number (if R is set) | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | One or more Capability codes (1 octet each) | 216 ~ ~ 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 The most significant bit is defined as the Grouping Support (G) bit. 220 It can be used to indicate support for the ability to group multiple 221 capability values into one session. When set (value 1) this bit 222 indicates that the BGP speaker supports grouping. An example of 223 grouping is if a BGP speaker wishes to use one session for AFI/SAFI 224 values 1/1, 1/2 and 1/4, and another for AFI/SAFI values 2/1, 2/2 and 225 2/4. 227 The next bit is defined as the Redirect (R) bit. When set, it 228 indicates that the sender wishes to continue the current BGP session 229 using a different transport endpoint. This entails the active 230 speaker dropping the current session and starting a fresh one using 231 the proposed endpoint; this is detailed in Section 5.1.1.1 below. 232 When set, the transport endpoint information is encoded in the port 233 number field of the capability as detailed below. 235 The remaining bits are reserved, and should be set to zero by the 236 sender and ignored by the receiver. 238 If the R bit is set, following the reserved bits is the two-octet TCP 239 port number to which the passive speaker wishes to redirect the 240 session. 242 Following the reserved bits and the transport endpoint information if 243 present is a list of one or more Capability codes defined in BGP. 244 The size of the list is inferred from the length of the overall 245 capability; it is the capability length minus one if the R bit is not 246 set, or minus three if the R bit is set. The capabilities listed 247 specify which capabilities in the OPEN message comprise the session 248 identifier. The Multisession capability code itself MUST NOT be 249 listed; if listed it MUST be ignored upon receipt. 251 For example, peers wishing to establish sessions based on AFI/SAFI 252 would exchange the Multiprotocol Extensions capability code (1) only 253 in the list. In this case the Multisession capability would have a 254 length of two octets, or four octets if redirect is being requested. 256 4. New NOTIFICATION Subcodes 258 BGP [RFC4271] Section 4.5 provides a number of subcodes to the 259 NOTIFICATION message, and Section 6.2 elaborates on the use of those 260 subcodes. 262 This specification introduces five new subcodes: 264 OPEN Message Error subcodes: 266 7 - Capability Value Mismatch 268 8 - Grouping Conflict 270 9 - Grouping Required 272 10 - Redirecting Now 274 11 - Redirect Required 276 The Capability Value Mismatch code MAY be used when an OPEN message 277 received contains one or more capabilities whose values are 278 inconsistent with the corresponding capabilities of the local BGP 279 speaker. The Data field MUST list the offending capability code(s). 281 The Grouping Conflict code MAY be used when an OPEN message contains 282 one or more capabilities whose values conflict with the values of one 283 or more capability groups configured on the local BGP speaker. The 284 Data field MUST indicate one of the conflicting locally-configured 285 capability group, encoded as the appropriate capabilities. 287 The Grouping Required code MAY be used when a BGP speaker that is 288 configured to require grouping attempts to establish a connection 289 with a BGP speaker that does not support grouping. (While it is true 290 that it might be possible to communicate much the same information 291 using the Unsupported Capability NOTIFICATION message, this more 292 explicit method is felt to be more transparent.) 294 If the MP-BGP capability is used as the session identifier, the 295 notifications could be used as follows: 297 Capability Value Mismatch MAY be used when an OPEN message contains 298 one or more MP-BGP capabilities, none of which lists an AFI/SAFI 299 supported by the local BGP speaker. It is observed that this subcode 300 may be useful for MP-BGP speakers in general, even if they do not 301 (otherwise) implement this specification. 303 The Grouping Conflict code MAY be used when an OPEN message contains 304 several MP-BGP capabilities whose AFI/SAFI conflict with one or more 305 AFI/SAFI groups configured on the local BGP speaker. The Data field 306 MUST indicate one of the conflicting locally-configured AFI/SAFI 307 groups, encoded as MP-BGP capabilities. (One might think of this as 308 indicating "I'm not willing to combine AFI/SAFI foo and bar as you've 309 tried to do.") 311 Use of the Redirecting Now and Redirect Required codes is detailed in 312 Section 5.1.1.1. 314 The use of these subcodes is further elaborated below. 316 5. Overview of Operation 318 The operation section is divided into two main subsections. 320 The "Using Multisession" sections below discuss the BGP speaker's 321 behavior when the peer does support this specification or is assumed 322 to. The "Backward Compatibility" section discusses the BGP speaker's 323 behavior when the peer does not support this specification, or is 324 assumed not to. Both sections also discuss how to switch to the 325 other mode. 327 A BGP speaker that supports this specification MUST always advertise 328 the Multisession capability, regardless of its peer's known or 329 presumed capability set. 331 In all cases until a BGP speaker has initiated or accepted one 332 connection from a given peer, it is unknown whether the peer supports 333 this specification or not. Two strategies can be considered for 334 making this initial determination -- either the BGP speaker can 335 initially assume that the peer does not support this specification, 336 and switch modes if it is discovered that it does, or vice-versa. 337 Either approach is acceptable. 339 As discussed previously, this section describes the operation from 340 the point of view of the MP-BGP capability and the associated AFI/ 341 SAFI values as the session identifier. It can be replaced with any 342 other capability or groups of capabilities without any changes to the 343 behavior described below. 345 Note that if a BGP speaker only wishes to support a single AFI/SAFI 346 in its communications with a given peer only one session is needed in 347 any case, and so the "multisession" feature is moot. In such a case 348 the behavior required would be indistinguishable from that given in 349 the "backward compatibility" section below. In the illustrative 350 examples in the following sections, it is generally assumed that a 351 BGP speaker does wish to support multiple AFI/SAFI in its 352 communications with a given peer. 354 5.1. Using Multisession 356 The following subsections discuss a BGP speaker's behavior towards a 357 peer that is known or assumed to support this specification. 359 5.1.1. Initiating Connections 361 When a BGP speaker (the "active" speaker) attempts BGP communication 362 with its peer (the "passive" speaker), it initiates one connection 363 per group of AFI/SAFI it wishes to support. (This implies that a new 364 local TCP port will be allocated for each new connection.) The OPEN 365 sent on each connection MUST include the Multisession capability and 366 one or more MP-BGP capabilities indicating the AFI/SAFI to be 367 supported on that session. If a non-trivial group of AFI/SAFI (i.e., 368 a group of two or more) is proposed, the BGP speaker MUST also set 369 the G bit of the Multisession capability. Even if a trivial group of 370 AFI/SAFI is proposed, the G bit SHOULD be set if grouping is 371 supported. The active speaker MUST NOT set the R bit nor include an 372 associated TCP port number. 374 Note that any "group of AFI/SAFI" may be a singleton group, i.e. the 375 speaker may wish to use a separate BGP connection for each AFI/SAFI. 377 If the peer also supports this specification and also wishes to 378 support the AFI/SAFI in question, it will respond with an OPEN that 379 includes the Multisession capability and the AFI/SAFI included in the 380 active speaker's OPEN. If the active speaker's OPEN included a non- 381 trivial group of AFI/SAFI that the peer supports, then the peer's 382 Multisession capability will have the G bit set. 384 If the peer also supports this specification and wishes to support 385 some but not all of the AFI/SAFI in question, it will respond with an 386 OPEN that includes the Multisession capability and a subset of AFI/ 387 SAFI included in the active speaker's OPEN. The reason for listing 388 only a subset may be because some of the AFI/SAFI are simply not 389 supported, or because the peer does not wish to support the AFI/SAFI 390 as a group (i.e. it may be configured to use a smaller group). In 391 this case, the BGP speaker MAY consider the set of AFI/SAFI that were 392 not included in the peer's OPEN to form a new group, and MAY try to 393 initiate a new session using that group. 395 If the peer also supports this specification but does not support 396 grouping, and a non-trivial group of AFI/SAFI has been proposed, then 397 it will respond as given in the previous paragraph but with the 398 additional proviso that the G bit will be clear. In this case, the 399 BGP speaker MAY accept the connection as given in the previous 400 paragraph, or it MAY reply with a NOTIFICATION message with ERROR 401 Code OPEN Message Error and Error Subcode Grouping Required, and the 402 connection will be closed. 404 If the peer wishes to continue the BGP connection on a different 405 transport endpoint, in addition to responding as detailed above, it 406 will set the R bit and will include the TCP port number that should 407 be used to continue the connection. See Section 5.1.1.1 for details 408 regarding how this is handled. 410 If the peer does not wish to support the AFI/SAFI in question, it 411 will reply with a NOTIFICATION message with Error Code OPEN Message 412 Error, and Error Subcode Capability Value Mismatch, and the 413 connection will be closed. 415 A BGP speaker MUST NOT attempt to initiate connections for any AFI/ 416 SAFI for which a connection already exists. 418 If the peer does not support this specification, it will respond with 419 an OPEN that does not include the Multisession capability. In this 420 case the connection SHOULD be terminated, and future connections to 421 the peer should be attempted in the "backward compatibility" mode 422 discussed in Section 6. 424 5.1.1.1. Continuing a Redirected Connection 426 When the active speaker receives an OPEN from the passive speaker 427 that includes transport redirect information, it MUST reply with an 428 Open Message Error NOTIFICATION with its subcode set to Redirecting 429 Now and close the session. Subsequently, it MUST attempt to initiate 430 a new session using the transport endpoint that the passive speaker 431 has proposed in lieu of the original one (which typically would have 432 been the well-known BGP port, 179). The new session should proceed 433 exactly as the original one did; that is, the active speaker SHOULD 434 send an OPEN with the same content, and can expect to receive from 435 the passive speaker an OPEN with the same content as previously with 436 the exception that the R bit should be clear and no associated port 437 number should be present. If the R bit is not clear it (and the 438 accompanying port number) SHOULD be disregarded. 440 Note that although the OPEN messages exchanged on the reinitiated 441 session can be expected to be the same as or similar to those from 442 the previous session as discussed above, an implementation MUST NOT 443 rely on or enforce this assumption when handling the received OPEN. 444 The new session MUST be handled as any other new session would be in 445 this respect. 447 As discussed above, when the passive speaker requests a redirect, the 448 active speaker is expected to drop the current session and initiate a 449 new one. If it does not do so, the passive speaker MAY elect to 450 continue the session, or it MAY elect to terminate the session by 451 sending a Redirect Required NOTIFICATION. 453 5.1.2. Accepting Connections 455 When processing a connection attempt, the BGP speaker MUST wait until 456 the peer's OPEN message has been received before proceeding. This is 457 at variance with the behavior specified in the finite state machine 458 (FSM) of [RFC4271], but is interoperable with that FSM. The FSM 459 changes are specified in Section 7. 461 Once the peer's OPEN message has been received, if it includes the 462 Multisession capability and one or more MP-BGP capabilities 463 indicating a group of AFI/SAFI that the BGP speaker wishes to 464 support, then the BGP speaker responds with an OPEN message that 465 includes the Multisession capability and one or more MP-BGP 466 capabilities indicating the same AFI/SAFI. 468 If the OPEN includes the Multisession capability and one or more MP- 469 BGP capabilities indicating a group of AFI/SAFI that conflicts with 470 an AFI/SAFI grouping that has been configured on the BGP speaker then 471 the BGP speaker MAY reply with an OPEN listing a set of AFI/SAFI that 472 intersect with those proposed by the peer (in effect overriding the 473 locally configured set) or it MAY close the connection with a 474 NOTIFICATION message with Error Code OPEN Message Error and Error 475 Subcode Grouping Conflict. The former behavior is suggested as the 476 default if grouping is supported. 478 If the BGP speaker does not support AFI/SAFI grouping it MAY reply 479 with an OPEN listing one of the AFI/SAFI out of those proposed by the 480 peer. It MUST also set the G bit in the Multisession capability to 481 zero. 483 If the passive speaker wishes to continue the session for this 484 particular grouping on a different port number, it sets the R bit in 485 its OPEN and includes the TCP port number on which it will continue 486 the session. The passive speaker MUST be prepared to accept a 487 connection on the given port immediately following transmission of 488 its OPEN. 490 If the received OPEN message does not include any MP-BGP capability 491 indicating an AFI/SAFI the BGP speaker wishes to support, it SHOULD 492 close the connection with a NOTIFICATION message with Error Code OPEN 493 Message Error and Error Subcode Capability Value Mismatch. 495 If the received OPEN message does not include the Multisession 496 capability, then the peer does not support this specification. The 497 connection MAY be continued in the "backward compatibility" mode 498 discussed in Section 6, or it MAY be terminated and future 499 connections to the peer attempted in the "backward compatibility" 500 mode. 502 5.1.3. Collision Detection, Graceful Restart 504 [RFC4271] Section 6.8 (BGP connection collision detection) considers 505 a pair of connections to have collided if the source and destination 506 IP addresses of both connections match. With respect to peers that 507 support this specification, the AFI/SAFI groups associated with the 508 connections must also intersect for them to be considered to have 509 collided. 511 This consideration also applies to Section 4.2 of BGP Graceful 512 Restart [RFC4724], when determining whether a new connection should 513 be considered equivalent to a reset of a previous TCP session. 515 6. Backward Compatibility 517 This subsection discusses a BGP speaker's behavior towards a peer 518 that is known or assumed not to support this specification. In 519 short, the BGP speaker's behavior towards such a peer should be as 520 otherwise defined for the BGP protocol, according to [RFC4271] and 521 any other extension supported by the BGP speaker. 523 As previously mentioned, the BGP speaker SHOULD always advertise the 524 Multisession capability in its OPEN message, even towards "backward 525 compatibility" peers. 527 If, in opening a BGP connection with such a peer, an OPEN that 528 includes the Multisession capability is received from the peer, then 529 the peer SHOULD be changed to "multisession" mode. How this is done 530 depends on whether the BGP speaker has already sent an OPEN or not -- 532 If the BGP speaker has not yet sent an OPEN to the peer, then the 533 connection MAY be continued in the "multisession" mode discussed 534 above, or it MAY be terminated and future connections to the peer 535 attempted in "multisession" mode. 537 If the BGP speaker has sent an OPEN to the peer, then the current 538 session SHOULD be terminated and future connections to the peer 539 attempted in "multisession" mode. 541 Use of techniques such as dynamic capabilities 542 [I-D.ietf-idr-dynamic-cap] for on-the-fly switching of session modes 543 is beyond the scope of this document. 545 7. State Machine 547 As mentioned under "accepting connections" above, this specification 548 modifies the BGP finite state machine, albeit in a backward- 549 compatible fashion. 551 In addition, note that one state machine is considered to exist for 552 each of the connections that may exist to a given peer. This implies 553 that, for example, any session flap dampening that may exist is 554 performed per session identifier. 556 The specific state machine modifications to [RFC4271] Section 8.2.2 557 are as follows. 559 7.1. Modifications to Connect State and Active State 561 In the actions in response to the events Open Delay timer expires 562 [Event 12] and TCP connection succeeds [Event 16 or Event 17], an 563 OPEN is not sent and the state changes to WaitForOpen and not to 564 OpenSent. 566 7.2. Addition of WaitForOpen State, Deletion of OpenSent State 568 The WaitForOpen state is the same in all respects to OpenSent, except 569 for the action in response to reception of a valid OPEN message 570 [Event 19]. In that event, the local system sends an OPEN message 571 prior to sending a KEEPALIVE message. 573 The OpenSent state is deleted. All references to OpenSent are 574 replaced by references to WaitForOpen. 576 8. Discussion 578 Note that many BGP implementations already permit multiple sessions 579 to be used between a given pair of routers, typically by configuring 580 multiple IP addresses on each router and configuring each session to 581 be bound to a different IP address. The principal contribution of 582 this specification is to allow multiple sessions to be created 583 automatically, without additional configuration overhead or address 584 consumption. 586 The specification supports the simple case of one capability being 587 used as the session identifier and one connection per session 588 identifier value. It also permits connections be established based 589 on multiple capabilities as a session identifier with multiple values 590 per capability grouped together per connection. 592 In the context of MP-BGP based connections, which we believe may be 593 the most prevalent use of this specification, it permits supporting 594 one AFI/SAFI per connection, and also permits arbitrary grouping of 595 AFI/SAFI onto BGP connections. For such grouping to function 596 pleasingly, both peers participating in a connection need to agree on 597 what AFI/SAFI groupings will be used. If conflicting groupings are 598 configured, the connections may not establish, or more connections 599 may be established than were expected (in the degenerate case, one 600 connection per AFI/SAFI could be established despite configured 601 groupings). We observe that the potential for misbehavior in the 602 presence of conflicting configuration is not unusual in BGP, and that 603 support for, and configuration of grouping is purely optional. 605 9. Security Considerations 607 The ability to redirect to a port other than the well-known BGP port 608 implies that a legitimate BGP session may exist for which neither 609 port is equal to 179. This may have implications for firewall 610 filters used to protect the control processor. 612 In other respects, this document does not change the BGP security 613 model. 615 10. Acknowledgements 617 The authors would like to thank Pedro Marques, Keyur Patel, Robert 618 Raszuk, Yakov Rekhter and David Ward for their valuable comments. 620 11. IANA Considerations 622 IANA has allocated BGP Capability Code 68 as the Multisession BGP 623 Capability. 625 This document requests IANA to allocate five new OPEN Message Error 626 subcodes: 628 7 - Capability Value Mismatch 630 8 - Grouping Conflict 632 9 - Grouping Required 634 10 - Redirecting Now 636 11 - Redirect Required 638 12. References 640 12.1. Normative References 642 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 643 Requirement Levels", BCP 14, RFC 2119, March 1997. 645 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 646 Protocol 4 (BGP-4)", RFC 4271, January 2006. 648 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 649 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 650 January 2007. 652 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 653 "Multiprotocol Extensions for BGP-4", RFC 4760, 654 January 2007. 656 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 657 with BGP-4", RFC 5492, February 2009. 659 12.2. Informative References 661 [I-D.ietf-idr-dynamic-cap] 662 Chen, E. and S. Sangli, "Dynamic Capability for BGP-4", 663 draft-ietf-idr-dynamic-cap-09 (work in progress), 664 November 2006. 666 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 667 September 2000. 669 Authors' Addresses 671 John G. Scudder 672 Juniper Networks 674 Email: jgs@juniper.net 676 Chandra Appanna 677 Cisco Systems 679 Email: achandra@cisco.com