[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

Gargi Nalawade
                 Internet Draft
John Scudder

David Ward
                 Document: draft-nalawade-bgp-inform-00.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.

           4. Table of Contents

              1. Status of this
Memo...............................................1






              Nalawade     Internet Draft - Expires December 2002
1
                                    BGPv4 INFORM Message
June 2002





              2. Copyright
Notice...................................................1
              3.
Abstract...........................................................1
              5.
Introduction.......................................................3
              6. Definition of the BGP INFORM
Message...............................3
                   6.1 Event
Codes..................................................4
                   6.1.1 Unspecified
event..........................................4
                   6.1.2 Unspecified event -- dropping
session......................5
                   6.1.3 Recoverable UPDATE attribute error --
attribute discarded..5
                   6.1.4 Recoverable UPDATE attribute error --
attribute fixed......5
                   6.1.5 Too many routes -- routes
discarded........................5
                   6.1.6 Too many routes -- dropping
session........................5
                   6.1.7 Attribute
Overflow.........................................6
                   6.1.8 Dampening
routes...........................................6
                   6.1.9 All routes
undampened......................................6
                   6.1.10 Graceful Restart Purge Timer
Expired......................6
              7.
Operation..........................................................6
                   7.1.1 Sending an INFORM
Message..................................6
                   7.1.2 Receiving an INFORM
message................................7
                   7.1.3 Implementation
notes.......................................7
                   7.1.4 Capability.................................................8

              8. Security
Considerations............................................8
              9.
Acknowledgements...................................................8
              10. Normative
References..............................................8
              13. Author's
Addresses................................................8
              14. Intellectual Property
Statement...................................9
              15. Full Copyright
Statement..........................................9
              16. Expiration
Date..................................................11




















              Nalawade     Internet Draft - Expires December 2002
2
                                    BGPv4 INFORM Message
June 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
June 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      Unspecified event -- dropping session
              3      Recoverable UPDATE attribute error ÷- attribute
                      discarded
              4      Recoverable UPDATE attribute error -- attribute fixed
              5      Too many routes -- routes discarded
              6      Too many routes -- dropping session
              7      Attribute Overflow
              8      Dampening routes
              9      All routes undampened
              10     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
June 2002






           6.1.2 Unspecified event -- dropping session

              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. It may be expected that this INFORM
              will be swiftly followed by a NOTIFICATION.  The NOTIFICATION
              may carry additional structured information in its own codes.
              This particular INFORM message may be seen as a way to
              include a string description with a NOTIFICATION message.

           6.1.3 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.4 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.5 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.6 Too many routes -- dropping session

              The peer has sent more routes than the local BGP speaker's
              configured maximum.  The local BGP speaker will drop the
              peering session.  It may be expected that this INFORM will be
              swiftly followed by a NOTIFICATION.






              Nalawade     Internet Draft - Expires December 2002
5
                                    BGPv4 INFORM Message
June 2002





              The configured maximum value which was exceeded should be
              included in the Integer TLV.

           6.1.7 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.8 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.

           6.1.9 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.10 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







              Nalawade     Internet Draft - Expires December 2002
6
                                    BGPv4 INFORM Message
June 2002





              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.

              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.






              Nalawade     Internet Draft - Expires December 2002
7
                                    BGPv4 INFORM Message
June 2002





              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.

           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.


           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.

           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





              Nalawade     Internet Draft - Expires December 2002
8
                                    BGPv4 INFORM Message
June 2002






              John Scudder
              mailto:jgs@cisco.com

              David Ward
              mailto:dward@cisco.com

              Cisco Systems, Inc
              170 West Tasman Drive
              San Jose, CA 95134




           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





              Nalawade     Internet Draft - Expires December 2002
9
                                    BGPv4 INFORM Message
June 2002





              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
              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
June 2002





           14. Expiration Date

              This memo is filed as <draft-nalawade-bgpv4-INFORM-00.txt>,
              and expires December, 2002.


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/