idnits 2.17.1 draft-ietf-idr-bgp-multisession-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 533. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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. ** There are 45 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** 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 87: '...is specification MUST also implement t...' RFC 2119 keyword, line 89: '...s implementing this specification MUST...' RFC 2119 keyword, line 172: '...ility Value code MAY be used when an O...' RFC 2119 keyword, line 178: '...ng Conflict code MAY be used when an O...' RFC 2119 keyword, line 181: '... SHOULD indicate one of the conflict...' (27 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 447 has weird spacing: '...bitrary group...' == Line 448 has weird spacing: '...ping to funct...' -- 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 (January 2007) is 6304 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 374, but not defined == Missing Reference: 'Event 12' is mentioned on line 415, but not defined == Missing Reference: 'Event 19' is mentioned on line 423, but not defined == Unused Reference: 'BGP4' is defined on line 464, 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: 9 errors (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group John G Scudder 2 Internet Draft Juniper Networks 3 Expiration Date: June 2007 Chandra Appanna 4 File name: draft-ietf-idr-bgp-multisession-03.txt Cisco Systems 5 January 2007 7 Multisession BGP 8 draft-ietf-idr-bgp-multisession-03.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that 13 any applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any 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. 67 Each transport session can be used for one or more AFI/SAFI. 69 While AFI/SAFI based sessions is one way to group data being exchanged 70 between BGP peers it is also possible to concieve of sessions being 71 based on other characteristics of the BGP data. In this draft we also 72 propose a scheme for creating multiple BGP sessions between BGP peers 73 based on criteria other than AFI/SAFI. However, the definition of specific 74 criteria for grouping exchanged data into sessions is beyond the scope of 75 this proposal. The goal of this proposal is to provide a mechanism for 76 doing that if such criteria is available. For ease of understandability 77 and readability, AFI/SAFI will be used as an illustrative grouping 78 criteria through out the document. 80 Each session is distinct from a BGP protocol point of view; an error 81 or other event on one session has no implications for any other session. 82 All protocol modifications proposed by this specification take place 83 during the OPEN exchange phase of the session, there are no 84 modifications to the operation of the protocol once a session reaches 85 ESTABLISHED state. 87 Routers implementing this specification MUST also implement the base 88 criteria that is used to define sessions. For example if AFI/SAFI based 89 sessions are desired then peers implementing this specification MUST 90 also implement [MP-BGP]. 92 2. Definitions 94 "MP-BGP capability" refers to the capability [BGP-CAP] with code 1, 95 specified in [MP-BGP] section 10. 97 A BGP speaker is said to "support" some feature or functionality (for 98 example, to support this specification, or to support a particular 99 AFI/SAFI) when the BGP implementation supports the feature AND the 100 feature has not been disabled by configuration. 102 The Session Identifier is a capability or group of capabilities that 103 will be used to differentiate individual BGP sessions between two IP 104 endpoints. When the AFI/SAFI is used to distinguish sessions, the MP-BGP 105 capability is the session identifier. 107 In this document the MP-BGP capability is used as a Session Identifier 108 for illustrative and explanatory purpose, i.e as the capability whose 109 values differentiates the multiple session between two IP endpoints. 110 MP-BGP and AFI/SAFI can be replaced by any other capability and the 111 values of that capability to setup multiple sessions, without any 112 modifications to the procedures described. 114 A pair of session indentifiers are said to conflict when considering the 115 two groups as two sets, there is an intersection between the groups either 116 in the capabilities or the values in the capabilities, but neither session 117 group is a subset of the other. For example, a pair of AFI/SAFI is said 118 to "conflict" when considering the two groups as two sets, there is an 119 intersection between the groups but neither group is a subset of the other. 121 3. Use of BGP Capability Advertisement 123 This specification defines the Multisession capability [BGP-CAP]: 125 Capability code (1 octet): TBD 127 Capability length (1 octet): variable 129 Capability value (1 octet): Flags followed by the list of capabilities 130 that define a session. 132 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 133 +-+-+-+-+-+-+-+-+ 134 |G| Reserved | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | One or more list of Capability codes (1 octet each) | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 The most significant bit is defined as the Grouping Support (G) bit. 140 It can be used to indicate support for the ability to group multiple 141 capabilty values into one session. When set (value 1) this bit indicates 142 that the BGP speaker supports grouping. 144 The remaining bits are reserved, and should be set to zero by the 145 sender and ignored by the receiver. 147 Following the reserved bits is a list of one or more Capability codes 148 defined in BGP. The capabilities listed here represent the session 149 identifier for sessions between the BGP speakers. 151 For example peers wishing to establish sessions based on AFI/SAFI would 152 exchange the Multiprotocol Extensions capability code (1) only in the 153 list. In this case the Multisession capability would have a length of 154 2 octets. 156 4. New NOTIFICATION Subcodes 158 [BGP, BGP-DRAFT] Section 4.5 provides a number of subcodes to the 159 NOTIFICATION message, and Section 6.2 elaborates on the use of those 160 subcodes. 162 This specification introduces two new subcodes: 164 OPEN Message Error subcodes: 166 7 - No Supported Capability Value. 168 8 - Grouping Conflict 170 9 - Grouping Required 172 The No Supported Capability Value code MAY be used when an OPEN message 173 contains one or more capabilities, none of which list an 174 capability supported by the local BGP speaker. It is observed that 175 this subcode may be useful for BGP speakers in general, even if 176 they do not (otherwise) implement this specification. 178 The Grouping Conflict code MAY be used when an OPEN message contains 179 several capabilities whose values conflict with one or more 180 capability groups configured on the local BGP speaker. The Data field 181 SHOULD indicate one of the conflicting locally-configured capability 182 groups, encoded as theh appropriate capabilities. 184 The Grouping Required code MAY be used when a BGP speaker which is 185 configured to require grouping attempts to establish a connection 186 with a BGP speaker which does not support grouping. (While it is 187 true that it might be possible to communicate much the same 188 information using the Unsupported Capability NOTIFICATION message, 189 this more explicit method is felt to be more transparent.) 191 If MP-BGP capability is used as the session identifier, the notification 192 codes could be used as follows: 194 The No Supported Capability Value code MAY be used when an OPEN message 195 contains one or more MP-BGP capabilities, none of which list an 196 AFI/SAFI supported by the local BGP speaker. It is observed that 197 this subcode may be useful for MP-BGP speakers in general, even if 198 they do not (otherwise) implement this specification. 200 The Grouping Conflict code MAY be used when an OPEN message contains 201 several MP-BGP capabilities whose AFI/SAFI conflict with one or more 202 AFI/SAFI groups configured on the local BGP speaker. The Data field 203 SHOULD indicate one of the conflicting locally-configured AFI/SAFI 204 groups, encoded as MP-BGP capabilities. 206 The Grouping Required code MAY be used when a BGP speaker which is 207 configured to require grouping attempts to establish a connection 208 with a BGP speaker which does not support grouping. (While it is 209 true that it might be possible to communicate much the same 210 information using the Unsupported Capability NOTIFICATION message, 211 this more explicit method is felt to be more transparent.) 213 The use of these subcodes is further elaborated below. 215 5. Overview of Operation 217 The operation section is divided into two main subsections. 219 The "Using Multisession" sections below discuss the BGP speaker's 220 behavior when the peer does support this specification or is assumed 221 to. The "Backward Compatibility" section discusses the BGP speaker's 222 behavior when the peer does not support this specification, or is 223 assumed not to. Both sections also discuss how to switch to the other 224 mode. 226 A BGP speaker which supports this specification SHOULD always 227 advertise the Multisession capability, regardless of its peer's known 228 or presumed capability set. 230 In all cases until a BGP speaker has initiated or accepted one connection 231 from a given peer, it is unknown whether the peer supports this 232 specification or not. Two strategies can be considered for making 233 this initial determination -- either the BGP speaker can initially 234 assume that the peer does not support this specification, and switch 235 modes if it is discovered that it does, or vice-versa. Either 236 approach is acceptable. 238 Again for illustration, section 5.0 describes the operation from the 239 point of view of the MP-BGP capability and the associated AFI/SAFI 240 values as the session identifier. It can be replaced with any other 241 capability or groups of capabilties without any changes to the behaviour 242 described below. 244 Note that if a BGP speaker only wishes to support a single AFI/SAFI 245 in its communications with a given peer only one session is needed in 246 any case, and so the "multisession" feature is moot. In such a case 247 the behavior required would be indistinguishable from that given in 248 the "backward compatibility" section below. In the illustrative examples 249 in the following sections, it is generally assumed that a BGP speaker 250 does wish to support multiple AFI/SAFI in its communications with a 251 given peer. 253 5.1. Using Multisession: 255 The following subsections discuss a BGP speaker's behavior towards a 256 peer which is known or assumed to support this specification. 258 5.1.1. Initiating Connections: 260 When a BGP speaker attempts BGP communication with its peer, it 261 initiates one connection per group of AFI/SAFI it wishes to support. 262 (This implies that a new local TCP port will be allocated for each 263 new connection.) The OPEN sent on each connection MUST include the 264 Multisession capability and one or more MP-BGP capabilities 265 indicating the AFI/SAFI to be supported on that session. If a non- 266 trivial group of AFI/SAFI (i.e., a group of two or more) is proposed, 267 the BGP speaker MUST also set the G bit of the Multisession 268 capability. Even if a trivial group of AFI/SAFI is proposed, the G 269 bit SHOULD be set if grouping is supported. 271 Note that any "group of AFI/SAFI" may be a singleton group, i.e. the 272 speaker may wish to use a separate BGP connection for each AFI/SAFI. 274 If the peer also supports this specification and also wishes to 275 support the AFI/SAFI in question, it will respond with an OPEN which 276 includes the Multisession capability and the AFI/SAFI included in the 277 active speaker's OPEN. If the active speaker's OPEN included a non- 278 trivial group of AFI/SAFI which the peer supports, then the peer's 279 Multisession capability will have the G bit set. 281 If the peer also supports this specification and wishes to support 282 some but not all of the AFI/SAFI in question, it will respond with an 283 OPEN which includes the Multisession capability and a subset of 284 AFI/SAFI included in the active speaker's OPEN. The reason for 285 listing only a subset may be because some of the AFI/SAFI are simply 286 not supported, or because the peer does not wish to support the 287 AFI/SAFI as a group (i.e. it may be configured to use a smaller 288 group). In this case, the BGP speaker MAY consider the set of 289 AFI/SAFI which were not included in the peer's OPEN to form a new 290 group, and MAY try to initiate a new session using that group. 292 If the peer also supports this specification but does not support 293 grouping, and a non-trivial group of AFI/SAFI has been proposed, then 294 it will respond as given in the previous paragraph but with the 295 additional proviso that the G bit will be clear. In this case, the 296 BGP speaker MAY accept the connection as given in the previous 297 paragraph, or it MAY reply with a NOTIFICATION message with ERROR 298 Code OPEN Message Error and Error Subcode Grouping Required, and the 299 connection will be closed. 301 If the peer does not wish to support the AFI/SAFI in question, it 302 will reply with a NOTIFICATION message with Error Code OPEN Message 303 Error, and Error Subcode No Supported Capability value, and the connection 304 will be closed. 306 A BGP speaker SHOULD NOT attempt to initiate connections for any 307 AFI/SAFI for which a connection already exists. 309 If the peer does not support this specification, it will respond with 310 an OPEN which does not include the Multisession capability. In this 311 case the connection SHOULD be terminated, and future connections to 312 the peer should be attempted in the "backward compatibility" mode 313 discussed below. 315 5.1.2. Accepting Connections: 317 When processing a connection attempt, the BGP speaker MUST wait until 318 the peer's OPEN message has been received before proceeding. This is 319 at variance with the behavior specified in the finite state machine 320 (FSM) of [BGP-DRAFT], but is interoperable with that FSM. The FSM 321 changes are specified in a later section. 323 Once the peer's OPEN message has been received, if it includes the 324 Multisession capability and one or more MP-BGP capabilities 325 indicating a group of AFI/SAFI which the BGP speaker wishes to 326 support, then the BGP speaker responds with an OPEN message which 327 includes the Multisession capability and one or more MP-BGP 328 capabilities indicating the same AFI/SAFI. 330 If the OPEN includes the Multisession capability and one or more MP- 331 BGP capabilities indicating a group of AFI/SAFI which conflicts with 332 an AFI/SAFI grouping that has been configured on the BGP speaker then 333 the BGP speaker MAY reply with an OPEN listing a set of AFI/SAFI 334 which intersect with those proposed by the peer (in effect overriding 335 the locally configured set) or it MAY close the connection with a 336 NOTIFICATION message with Error Code OPEN Message Error and Error 337 Subcode Grouping Conflict. The former behavior is suggested as the 338 default if grouping is supported. 340 If the BGP speaker does not support AFI/SAFI grouping it MAY reply 341 with an OPEN listing one of the AFI/SAFI out of those proposed by the 342 peer. It SHOULD also set the G bit in the Multisession capability to 343 zero. 345 If the received OPEN message does not include any MP-BGP capability 346 indicating an AFI/SAFI the BGP speaker wishes to support, it should 347 close the connection with a NOTIFICATION message with Error Code OPEN 348 Message Error and Error Subcode No Supported Capability Value. 350 If the received OPEN message does not include the Multisession 351 capability, then the peer does not support this specification. The 352 connection MAY be continued in the "backward compatibility" mode 353 discussed below, or it MAY be terminated and future connections to 354 the peer attempted in the "backward compatibility" mode. 356 5.1.3. Collision Detection, Graceful Restart: 358 [BGP, BGP-DRAFT] Section 6.8 (BGP connection collision detection) 359 considers a pair of connections to have collided if the source and 360 destination IP addresses of both connections match. With respect to 361 peers which support this specification, the AFI/SAFI groups 362 associated with the connections must also intersect for them to be 363 considered to have collided. 365 This consideration also applies to Section 6.2 of [BGP-GR], when 366 determining whether a new connection should be considered equivalent 367 to a reset of a previous TCP session. 369 5.2. Backward Compatibility: 371 This subsection discusses a BGP speaker's behavior towards a peer 372 which is known or assumed not to support this specification. In 373 short, the BGP speaker's behavior towards such a peer should be as 374 otherwise defined for the BGP protocol, according to [BGP, BGP-DRAFT] 375 and any other extension supported by the BGP speaker. 377 As previously mentioned, the BGP speaker SHOULD always advertise the 378 Multisession capability in its OPEN message, even towards "backward 379 compatibility" peers. 381 If, in opening a BGP connection with such a peer, an OPEN which 382 includes the Multisession capability is received from the peer, then 383 the peer SHOULD be changed to "multisession" mode. How this is done 384 depends on whether the BGP speaker has already sent an OPEN or not -- 386 If the BGP speaker has not yet sent an OPEN to the peer, then the 387 connection MAY be continued in the "multisession" mode discussed 388 above, or it MAY be terminated and future connections to the peer 389 attempted in "multisession" mode. 391 If the BGP speaker has sent an OPEN to the peer, then the current 392 session SHOULD be terminated and future connections to the peer 393 attempted in "multisession" mode. 395 Use of techniques such as [BGP-DYN-CAP] for on-the-fly switching of 396 session modes are beyond the scope of this document. 398 6. State Machine 400 As mentioned under "accepting connections" above, this specification 401 modifies the BGP finite state machine, albeit in a backward- 402 compatible fashion. 404 In addition, note that one state machine is considered to exist for 405 each of the connections which may exist to a given peer. This 406 implies that, for example, any session flap dampening that may exist 407 is performed per session indetifier. 409 The specific state machine modifications to [BGP-DRAFT] Section 8.2.2 410 are as follows. 412 6.1. Modifications to Connect State and Active State 414 In the actions in response to the events Open Delay timer expires 415 [Event 12] and TCP connection succeeds [Event 16 or Event 17], an 416 OPEN is not sent and the state changes to WaitForOpen and not to 417 OpenSent. 419 6.2. Addition of WaitForOpen State, Deletion of OpenSent State 421 The WaitForOpen state is the same in all respects to OpenSent, except 422 for the action in response to reception of a valid OPEN message 423 [Event 19]. In that event, the local system sends an OPEN message 424 prior to sending a KEEPALIVE message. 426 The OpenSent state is deleted. All references to OpenSent are 427 replaced by references to WaitForOpen. 429 7. Discussion 431 Note that many BGP implementations already permit multiple sessions 432 to be used between a given pair of routers, typically by configuring 433 multiple IP addresses on each router and configuring each session to 434 be bound to a different IP address. The principal contribution of 435 this specification is to allow multiple sessions to be created 436 automatically, without additional configuration overhead or address 437 consumption. 439 The specification supports the simple case of one capability being used 440 as the session identifier and one connection per session identifier value. 441 It also permits connections be established based on the multiple 442 capabilties as a sessio identifier with multiple values per capability 443 grouped together per connection. 445 In the context of MP-BGP based connections, which we believe may be the 446 most prevalent use of this specification it permits supporting one 447 AFI/SAFI per connection, and also permits arbitrary grouping of AFI/SAFI 448 onto BGP connections. For such grouping to function pleasingly, both 449 peers participating in a connection need to agree on what AFI/SAFI 450 groupings will be used. If conflicting groupings are configured, the 451 connections may not establish, or more connections may be established 452 than were expected (in the degenerate case, one connection per AFI/SAFI 453 could be established despite configured groupings). We observe that 454 the potential for misbehavior in the presence of conflicting configuration 455 is not unusual in BGP, and that support for, and configuration of grouping 456 is purely optional. 458 8. Acknowledgements 460 To be supplied. 462 9. References 464 [BGP4] 465 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)," RFC 466 1771, March 1995. 468 [BGP-DRAFT] 469 Rekhter, Y., T. Li and S. Hares, "A Border Gateway Protocol 4 470 (BGP-4)," Work in Progress (draft-ietf-idr-bgp4-20), April 2003. 472 [MP-BGP] 473 Bates, T., R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol Exten- 474 sions for BGP-4," Work in Progress (draft-ietf-idr-rfc2858bis-03), 475 July 2003. 477 [BGP-GR] 478 Sangli, S., Y. Rekhter, R. Fernando, J. Scudder, E. Chen, "Graceful 479 Restart Mechanism for BGP," Work in Progress (draft-ietf-idr- 480 restart-06), January 2003. 482 [BGP-CAP] 483 Chandra, R., J. Scudder, "Capabilities Advertisement with BGP-4," 484 RFC 2842, May 2000. 486 [BGP-DYN-CAP] 487 Chen, E. and S. Sangli, "Dynamic Capability for BGP-4," Work in 488 Progress (draft-ietf-idr-dynamic-cap-03), December 2002. 490 10. Security Considerations 492 This document introduces no new security vulnerabilities to BGP or 493 other specifications referenced in this document. 495 11. IANA Considerations 497 TBD 499 12. Authors' Addresses 501 John G. Scudder 502 Juniper Networks 503 Email: jgs@juniper.net 505 Chandrashekhar (Chandra) Appanna 506 Cisco Systems, Inc. 507 170 West Tasman Drive 508 San Jose, CA 95134 509 e-mail: achandra@cisco.com 511 13. Intellectual Property Statement 513 The IETF takes no position regarding the validity or scope of any 514 Intellectual Property Rights or other rights that might be claimed to 515 pertain to the implementation or use of the technology described in 516 this document or the extent to which any license under such rights 517 might or might not be available; nor does it represent that it has 518 made any independent effort to identify any such rights. Information 519 on the procedures with respect to rights in RFC documents can be 520 found in BCP 78 and BCP 79. 522 Copies of IPR disclosures made to the IETF Secretariat and any 523 assurances of licenses to be made available, or the result of an 524 attempt made to obtain a general license or permission for the use of 525 such proprietary rights by implementers or users of this 526 specification can be obtained from the IETF on-line IPR repository at 527 http://www.ietf.org/ipr. 529 The IETF invites any interested party to bring to its attention any 530 copyrights, patents or patent applications, or other proprietary 531 rights that may cover technology that may be required to implement 532 this standard. Please address the information to the IETF at 533 ietf-ipr@ietf.org. 535 14. Disclaimer of Validity 537 This document and the information contained herein 538 are provided on an "AS IS" basis and THE CONTRIBUTOR, THE 539 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE 540 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 541 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 542 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 543 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 544 OR FITNESS FOR A PARTICULAR PURPOSE. 546 15. Copyright Statement 548 Copyright (C) The Internet Society (2007). This document is subject 549 to the rights, licenses and restrictions contained in BCP 78, and except 550 as set forth therein, the authors retain all their rights.