BGPv4 INFORM Message August 2002 Gargi Nalawade Internet Draft John Scudder David Ward Document: draft-nalawade-bgp-inform-01.txt Cisco Systems Expires: December 2002 June 2002 BGPv4 INFORM message 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. 3. Abstract This document defines a new message type, the BGP INFORM message that communicates Informational data and operational warnings without resetting the peering session. Nalawade Internet Draft - Expires December 2002 1 BGPv4 INFORM Message August 2002 4. Table of Contents 1. Status of this Memo......................................1 2. Copyright Notice.........................................1 3. Abstract.................................................1 5. Introduction.............................................3 6...........................................................3 Definition of the BGP INFORM Message........................3 6.1. Event Codes.......................................4 6.1.1. Unspecified event...............................4 6.1.2. Recoverable UPDATE attribute error -- attribute discarded..............................................5 6.1.3. Recoverable UPDATE attribute error -- attribute fixed..................................................5 6.1.4. Too many routes -- routes discarded.............5 6.1.5 Attribute Overflow...............................5 6.1.6 Dampening routes.................................5 6.1.7 All routes undampened............................6 6.1.8 Graceful Restart Purge Timer Expired.............6 7. Operation................................................6 7.1.1. Sending an INFORM Message.......................6 7.1.2. Receiving an INFORM message.....................6 7.1.3. Implementation notes............................7 7.1.4. Capability......................................7 8. Security Considerations..................................8 9. Acknowledgements.........................................8 10. References..............................................8 11. Author's Addresses......................................8 12. Intellectual Property Statement.........................9 13. Full Copyright Statement................................9 14. Expiration Date........................................11 Nalawade Internet Draft - Expires December 2002 2 BGPv4 INFORM Message August 2002 5. Introduction Currently there is no mechanism available for two peers to communicate the occurrence of an event other than through a BGP NOTIFICATION Message. The problem is that a NOTIFICATION message resets the peering session. If a peer wants to gracefully recover from an error or wants to warn its peer about the occurrence of a BGP-related event, there is no mechanism available to do that. The proposed BGP INFORM message is a mechanism to inform a remote peer of an event without resetting the session. 6. Definition of the BGP INFORM Message The INFORM message is a BGP message with type TBD. An INFORM message may be sent to inform a peer of an error condition which is not serious enough to warrant the reset of the BGP peering session. Each INFORM message relates to a single event. To inform a peer about multiple events, multiple INFORM messages must be used. The INFORM message contains a 2-octet Event Code followed by one or more Data TLVs of the following form: +------------------------+ | Type (1 octet) | +------------------------+ | Length (2 octets) | +------------------------+ | Value (variable) | +------------------------+ This document defines TLVs summarized below: Type Name Length Value ---- ------ -------- ----- 1 Unspecified variable Unspecified Data Type. 2 String variable A text string whose length is given by the length field. Not null-terminated. 3 PDU variable A copy of the PDU which triggered Nalawade Internet Draft - Expires December 2002 3 BGPv4 INFORM Message August 2002 the INFORM message. May be truncated. 4 Attribute variable A copy of the path attribute which triggered the INFORM message. May be truncated. 5 Integer 4 A four-byte integer No TLV may appear in the INFORM message more than once. 6.1. Event Codes The Event Code provides structured information regarding the event which triggered the generation of the INFORM message. Events 0-32767 are well-known and are defined here (TBD IANA document). Events 32768-65535 are reserved for vendor- specific use. Well-known events are summarized in the table below, and subsequently described. Code Name ---- ---- 1 Unspecified event 2 Recoverable UPDATE attribute error -- attribute Discarded 3 Recoverable UPDATE attribute error -- attribute fixed 4 Too many routes -- routes discarded 5 Attribute Overflow 6 Dampening routes 7 All routes undampened 8 Graceful Restart purge timer expired In the descriptions below, the inclusion of certain TLVs is specified -- for example, an unspecified event should include a string describing the event. These constitute a minimum set that should be included -- any other applicable or useful TLV may also be included. 6.1.1. Unspecified event An event has occurred which is not described by any other event code. The String TLV should be included with a description of the event. Nalawade Internet Draft - Expires December 2002 4 BGPv4 INFORM Message August 2002 6.1.2. Recoverable UPDATE attribute error -- attribute discarded The attribute which caused the INFORM to be generated should be included in the Attribute TLV. The reason it was considered an error should be included in the String field of the data port of the packet. 6.1.3. Recoverable UPDATE attribute error -- attribute fixed The attribute which caused the INFORM to be generated should be included in the Attribute TLV. The reason it was considered an error and a description of the action taken to fix the problem should be included in the String field of the data port of the packet. Care should be taken not to fix attributes unless it can be unambiguously determined that doing so will not compromise the protocol's correctness. 6.1.4. Too many routes -- routes discarded The peer has sent more routes than the local BGP speaker's configured maximum. The local BGP speaker has discarded some of the routes received from the peer. The configured maximum value which was exceeded should be included in the Integer TLV. 6.1.5 Attribute Overflow This INFORM message may be sent any time a peer receives an UPDATE with an attribute value, e.g., community list [RFC1997] that must be truncated due to its length. The Attribute TLV should be included. 6.1.6 Dampening routes The remote peer has announced and withdrawn some prefix or prefixes too frequently and the local peer has applied dampening to some set of prefixes announced by the remote peer. This INFORM message should not be sent each time a prefix is dampened. Instead it should only be sent when the boundary from no dampened routes to any dampened routes has been crossed. Nalawade Internet Draft - Expires December 2002 5 BGPv4 INFORM Message August 2002 6.1.7 All routes undampened At some point in the past, the remote peer announced and withdrawn some prefix or prefixes too frequently and the local peer had applied dampening to some set of prefixes announced by the remote peer. This INFORM message should not be sent each time a prefix is undampened. Instead it should only be sent when the boundary from dampened routes to no dampened prefixes has been crossed. 6.1.8 Graceful Restart Purge Timer Expired This INFORM message is to be sent during a Graceful Restart event [BGP-GR] and the purge timer has expired, thus causing all routes from the remote peer to be purged from the forwarding table of the local peer. 7. Operation The following rules apply to the generation of INFORM messages: 7.1.1. Sending an INFORM Message A router may send an INFORM message to a peer upon detecting a normal or abnormal, non-critical condition during operation which needs to be communicated to the peer and which does not necessitate a session reset. A router may also send an INFORM message for a condition which does require a session reset, provided that the INFORM is followed by a NOTIFICATION message and session reset. The rate at which INFORM messages are generated must be rate- limited. A suggested default limit is 60 messages per minute. 7.1.2. Receiving an INFORM message On receiving an INFORM Message from a peer, the INFORM message should be logged and via locally determined means and brought to the attention of the routerâs operator. The means to do this are, however, outside the scope of this draft. Under all circumstances an implementation SHOULD NOT take any automated action upon receiving an INFORM message. Nalawade Internet Draft - Expires December 2002 6 BGPv4 INFORM Message August 2002 An implementation must be prepared to receive INFORM messages containing unrecognized TLVs or TLV subcodes. An implementation should handle recognized TLVs as normal and may log, silently drop, or otherwise handle unrecognized TLVs. It is not recommended that the reception of a malformed INFORM message be cause to generate a reply of an INFORM message. An implementation must not reset the session due to a malformed INFORM message. 7.1.3. Implementation notes An implementation must not assume that its generation of an INFORM message will result in any state change on the part of its peer. It is axiomatic that the INFORM message is for the peer's information only. Implementors should refrain from sending INFORM messages without good cause. Although use of an INFORM message is not as serious as sending a NOTIFICATION, nonetheless an INFORM should only be generated in response to a protocol error or other serious problem. Normal, expected protocol events should not be INFORMed. Examples of events for which generation of an INFORM would be inappropriate include the dampening of an individual flapping route, the impending expiration of a holdtime, or the suppression of a component of an aggregate. The INFORM should not be used as a blanket replacement for sending a notification and terminating the BGP session. The BGP protocol's correctness generally assumes that protocol errors will be handled by terminating the session. The decision not to terminate a session in response to an error condition should not be taken lightly or without careful and sober consideration. The INFORM should not be used inconunction with a NOTIFICATION message. Additional information that an implementor would like to send with a NOTIFICATION should be included in the TLV structure of that message type. 7.1.4. Capability A new Capability [BGP-CAP] code (TBD) is defined for interoperability with software that does not recognize the INFORM message. The INFORM message can be sent only to peers that have advertised this capability. Nalawade Internet Draft - Expires December 2002 7 BGPv4 INFORM Message August 2002 8. Security Considerations This extension to BGP does not change the underlying security issues. 9. Acknowledgements We would like to thank Russ White, Alvaro Retana and Chandrashekhar Appanna for their review of the document. The authors would also like to thank all the other reviewers that gave suggestions to this document. 10. References [BGP-4] Rekhter, Y. and T. Li (editors), "A Border Gateway Protocol 4 (BGP-4)", Internet Draft draft-ietf-idr-bgp4- 17.txt, January 2002. [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002. [BGP-GR] Chandra, R., Scudder, J., "Graceful Restart Mechanism for BGP", draft-ietf-idr-restart-05.txt, June 2002. [RFC1997] Chandra, R., Traina, P., Li, T., "BGP Communities Attribute", RFC1997, August 1996. 11. Author's Addresses Gargi Nalawade mailto:gargi@cisco.com John Scudder mailto:jgs@cisco.com David Ward mailto:dward@cisco.com Cisco Systems, Inc 170 West Tasman Drive San Jose, CA 95134 Nalawade Internet Draft - Expires December 2002 8 BGPv4 INFORM Message August 2002 12. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 13. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions Nalawade Internet Draft - Expires December 2002 9 BGPv4 INFORM Message August 2002 granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Nalawade Internet Draft - Expires December 2002 10 BGPv4 INFORM Message August 2002 14. Expiration Date This memo is filed as , and expires December, 2002. Nalawade Internet Draft - Expires December 2002 11