idnits 2.17.1 draft-ietf-idr-bgp-multisession-01.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 545. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 528. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 534. ** 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 40 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 86: '...is specification MUST also implement t...' RFC 2119 keyword, line 88: '...s implementing this specification MUST...' RFC 2119 keyword, line 171: '...ility Value code MAY be used when an O...' RFC 2119 keyword, line 177: '...ng Conflict code MAY be used when an O...' RFC 2119 keyword, line 180: '... 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 446 has weird spacing: '...bitrary group...' == Line 447 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 (October 2005) is 6768 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 373, but not defined == Missing Reference: 'Event 12' is mentioned on line 414, but not defined == Missing Reference: 'Event 19' is mentioned on line 422, but not defined == Unused Reference: 'BGP4' is defined on line 463, 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 Chandra Appanna 2 Internet Draft John G. Scudder 3 Expiration Date: March 2006 Cisco Systems 4 File name: draft-ietf-idr-bgp-multisession-01.txt October 2005 6 Multisession BGP 7 draft-ietf-idr-bgp-multisession-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 This specification augments "Multiprotocol Extensions for BGP-4" [MP- 33 BGP] by proposing a mechanism to allow multiple sessions to be used 34 between a given pair of BGP speakers. Each session is used to 35 transport routes for one or more AFI/SAFI. This provides an 36 alternative to the current [MP-BGP] approach of multiplexing routes 37 for all AFI/SAFI onto a single connection. 39 Use of this approach is expected to increase the robustness of the 40 BGP protocol as it is used to support more and more diverse AFI/SAFI. 42 1. Introduction 44 Most BGP [BGP, BGP-DRAFT] implementations only permit a single 45 ESTABLISHED connection to exist with each peer. More precisely, they 46 only permit a single ESTABLISHED connection for any given pair of IP 47 endpoints. 49 Multiprotocol BGP [MP-BGP] extends BGP to allow information for 50 multiple NLRI families and sub-families to be transported in BGP. 51 Routes for different families are distinguished by AFI and SAFI. 52 Routes for different families are commonly multiplexed onto a single 53 BGP session. 55 A common criticism of BGP is the fact that most malformed messages 56 cause the session to be terminated. While this behavior is necessary 57 for protocol correctness, one may observe that the protocol machinery 58 of a given implementation may only be defective with respect to a 59 given AFI/SAFI. Thus, it would be desirable to allow the session 60 related to that family to be terminated while leaving other AFI/SAFI 61 unaffected. As BGP is commonly deployed, this is not possible. 63 In this specification, we propose a mechanism by which multiple 64 transport sessions may be established between a pair of peers. 66 Each transport session can be used for one or more AFI/SAFI. 68 While AFI/SAFI based sessions is one way to group data being exchanged 69 between BGP peers it is also possible to concieve of sessions being 70 based on other characteristics of the BGP data. In this draft we also 71 propose a scheme for creating multiple BGP sessions between BGP peers 72 based on criteria other than AFI/SAFI. However, the definition of specific 73 criteria for grouping exchanged data into sessions is beyond the scope of 74 this proposal. The goal of this proposal is to provide a mechanism for 75 doing that if such criteria is available. For ease of understandability 76 and readability, AFI/SAFI will be used as an illustrative grouping 77 criteria through out the document. 79 Each session is distinct from a BGP protocol point of view; an error 80 or other event on one session has no implications for any other session. 81 All protocol modifications proposed by this specification take place 82 during the OPEN exchange phase of the session, there are no 83 modifications to the operation of the protocol once a session reaches 84 ESTABLISHED state. 86 Routers implementing this specification MUST also implement the base 87 criteria that is used to define sessions. For example if AFI/SAFI based 88 sessions are desired then peers implementing this specification MUST 89 also implement [MP-BGP]. 91 2. Definitions 93 "MP-BGP capability" refers to the capability [BGP-CAP] with code 1, 94 specified in [MP-BGP] section 10. 96 A BGP speaker is said to "support" some feature or functionality (for 97 example, to support this specification, or to support a particular 98 AFI/SAFI) when the BGP implementation supports the feature AND the 99 feature has not been disabled by configuration. 101 The Session Identifier is a capability or group of capabilities that 102 will be used to differentiate individual BGP sessions between two IP 103 endpoints. When the AFI/SAFI is used to distinguish sessions, the MP-BGP 104 capability is the session identifier. 106 In this document the MP-BGP capability is used as a Session Identifier 107 for illustrative and explanatory purpose, i.e as the capability whose 108 values differentiates the multiple session between two IP endpoints. 109 MP-BGP and AFI/SAFI can be replaced by any other capability and the 110 values of that capability to setup multiple sessions, without any 111 modifications to the procedures described. 113 A pair of session indentifiers are said to conflict when considering the 114 two groups as two sets, there is an intersection between the groups either 115 in the capabilities or the values in the capabilities, but neither session 116 group is a subset of the other. For example, a pair of AFI/SAFI is said 117 to "conflict" when considering the two groups as two sets, there is an 118 intersection between the groups but neither group is a subset of the other. 120 3. Use of BGP Capability Advertisement 122 This specification defines the Multisession capability [BGP-CAP]: 124 Capability code (1 octet): TBD 126 Capability length (1 octet): variable 128 Capability value (1 octet): Flags followed by the list of capabilities 129 that define a session. 131 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 132 +-+-+-+-+-+-+-+-+ 133 |G| Reserved | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | One or more list of Capability codes (1 octet each) | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 The most significant bit is defined as the Grouping Support (G) bit. 139 It can be used to indicate support for the ability to group multiple 140 capabilty values into one session. When set (value 1) this bit indicates 141 that the BGP speaker supports grouping. 143 The remaining bits are reserved, and should be set to zero by the 144 sender and ignored by the receiver. 146 Following the reserved bits is a list of one or more Capability codes 147 defined in BGP. The capabilities listed here represent the session 148 identifier for sessions between the BGP speakers. 150 For example peers wishing to establish sessions based on AFI/SAFI would 151 exchange the Multiprotocol Extensions capability code (1) only in the 152 list. In this case the Multisession capability would have a length of 153 2 octets. 155 4. New NOTIFICATION Subcodes 157 [BGP, BGP-DRAFT] Section 4.5 provides a number of subcodes to the 158 NOTIFICATION message, and Section 6.2 elaborates on the use of those 159 subcodes. 161 This specification introduces two new subcodes: 163 OPEN Message Error subcodes: 165 7 - No Supported Capability Value. 167 8 - Grouping Conflict 169 9 - Grouping Required 171 The No Supported Capability Value code MAY be used when an OPEN message 172 contains one or more capabilities, none of which list an 173 capability supported by the local BGP speaker. It is observed that 174 this subcode may be useful for BGP speakers in general, even if 175 they do not (otherwise) implement this specification. 177 The Grouping Conflict code MAY be used when an OPEN message contains 178 several capabilities whose values conflict with one or more 179 capability groups configured on the local BGP speaker. The Data field 180 SHOULD indicate one of the conflicting locally-configured capability 181 groups, encoded as theh appropriate capabilities. 183 The Grouping Required code MAY be used when a BGP speaker which is 184 configured to require grouping attempts to establish a connection 185 with a BGP speaker which does not support grouping. (While it is 186 true that it might be possible to communicate much the same 187 information using the Unsupported Capability NOTIFICATION message, 188 this more explicit method is felt to be more transparent.) 190 If MP-BGP capability is used as the session identifier, the notification 191 codes could be used as follows: 193 The No Supported Capability Value code MAY be used when an OPEN message 194 contains one or more MP-BGP capabilities, none of which list an 195 AFI/SAFI supported by the local BGP speaker. It is observed that 196 this subcode may be useful for MP-BGP speakers in general, even if 197 they do not (otherwise) implement this specification. 199 The Grouping Conflict code MAY be used when an OPEN message contains 200 several MP-BGP capabilities whose AFI/SAFI conflict with one or more 201 AFI/SAFI groups configured on the local BGP speaker. The Data field 202 SHOULD indicate one of the conflicting locally-configured AFI/SAFI 203 groups, encoded as MP-BGP capabilities. 205 The Grouping Required code MAY be used when a BGP speaker which is 206 configured to require grouping attempts to establish a connection 207 with a BGP speaker which does not support grouping. (While it is 208 true that it might be possible to communicate much the same 209 information using the Unsupported Capability NOTIFICATION message, 210 this more explicit method is felt to be more transparent.) 212 The use of these subcodes is further elaborated below. 214 5. Overview of Operation 216 The operation section is divided into two main subsections. 218 The "Using Multisession" sections below discuss the BGP speaker's 219 behavior when the peer does support this specification or is assumed 220 to. The "Backward Compatibility" section discusses the BGP speaker's 221 behavior when the peer does not support this specification, or is 222 assumed not to. Both sections also discuss how to switch to the other 223 mode. 225 A BGP speaker which supports this specification SHOULD always 226 advertise the Multisession capability, regardless of its peer's known 227 or presumed capability set. 229 In all cases until a BGP speaker has initiated or accepted one connection 230 from a given peer, it is unknown whether the peer supports this 231 specification or not. Two strategies can be considered for making 232 this initial determination -- either the BGP speaker can initially 233 assume that the peer does not support this specification, and switch 234 modes if it is discovered that it does, or vice-versa. Either 235 approach is acceptable. 237 Again for illustration, section 5.0 describes the operation from the 238 point of view of the MP-BGP capability and the associated AFI/SAFI 239 values as the session identifier. It can be replaced with any other 240 capability or groups of capabilties without any changes to the behaviour 241 described below. 243 Note that if a BGP speaker only wishes to support a single AFI/SAFI 244 in its communications with a given peer only one session is needed in 245 any case, and so the "multisession" feature is moot. In such a case 246 the behavior required would be indistinguishable from that given in 247 the "backward compatibility" section below. In the illustrative examples 248 in the following sections, it is generally assumed that a BGP speaker 249 does wish to support multiple AFI/SAFI in its communications with a 250 given peer. 252 5.1. Using Multisession: 254 The following subsections discuss a BGP speaker's behavior towards a 255 peer which is known or assumed to support this specification. 257 5.1.1. Initiating Connections: 259 When a BGP speaker attempts BGP communication with its peer, it 260 initiates one connection per group of AFI/SAFI it wishes to support. 261 (This implies that a new local TCP port will be allocated for each 262 new connection.) The OPEN sent on each connection MUST include the 263 Multisession capability and one or more MP-BGP capabilities 264 indicating the AFI/SAFI to be supported on that session. If a non- 265 trivial group of AFI/SAFI (i.e., a group of two or more) is proposed, 266 the BGP speaker MUST also set the G bit of the Multisession 267 capability. Even if a trivial group of AFI/SAFI is proposed, the G 268 bit SHOULD be set if grouping is supported. 270 Note that any "group of AFI/SAFI" may be a singleton group, i.e. the 271 speaker may wish to use a separate BGP connection for each AFI/SAFI. 273 If the peer also supports this specification and also wishes to 274 support the AFI/SAFI in question, it will respond with an OPEN which 275 includes the Multisession capability and the AFI/SAFI included in the 276 active speaker's OPEN. If the active speaker's OPEN included a non- 277 trivial group of AFI/SAFI which the peer supports, then the peer's 278 Multisession capability will have the G bit set. 280 If the peer also supports this specification and wishes to support 281 some but not all of the AFI/SAFI in question, it will respond with an 282 OPEN which includes the Multisession capability and a subset of 283 AFI/SAFI included in the active speaker's OPEN. The reason for 284 listing only a subset may be because some of the AFI/SAFI are simply 285 not supported, or because the peer does not wish to support the 286 AFI/SAFI as a group (i.e. it may be configured to use a smaller 287 group). In this case, the BGP speaker MAY consider the set of 288 AFI/SAFI which were not included in the peer's OPEN to form a new 289 group, and MAY try to initiate a new session using that group. 291 If the peer also supports this specification but does not support 292 grouping, and a non-trivial group of AFI/SAFI has been proposed, then 293 it will respond as given in the previous paragraph but with the 294 additional proviso that the G bit will be clear. In this case, the 295 BGP speaker MAY accept the connection as given in the previous 296 paragraph, or it MAY reply with a NOTIFICATION message with ERROR 297 Code OPEN Message Error and Error Subcode Grouping Required, and the 298 connection will be closed. 300 If the peer does not wish to support the AFI/SAFI in question, it 301 will reply with a NOTIFICATION message with Error Code OPEN Message 302 Error, and Error Subcode No Supported Capability value, and the connection 303 will be closed. 305 A BGP speaker SHOULD NOT attempt to initiate connections for any 306 AFI/SAFI for which a connection already exists. 308 If the peer does not support this specification, it will respond with 309 an OPEN which does not include the Multisession capability. In this 310 case the connection SHOULD be terminated, and future connections to 311 the peer should be attempted in the "backward compatibility" mode 312 discussed below. 314 5.1.2. Accepting Connections: 316 When processing a connection attempt, the BGP speaker MUST wait until 317 the peer's OPEN message has been received before proceeding. This is 318 at variance with the behavior specified in the finite state machine 319 (FSM) of [BGP-DRAFT], but is interoperable with that FSM. The FSM 320 changes are specified in a later section. 322 Once the peer's OPEN message has been received, if it includes the 323 Multisession capability and one or more MP-BGP capabilities 324 indicating a group of AFI/SAFI which the BGP speaker wishes to 325 support, then the BGP speaker responds with an OPEN message which 326 includes the Multisession capability and one or more MP-BGP 327 capabilities indicating the same AFI/SAFI. 329 If the OPEN includes the Multisession capability and one or more MP- 330 BGP capabilities indicating a group of AFI/SAFI which conflicts with 331 an AFI/SAFI grouping that has been configured on the BGP speaker then 332 the BGP speaker MAY reply with an OPEN listing a set of AFI/SAFI 333 which intersect with those proposed by the peer (in effect overriding 334 the locally configured set) or it MAY close the connection with a 335 NOTIFICATION message with Error Code OPEN Message Error and Error 336 Subcode Grouping Conflict. The former behavior is suggested as the 337 default if grouping is supported. 339 If the BGP speaker does not support AFI/SAFI grouping it MAY reply 340 with an OPEN listing one of the AFI/SAFI out of those proposed by the 341 peer. It SHOULD also set the G bit in the Multisession capability to 342 zero. 344 If the received OPEN message does not include any MP-BGP capability 345 indicating an AFI/SAFI the BGP speaker wishes to support, it should 346 close the connection with a NOTIFICATION message with Error Code OPEN 347 Message Error and Error Subcode No Supported Capability Value. 349 If the received OPEN message does not include the Multisession 350 capability, then the peer does not support this specification. The 351 connection MAY be continued in the "backward compatibility" mode 352 discussed below, or it MAY be terminated and future connections to 353 the peer attempted in the "backward compatibility" mode. 355 5.1.3. Collision Detection, Graceful Restart: 357 [BGP, BGP-DRAFT] Section 6.8 (BGP connection collision detection) 358 considers a pair of connections to have collided if the source and 359 destination IP addresses of both connections match. With respect to 360 peers which support this specification, the AFI/SAFI groups 361 associated with the connections must also intersect for them to be 362 considered to have collided. 364 This consideration also applies to Section 6.2 of [BGP-GR], when 365 determining whether a new connection should be considered equivalent 366 to a reset of a previous TCP session. 368 5.2. Backward Compatibility: 370 This subsection discusses a BGP speaker's behavior towards a peer 371 which is known or assumed not to support this specification. In 372 short, the BGP speaker's behavior towards such a peer should be as 373 otherwise defined for the BGP protocol, according to [BGP, BGP-DRAFT] 374 and any other extension supported by the BGP speaker. 376 As previously mentioned, the BGP speaker SHOULD always advertise the 377 Multisession capability in its OPEN message, even towards "backward 378 compatibility" peers. 380 If, in opening a BGP connection with such a peer, an OPEN which 381 includes the Multisession capability is received from the peer, then 382 the peer SHOULD be changed to "multisession" mode. How this is done 383 depends on whether the BGP speaker has already sent an OPEN or not -- 385 If the BGP speaker has not yet sent an OPEN to the peer, then the 386 connection MAY be continued in the "multisession" mode discussed 387 above, or it MAY be terminated and future connections to the peer 388 attempted in "multisession" mode. 390 If the BGP speaker has sent an OPEN to the peer, then the current 391 session SHOULD be terminated and future connections to the peer 392 attempted in "multisession" mode. 394 Use of techniques such as [BGP-DYN-CAP] for on-the-fly switching of 395 session modes are beyond the scope of this document. 397 6. State Machine 399 As mentioned under "accepting connections" above, this specification 400 modifies the BGP finite state machine, albeit in a backward- 401 compatible fashion. 403 In addition, note that one state machine is considered to exist for 404 each of the connections which may exist to a given peer. This 405 implies that, for example, any session flap dampening that may exist 406 is performed per session indetifier. 408 The specific state machine modifications to [BGP-DRAFT] Section 8.2.2 409 are as follows. 411 6.1. Modifications to Connect State and Active State 413 In the actions in response to the events Open Delay timer expires 414 [Event 12] and TCP connection succeeds [Event 16 or Event 17], an 415 OPEN is not sent and the state changes to WaitForOpen and not to 416 OpenSent. 418 6.2. Addition of WaitForOpen State, Deletion of OpenSent State 420 The WaitForOpen state is the same in all respects to OpenSent, except 421 for the action in response to reception of a valid OPEN message 422 [Event 19]. In that event, the local system sends an OPEN message 423 prior to sending a KEEPALIVE message. 425 The OpenSent state is deleted. All references to OpenSent are 426 replaced by references to WaitForOpen. 428 7. Discussion 430 Note that many BGP implementations already permit multiple sessions 431 to be used between a given pair of routers, typically by configuring 432 multiple IP addresses on each router and configuring each session to 433 be bound to a different IP address. The principal contribution of 434 this specification is to allow multiple sessions to be created 435 automatically, without additional configuration overhead or address 436 consumption. 438 The specification supports the simple case of one capability being used 439 as the session identifier and one connection per session identifier value. 440 It also permits connections be established based on the multiple 441 capabilties as a sessio identifier with multiple values per capability 442 grouped together per connection. 444 In the context of MP-BGP based connections, which we believe may be the 445 most prevalent use of this specification it permits supporting one 446 AFI/SAFI per connection, and also permits arbitrary grouping of AFI/SAFI 447 onto BGP connections. For such grouping to function pleasingly, both 448 peers participating in a connection need to agree on what AFI/SAFI 449 groupings will be used. If conflicting groupings are configured, the 450 connections may not establish, or more connections may be established 451 than were expected (in the degenerate case, one connection per AFI/SAFI 452 could be established despite configured groupings). We observe that 453 the potential for misbehavior in the presence of conflicting configuration 454 is not unusual in BGP, and that support for, and configuration of grouping 455 is purely optional. 457 8. Acknowledgements 459 To be supplied. 461 9. References 463 [BGP4] 464 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)," RFC 465 1771, March 1995. 467 [BGP-DRAFT] 468 Rekhter, Y., T. Li and S. Hares, "A Border Gateway Protocol 4 469 (BGP-4)," Work in Progress (draft-ietf-idr-bgp4-20), April 2003. 471 [MP-BGP] 472 Bates, T., R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol Exten- 473 sions for BGP-4," Work in Progress (draft-ietf-idr-rfc2858bis-03), 474 July 2003. 476 [BGP-GR] 477 Sangli, S., Y. Rekhter, R. Fernando, J. Scudder, E. Chen, "Graceful 478 Restart Mechanism for BGP," Work in Progress (draft-ietf-idr- 479 restart-06), January 2003. 481 [BGP-CAP] 482 Chandra, R., J. Scudder, "Capabilities Advertisement with BGP-4," 483 RFC 2842, May 2000. 485 [BGP-DYN-CAP] 486 Chen, E. and S. Sangli, "Dynamic Capability for BGP-4," Work in 487 Progress (draft-ietf-idr-dynamic-cap-03), December 2002. 489 10. Security Considerations 491 This document introduces no new security vulnerabilities to BGP or 492 other specifications referenced in this document. 494 11. IANA Considerations 496 TBD 498 12. Authors' Addresses 500 John G. Scudder 501 Cisco Systems, Inc. 502 100 S. Main Suite 200 503 Ann Arbor, MI 48104 504 Email: jgs@cisco.com 506 Chandra Appanna 507 Cisco Systems, Inc. 508 170 West Tasman Drive 509 San Jose, CA 95134 510 e-mail: achandra@cisco.com 512 13. Intellectual Property Statement 514 The IETF takes no position regarding the validity or scope of any 515 Intellectual Property Rights or other rights that might be claimed to 516 pertain to the implementation or use of the technology described in 517 this document or the extent to which any license under such rights 518 might or might not be available; nor does it represent that it has 519 made any independent effort to identify any such rights. Information 520 on the procedures with respect to rights in RFC documents can be 521 found in BCP 78 and BCP 79. 523 Copies of IPR disclosures made to the IETF Secretariat and any 524 assurances of licenses to be made available, or the result of an 525 attempt made to obtain a general license or permission for the use of 526 such proprietary rights by implementers or users of this 527 specification can be obtained from the IETF on-line IPR repository at 528 http://www.ietf.org/ipr. 530 The IETF invites any interested party to bring to its attention any 531 copyrights, patents or patent applications, or other proprietary 532 rights that may cover technology that may be required to implement 533 this standard. Please address the information to the IETF at 534 ietf-ipr@ietf.org. 536 14. Disclaimer of Validity 538 This document and the information contained herein 539 are provided on an "AS IS" basis and THE CONTRIBUTOR, THE 540 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE 541 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 542 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 543 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 544 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 545 OR FITNESS FOR A PARTICULAR PURPOSE. 547 15. Copyright Statement 549 Copyright (C) The Internet Society (2005). This document is subject 550 to the rights, licenses and restrictions contained in BCP 78, and except 551 as set forth therein, the authors retain all their rights.