idnits 2.17.1 draft-nalawade-bgp-inform-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 650 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. Abstract' ) ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 113 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([BGP-GR], [BGP-CAP], [RFC1997], [BGP-4]), 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 258: '... A router SHOULD NOT send an IN...' RFC 2119 keyword, line 259: '...ession reset. It SHOULD NOT be sent in...' RFC 2119 keyword, line 272: '... an implementation SHOULD NOT take any...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 133 has weird spacing: '...tribute varia...' -- 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 (August 2002) is 7925 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 section? 'RFC1997' on line 354 looks like a reference -- Missing reference section? 'BGP-GR' on line 351 looks like a reference -- Missing reference section? 'BGP-CAP' on line 347 looks like a reference -- Missing reference section? 'BGP-4' on line 343 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BGPv4 INFORM Message August 2002 4 Gargi Nalawade 5 Internet Draft John Scudder 6 David Ward 7 Document: draft-nalawade-bgp-inform-02.txt Cisco Systems 8 Expires: December 2002 June 2002 10 BGPv4 INFORM message 12 1. Status of this Memo 14 This document is an Internet-Draft and is in full conformance 15 with all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by 24 other documents at any time. It is inappropriate to use 25 Internet-Drafts as reference material or to cite them other 26 than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed 32 at http://www.ietf.org/shadow.html. 34 2. Copyright Notice 36 Copyright (C) The Internet Society (2001). All Rights 37 Reserved. 39 3. Abstract 41 This document defines a new message type, the BGP INFORM 42 message that communicates Informational data and operational 43 warnings without resetting the peering session. 45 Nalawade Internet Draft - Expires December 2002 1 47 BGPv4 INFORM Message August 2002 49 4. Table of Contents 51 1. Status of this Memo......................................1 52 2. Copyright Notice.........................................1 53 3. Abstract.................................................1 54 5. Introduction.............................................3 55 6...........................................................3 56 Definition of the BGP INFORM Message........................3 57 6.1. Event Codes.......................................4 58 6.1.1. Unspecified event...............................4 59 6.1.2. Recoverable UPDATE attribute error -- attribute 60 discarded..............................................5 61 6.1.3. Recoverable UPDATE attribute error -- attribute 62 fixed..................................................5 63 6.1.4. Too many routes -- routes discarded.............5 64 6.1.5 Attribute Overflow...............................5 65 6.1.6 Dampening routes.................................5 66 6.1.7 All routes undampened............................6 67 6.1.8 Graceful Restart Purge Timer Expired.............6 68 7. Operation................................................6 69 7.1.1. Sending an INFORM Message.......................6 70 7.1.2. Receiving an INFORM message.....................6 71 7.1.3. Implementation notes............................7 72 7.1.4. Capability......................................7 73 8. Security Considerations..................................8 74 9. Acknowledgements.........................................8 75 10. References..............................................8 76 11. Author's Addresses......................................8 77 12. Intellectual Property Statement.........................9 78 13. Full Copyright Statement................................9 79 14. Expiration Date........................................11 81 Nalawade Internet Draft - Expires December 2002 2 83 BGPv4 INFORM Message August 2002 85 5. Introduction 87 Currently there is no mechanism available for two peers to 88 communicate the occurrence of an event other than through a 89 BGP NOTIFICATION Message. The problem is that a NOTIFICATION 90 message resets the peering session. If a peer wants to 91 gracefully recover from an error or wants to warn its peer 92 about the occurrence of a BGP-related event, there is no 93 mechanism available to do that. The proposed BGP INFORM 94 message is a mechanism to inform a remote peer of an event 95 without resetting the session. 97 6. Definition of the BGP INFORM Message 99 The INFORM message is a BGP message with type TBD. An INFORM 100 message may be sent to inform a peer of an error condition 101 which is not serious enough to warrant the reset of the BGP 102 peering session. Each INFORM message relates to a single 103 event. To inform a peer about multiple events, multiple 104 INFORM messages must be used. 106 The INFORM message contains a 2-octet Event Code followed by 107 one or more Data TLVs of the following form: 109 +------------------------+ 110 | Type (1 octet) | 111 +------------------------+ 112 | Length (2 octets) | 113 +------------------------+ 114 | Value (variable) | 115 +------------------------+ 117 This document defines TLVs summarized below: 119 Type Name Length Value 120 ---- ------ -------- ----- 121 1 Unspecified variable Unspecified Data Type. 122 2 String variable A text string whose length is 123 given by the length field. Not 124 null-terminated. 125 3 PDU variable A copy of the PDU which triggered 127 Nalawade Internet Draft - Expires December 2002 3 129 BGPv4 INFORM Message August 2002 131 the INFORM message. May be 132 truncated. 133 4 Attribute variable A copy of the path attribute which 134 triggered the INFORM message. May 135 be truncated. 136 5 Integer 4 A four-byte integer 138 No TLV may appear in the INFORM message more than once. 140 6.1. Event Codes 142 The Event Code provides structured information regarding the 143 event which triggered the generation of the INFORM message. 145 Events 0-32767 are well-known and are defined here (TBD IANA 146 document). Events 32768-65535 are reserved for vendor- 147 specific use. 149 Well-known events are summarized in the table below, and 150 subsequently described. 152 Code Name 153 ---- ---- 154 1 Unspecified event 155 2 Recoverable UPDATE attribute error -- attribute 156 Discarded 157 3 Recoverable UPDATE attribute error -- attribute fixed 158 4 Too many routes -- routes discarded 159 5 Attribute Overflow 160 6 Dampening routes 161 7 All routes undampened 162 8 Graceful Restart purge timer expired 164 In the descriptions below, the inclusion of certain TLVs is 165 specified -- for example, an unspecified event should include 166 a string describing the event. These constitute a minimum 167 set that should be included -- any other applicable or useful 168 TLV may also be included. 170 6.1.1. Unspecified event 172 An event has occurred which is not described by any other 173 event code. The String TLV should be included with a 174 description of the event. 176 Nalawade Internet Draft - Expires December 2002 4 178 BGPv4 INFORM Message August 2002 180 6.1.2. Recoverable UPDATE attribute error -- attribute discarded 182 The attribute which caused the INFORM to be generated should 183 be included in the Attribute TLV. The reason it was 184 considered an error should be included in the String field of 185 the data port of the packet. 187 6.1.3. Recoverable UPDATE attribute error -- attribute fixed 189 The attribute which caused the INFORM to be generated should 190 be included in the Attribute TLV. The reason it was 191 considered an error and a description of the action taken to 192 fix the problem should be included in the String field of the 193 data port of the packet. 195 Care should be taken not to fix attributes unless it can be 196 unambiguously determined that doing so will not compromise 197 the protocol's correctness. 199 6.1.4. Too many routes -- routes discarded 201 The peer has sent more routes than the local BGP speaker's 202 configured maximum. The local BGP speaker has discarded some 203 of the routes received from the peer. 205 The configured maximum value which was exceeded should be 206 included in the Integer TLV. 208 6.1.5 Attribute Overflow 210 This INFORM message may be sent any time a peer receives an 211 UPDATE with an attribute value, e.g., community list 212 [RFC1997] that must be truncated due to its length. The 213 Attribute TLV should be included. 215 6.1.6 Dampening routes 217 The remote peer has announced and withdrawn some prefix or 218 prefixes too frequently and the local peer has applied 219 dampening to some set of prefixes announced by the remote 220 peer. This INFORM message should not be sent each time a 221 prefix is dampened. Instead it should only be sent when the 222 boundary from no dampened routes to any dampened routes has 223 been crossed. 225 Nalawade Internet Draft - Expires December 2002 5 227 BGPv4 INFORM Message August 2002 229 6.1.7 All routes undampened 231 At some point in the past, the remote peer announced and 232 withdrawn some prefix or prefixes too frequently and the 233 local peer had applied dampening to some set of prefixes 234 announced by the remote peer. This INFORM message should not 235 be sent each time a prefix is undampened. Instead it should 236 only be sent when the boundary from dampened routes to no 237 dampened prefixes has been crossed. 239 6.1.8 Graceful Restart Purge Timer Expired 241 This INFORM message is to be sent during a Graceful Restart 242 event [BGP-GR] and the purge timer has expired, thus causing 243 all routes from the remote peer to be purged from the 244 forwarding table of the local peer. 246 7. Operation 248 The following rules apply to the generation of INFORM 249 messages: 251 7.1.1. Sending an INFORM Message 253 A router may send an INFORM message to a peer upon detecting 254 a normal or abnormal, non-critical condition during operation 255 which needs to be communicated to the peer and which does not 256 necessitate a session reset. 258 A router SHOULD NOT send an INFORM message for a condition 259 which requires a session reset. It SHOULD NOT be sent in 260 conjunction with a NOTIFICATION message. 262 The rate at which INFORM messages are generated must be rate- 263 limited. A suggested default limit is 60 messages per minute. 265 7.1.2. Receiving an INFORM message 267 On receiving an INFORM Message from a peer, the INFORM 268 message should be logged and via locally determined means and 269 brought to the attention of the router's operator. The means 270 to do this are, however, outside the scope of this draft. 272 Under all circumstances an implementation SHOULD NOT take any 273 automated action upon receiving an INFORM message (other than 274 logging or alerting the operator). 276 Nalawade Internet Draft - Expires December 2002 6 278 BGPv4 INFORM Message August 2002 280 An implementation must be prepared to receive INFORM messages 281 containing unrecognized TLVs or TLV subcodes. An 282 implementation should handle recognized TLVs as normal and 283 may log, silently drop, or otherwise handle unrecognized 284 TLVs. It is not recommended that the reception of a malformed 285 INFORM message be cause to generate a reply of an INFORM 286 message. An implementation must not reset the session due to 287 a malformed INFORM message. 289 7.1.3. Implementation notes 291 An implementation must not assume that its generation of an 292 INFORM message will result in any state change on the part of 293 its peer. It is axiomatic that the INFORM message is for the 294 peer's information only. 296 Implementors should refrain from sending INFORM messages 297 without good cause. Although use of an INFORM message is not 298 as serious as sending a NOTIFICATION, nonetheless an INFORM 299 should only be generated in response to a protocol error or 300 other serious problem. Normal, expected protocol events 301 should not be INFORMed. Examples of events for which 302 generation of an INFORM would be inappropriate include the 303 dampening of an individual flapping route, the impending 304 expiration of a holdtime, or the suppression of a component 305 of an aggregate. 307 The INFORM should not be used as a blanket replacement for 308 sending a notification and terminating the BGP session. The 309 BGP protocol's correctness generally assumes that protocol 310 errors will be handled by terminating the session. The 311 decision not to terminate a session in response to an error 312 condition should not be taken lightly or without careful and 313 sober consideration. It is noted that it is possible for a 314 NOTIFICATION message to carry arbitrary data, so if the session 315 is to be terminated, any relevant data may be carried in the 316 NOTIFICATION message itself. 318 7.1.4. Capability 320 A new Capability [BGP-CAP] code (TBD) is defined for 321 interoperability with software that does not recognize the 322 INFORM message. The INFORM message can be sent only to peers 323 that have advertised this capability. 325 Nalawade Internet Draft - Expires December 2002 7 327 BGPv4 INFORM Message August 2002 329 8. Security Considerations 331 This extension to BGP does not change the underlying security 332 issues. 334 9. Acknowledgements 336 We would like to thank Russ White, Alvaro Retana and 337 Chandrashekhar Appanna for their review of the document. The 338 authors would also like to thank all the other reviewers that 339 gave suggestions to this document. 341 10. References 343 [BGP-4] Rekhter, Y. and T. Li (editors), "A Border Gateway 344 Protocol 4 (BGP-4)", Internet Draft draft-ietf-idr-bgp4- 345 17.txt, January 2002. 347 [BGP-CAP] Chandra, R., Scudder, J., "Capabilities 348 Advertisement with BGP-4", draft-ietf-idr-rfc2842bis-02.txt, 349 April 2002. 351 [BGP-GR] Chandra, R., Scudder, J., "Graceful Restart 352 Mechanism for BGP", draft-ietf-idr-restart-05.txt, June 2002. 354 [RFC1997] Chandra, R., Traina, P., Li, T., "BGP Communities 355 Attribute", RFC1997, August 1996. 357 11. Author's Addresses 359 Gargi Nalawade 360 mailto:gargi@cisco.com 362 John Scudder 363 mailto:jgs@cisco.com 365 David Ward 366 mailto:dward@cisco.com 368 Cisco Systems, Inc 369 170 West Tasman Drive 370 San Jose, CA 95134 372 Nalawade Internet Draft - Expires December 2002 8 374 BGPv4 INFORM Message August 2002 376 12. Intellectual Property Statement 378 The IETF takes no position regarding the validity or scope of 379 any intellectual property or other rights that might be 380 claimed to pertain to the implementation or use of the 381 technology described in this document or the extent to which 382 any license under such rights might or might not be 383 available; neither does it represent that it has made any 384 effort to identify any such rights. Information on the 385 IETF's procedures with respect to rights in standards-track 386 and standards- related documentation can be found in BCP-11. 387 Copies of claims of rights made available for publication and 388 any assurances of licenses to be made available, or the 389 result of an attempt made to obtain a general license or 390 permission for the use of such proprietary rights by 391 implementors or users of this specification can be obtained 392 from the IETF Secretariat. 394 The IETF invites any interested party to bring to its 395 attention any copyrights, patents or patent applications, or 396 other proprietary rights which may cover technology that may 397 be required to practice this standard. Please address the 398 information to the IETF Executive 399 Director. 401 13. Full Copyright Statement 403 Copyright (C) The Internet Society (2001). All Rights 404 Reserved. 406 This document and translations of it may be copied and 407 furnished to others, and derivative works that comment on or 408 otherwise explain it or assist in its implementation may be 409 prepared, copied, published and distributed, in whole or in 410 part, without restriction of any kind, provided that the 411 above copyright notice and this paragraph are included on all 412 such copies and derivative works. However, this document 413 itself may not be modified in any way, such as by removing 414 the copyright notice or references to the Internet Society or 415 other Internet organizations, except as needed for the 416 purpose of developing Internet standards in which case the 417 procedures for copyrights defined in the Internet Standards 418 process must be followed, or as required to translate it into 419 languages other than English. The limited permissions 421 Nalawade Internet Draft - Expires December 2002 9 423 BGPv4 INFORM Message August 2002 425 granted above are perpetual and will not be revoked by the 426 Internet Society or its successors or assigns. This document 427 and the information contained herein is provided on an "AS 428 IS" basis and THE INTERNET SOCIETY AND THE INTERNET 429 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 430 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 431 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 432 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 433 PARTICULAR PURPOSE." 435 Nalawade Internet Draft - Expires December 2002 10 437 BGPv4 INFORM Message August 2002 439 14. Expiration Date 441 This memo is filed as , 442 and expires December, 2002. 444 Nalawade Internet Draft - Expires December 2002 11