### ----------------------------------------------------
### -- Net::BGP
### -- Licenses: Artistic-2.0
### -- Authors: Joelle Maslak
### -- File: rfc/rfc4271.txt
### ----------------------------------------------------
### -- Chunk 3 of 7
 be set to 0
   (Unspecific).

6.3.  UPDATE Message Error Handling

   All errors detected while processing the UPDATE message MUST be
   indicated by sending the NOTIFICATION message with the Error Code
   UPDATE Message Error.  The error subcode elaborates on the specific
   nature of the error.

   Error checking of an UPDATE message begins by examining the path
   attributes.  If the Withdrawn Routes Length or Total Attribute Length
   is too large (i.e., if Withdrawn Routes Length + Total Attribute
   Length + 23 exceeds the message Length), then the Error Subcode MUST
   be set to Malformed Attribute List.

   If any recognized attribute has Attribute Flags that conflict with
   the Attribute Type Code, then the Error Subcode MUST be set to
   Attribute Flags Error.  The Data field MUST contain the erroneous
   attribute (type, length, and value).





Rekhter, et al.             Standards Track                    [Page 32]

RFC 4271                         BGP-4                      January 2006


   If any recognized attribute has an Attribute Length that conflicts
   with the expected length (based on the attribute type code), then the
   Error Subcode MUST be set to Attribute Length Error.  The Data field
   MUST contain the erroneous attribute (type, length, and value).

   If any of the well-known mandatory attributes are not present, then
   the Error Subcode MUST be set to Missing Well-known Attribute.  The
   Data field MUST contain the Attribute Type Code of the missing,
   well-known attribute.

   If any of the well-known mandatory attributes are not recognized,
   then the Error Subcode MUST be set to Unrecognized Well-known
   Attribute.  The Data field MUST contain the unrecognized attribute
   (type, length, and value).

   If the ORIGIN attribute has an undefined value, then the Error Sub-
   code MUST be set to Invalid Origin Attribute.  The Data field MUST
   contain the unrecognized attribute (type, length, and value).

   If the NEXT_HOP attribute field is syntactically incorrect, then the
   Error Subcode MUST be set to Invalid NEXT_HOP Attribute.  The Data
   field MUST contain the incorrect attribute (type, length, and value).
   Syntactic correctness means that the NEXT_HOP attribute represents a
   valid IP host address.

   The IP address in the NEXT_HOP MUST meet the following criteria to be
   considered semantically correct:

      a) It MUST NOT be the IP address of the receiving speaker.

      b) In the case of an EBGP, where the sender and receiver are one
         IP hop away from each other, either the IP address in the
         NEXT_HOP MUST be the sender's IP address that is used to
         establish the BGP connection, or the interface associated with
         the NEXT_HOP IP address MUST share a common subnet with the
         receiving BGP speaker.

   If the NEXT_HOP attribute is semantically incorrect, the error SHOULD
   be logged, and the route SHOULD be ignored.  In this case, a
   NOTIFICATION message SHOULD NOT be sent, and the connection SHOULD
   NOT be closed.

   The AS_PATH attribute is checked for syntactic correctness.  If the
   path is syntactically incorrect, then the Error Subcode MUST be set
   to Malformed AS_PATH.






Rekhter, et al.             Standards Track                    [Page 33]

RFC 4271                         BGP-4                      January 2006


   If the UPDATE message is received from an external peer, the local
   system MAY check whether the leftmost (with respect to the position
   of octets in the protocol message) AS in the AS_PATH attribute is
   equal to the autonomous system number of the peer that sent the
   message.  If the check determines this is not the case, the Error
   Subcode MUST be set to Malformed AS_PATH.

   If an optional attribute is recognized, then the value of this
   attribute MUST be checked.  If an error is detected, the attribute
   MUST be discarded, and the Error Subcode MUST be set to Optional
   Attribute Error.  The Data field MUST contain the attribute (type,
   length, and value).

   If any attribute appears more than once in the UPDATE message, then
   the Error Subcode MUST be set to Malformed Attribute List.

   The NLRI field in the UPDATE message is checked for syntactic
   validity.  If the field is syntactically incorrect, then the Error
   Subcode MUST be set to Invalid Network Field.

   If a prefix in the NLRI field is semantically incorrect (e.g., an
   unexpected multicast IP address), an error SHOULD be logged locally,
   and the prefix SHOULD be ignored.

   An UPDATE message that contains correct path attributes, but no NLRI,
   SHALL be treated as a valid UPDATE message.

6.4.  NOTIFICATION Message Error Handling

   If a peer sends a NOTIFICATION message, and the receiver of the
   message detects an error in that message, the receiver cannot use a
   NOTIFICATION message to report this error back to the peer.  Any such
   error (e.g., an unrecognized Error Code or Error Subcode) SHOULD be
   noticed, logged locally, and brought to the attention of the
   administration of the peer.  The means to do this, however, lies
   outside the scope of this document.

6.5.  Hold Timer Expired Error Handling

   If a system does not receive successive KEEPALIVE, UPDATE, and/or
   NOTIFICATION messages within the period specified in the Hold Time
   field of the OPEN message, then the NOTIFICATION message with the
   Hold Timer Expired Error Code is sent and the BGP connection is
   closed.







Rekhter, et al.             Standards Track                    [Page 34]

RFC 4271                         BGP-4                      January 2006


6.6.  Finite State Machine Error Handling

   Any error detected by the BGP Finite State Machine (e.g., receipt of
   an unexpected event) is indicated by sending the NOTIFICATION message
   with the Error Code Finite State Machine Error.

6.7.  Cease

   In the absence of any fatal errors (that are indicated in this
   section), a BGP peer MAY choose, at any given time, to close its BGP
   connection by sending the NOTIFICATION message with the Error Code
   Cease.  However, the Cease NOTIFICATION message MUST NOT be used when
   a fatal error indicated by this section does exist.

   A BGP speaker MAY support the ability to impose a locally-configured,
   upper bound on the number of address prefixes the speaker is willing
   to accept from a neighbor.  When the upper bound is reached, the
   speaker, under control of local configuration, either (a) discards
   new address prefixes from the neighbor (while maintaining the BGP
   connection with the neighbor), or (b) terminates the BGP connection
   with the neighbor.  If the BGP speaker decides to terminate its BGP
   connection with a neighbor because the number of address prefixes
   received from the neighbor exceeds the locally-configured, upper
   bound, then the speaker MUST send the neighbor a NOTIFICATION message
   with the Error Code Cease.  The speaker MAY also log this locally.

6.8.  BGP Connection Collision Detection

   If a pair of BGP speakers try to establish a BGP connection with each
   other simultaneously, then two parallel connections well be formed.
   If the source IP address used by one of these connections is the same
   as the destination IP address used by the other, and the destination
   IP address used by the first connection is the same as the source IP
   address used by the other, connection collision has occurred.  In the
   event of connection collision, one of the connections MUST be closed.

   Based on the value of the BGP Identifier, a convention is established
   for detecting which BGP connection is to be preserved when a
   collision occurs.  The convention is to compare the BGP Identifiers
   of the peers involved in the collision and to retain only the
   connection initiated by the BGP speaker with the higher-valued BGP
   Identifier.

   Upon receipt of an OPEN message, the local system MUST examine all of
   its connections that are in the OpenConfirm state.  A BGP speaker MAY
   also examine connections in an OpenSent state if it knows the BGP
   Identifier of the peer by means outside of the protocol.  If, among
   these connections, there is a connection to a remote BGP speaker



Rekhter, et al.             Standards Track                    [Page 35]

RFC 4271                         BGP-4                      January 2006


   whose BGP Identifier equals the one in the OPEN message, and this
   connection collides with the connection over which the OPEN message
   is received, then the local system performs the following collision
   resolution procedure:

      1) The BGP Identifier of the local system is compared to the BGP
         Identifier of the remote system (as specified in the OPEN
         message).  Comparing BGP Identifiers is done by converting them
         to host byte order and treating them as 4-octet unsigned
         integers.

      2) If the value of the local BGP Identifier is less than the
         remote one, the local system closes the BGP connection that
         already exists (the one that is already in the OpenConfirm
         state), and accepts the BGP connection initiated by the remote
         system.

      3) Otherwise, the local system closes the newly created BGP
         connection (the one associated with the newly received OPEN
         message), and continues to use the existing one (the one that
         is already in the OpenConfirm state).

   Unless allowed via configuration, a connection collision with an
   existing BGP connection that is in the Established state causes
   closing of the newly created connection.

   Note that a connection collision cannot be detected with connections
   that are in Idle, Connect, or Active states.

   Closing the BGP connection (that results from the collision
   resolution procedure) is accomplished by sending the NOTIFICATION
   message with the Error Code Cease.

7.  BGP Version Negotiation

   BGP speakers MAY negotiate the version of the protocol by making
   multiple attempts at opening a BGP connection, starting with the
   highest version number each BGP speaker supports.  If an open attempt
   fails with an Error Code, OPEN Message Error, and an Error Subcode,
   Unsupported Version Number, then the BGP speaker has available the
   version number it tried, the version number its peer tried, the
   version number passed by its peer in the NOTIFICATION message, and
   the version numbers it supports.  If the two peers do support one or
   more common versions, then this will allow them to rapidly determine
   the highest common version.  In order to support BGP version
   negotiation, future versions of BGP MUST retain the format of the
   OPEN and NOTIFICATION messages.




Rekhter, et al.             Standards Track                    [Page 36]

RFC 4271                         BGP-4                      January 2006


8.  BGP Finite State Machine (FSM)

   The data structures and FSM described in this document are conceptual
   and do not have to be implemented precisely as described here, as
   long as the implementations support the described functionality and
   they exhibit the same externally visible behavior.

   This section specifies the BGP operation in terms of a Finite State
   Machine (FSM).  The section falls into two parts:

      1) Description of Events for the State machine (Section 8.1)
      2) Description of the FSM (Section 8.2)

   Session attributes required (mandatory) for each connection are:

      1) State
      2) ConnectRetryCounter
      3) ConnectRetryTimer
      4) ConnectRetryTime
      5) HoldTimer
      6) HoldTime
      7) KeepaliveTimer
      8) KeepaliveTime

   The state session attribute indicates the current state of the BGP
   FSM.  The ConnectRetryCounter indicates the number of times a BGP
   peer has tried to establish a peer session.

   The mandatory attributes related to timers are described in Section
   10.  Each timer has a "timer" and a "time" (the initial value).

   The optional Session attributes are listed below.  These optional
   attributes may be supported, either per connection or per local
   system:

      1) AcceptConnectionsUnconfiguredPeers
      2) AllowAutomaticStart
      3) AllowAutomaticStop
      4) CollisionDetectEstablishedState
      5) DampPeerOscillations
      6) DelayOpen
      7) DelayOpenTime
      8) DelayOpenTimer
      9) IdleHoldTime
     10) IdleHoldTimer
     11) PassiveTcpEstablishment
     12) SendNOTIFICATIONwithoutOPEN
     13) TrackTcpState



Rekhter, et al.             Standards Track                    [Page 37]

RFC 4271                         BGP-4                      January 2006


   The optional session attributes support different features of the BGP
   functionality that have implications for the BGP FSM state
   transitions.  Two groups of the attributes which relate to timers
   are:

      group 1: DelayOpen, DelayOpenTime, DelayOpenTimer
      group 2: DampPeerOscillations, IdleHoldTime, IdleHoldTimer

   The first parameter (DelayOpen, DampPeerOscillations) is an optional
   attribute that indicates that the Timer function is active.  The
   "Time" value specifies the initial value for the "Timer"
   (DelayOpenTime, IdleHoldTime).  The "Timer" specifies the actual
   timer.

   Please refer to Section 8.1.1 for an explanation of the interaction
   between these optional attributes and the events signaled to the
   state machine.  Section 8.2.1.3 also provides a short overview of the
   different types of optional attributes (flags or timers).

8.1.  Events for the BGP FSM

8.1.1.  Optional Events Linked to Optional Session Attributes

   The Inputs to the BGP FSM are events.  Events can either be mandatory
   or optional.  Some optional events are linked to optional session
   attributes.  Optional session attributes enable several groups of FSM
   functionality.

   The linkage between FSM functionality, events, and the optional
   session attributes are described below.

      Group 1: Automatic Administrative Events (Start/Stop)

         Optional Session Attributes: AllowAutomaticStart,
                                      AllowAutomaticStop,
                                      DampPeerOscillations,
                                      IdleHoldTime, IdleHoldTimer

         Option 1:    AllowAutomaticStart

         Description: A BGP peer connection can be started and stopped
                      by administrative control.  This administrative
                      control can either be manual, based on operator
                      intervention, or under the control of logic that
                      is specific to a BGP implementation.  The term
                      "automatic" refers to a start being issued to the
                      BGP peer connection FSM when such logic determines
                      that the BGP peer connection should be restarted.



Rekhter, et al.             Standards Track                    [Page 38]

RFC 4271                         BGP-4                      January 2006


                      The AllowAutomaticStart attribute specifies that
                      this BGP connection supports automatic starting of
                      the BGP connection.

                      If the BGP implementation supports
                      AllowAutomaticStart, the peer may be repeatedly
                      restarted.  Three other options control the rate
                      at which the automatic restart occurs:
                      DampPeerOscillations, IdleHoldTime, and the
                      IdleHoldTimer.

                      The DampPeerOscillations option specifies that the
                      implementation engages additional logic to damp
                      the oscillations of BGP peers in the face of
                      sequences of automatic start and automatic stop.
                      IdleHoldTime specifies the length of time the BGP
                      peer is held in the Idle state prior to allowing
                      the next automatic restart.  The IdleHoldTimer is
                      the timer that holds the peer in Idle state.

                      An example of DampPeerOscillations logic is an
                      increase of the IdleHoldTime value if a BGP peer
                      oscillates connectivity (connected/disconnected)
                      repeatedly within a time period.  To engage this
                      logic, a peer could connect and disconnect 10
                      times within 5 minutes.  The IdleHoldTime value
                      would be reset from 0 to 120 seconds.

         Values:      TRUE or FALSE

         Option 2:    AllowAutomaticStop

         Description: This BGP peer session optional attribute indicates
                      that the BGP connection allows "automatic"
                      stopping of the BGP connection.  An "automatic"
                      stop is defined as a stop under the control of
                      implementation-specific logic.  The
                      implementation-specific logic is outside the scope
                      of this specification.

         Values:      TRUE or FALSE

         Option 3:    DampPeerOscillations

         Description: The DampPeerOscillations optional session
                      attribute indicates that the BGP connection is
                      using logic that damps BGP peer oscillations in
                      the Idle State.



Rekhter, et al.             Standards Track                    [Page 39]

RFC 4271                         BGP-4                      January 2006


         Value:       TRUE or FALSE

         Option 4:    IdleHoldTime

         Description: The IdleHoldTime is the value that is set in the
                      IdleHoldTimer.

         Values:      Time in seconds

         Option 5:    IdleHoldTimer

         Description: The IdleHoldTimer aids in controlling BGP peer
                      oscillation.  The IdleHoldTimer is used to keep
                      the BGP peer in Idle for a particular duration.
                      The IdleHoldTimer_Expires event is described in
                      Section 8.1.3.

         Values:      Time in seconds

      Group 2: Unconfigured Peers

         Optional Session Attributes: AcceptConnectionsUnconfiguredPeers

         Option 1:    AcceptConnectionsUnconfiguredPeers

         Description: The BGP FSM optionally allows the acceptance of
                      BGP peer connections from neighbors that are not
                      pre-configured.  The
                      "AcceptConnectionsUnconfiguredPeers" optional
                      session attribute allows the FSM to support the
                      state transitions that allow the implementation to
                      accept or reject these unconfigured peers.

                      The AcceptConnectionsUnconfiguredPeers has
                      security implications.  Please refer to the BGP
                      Vulnerabilities document [RFC4272] for details.

         Value:       True or False

      Group 3: TCP processing

         Optional Session Attributes: PassiveTcpEstablishment,
                                      TrackTcpState

         Option 1:    PassiveTcpEstablishment






Rekhter, et al.             Standards Track                    [Page 40]

RFC 4271                         BGP-4                      January 2006


         Description: This option indicates that the BGP FSM will
                      passively wait for the remote BGP peer to
                      establish the BGP TCP connection.

         value:       TRUE or FALSE

         Option 2:    TrackTcpState

         Description: The BGP FSM normally tracks the end result of a
                      TCP connection attempt rather than individual TCP
                      messages.  Optionally, the BGP FSM can support
                      additional interaction with the TCP connection
                      negotiation.  The interaction with the TCP events
                      may increase the amount of logging the BGP peer
                      connection requires and the number of BGP FSM
                      changes.

         Value:       TRUE or FALSE

      Group 4:  BGP Message Processing

         Optional Session Attributes: DelayOpen, DelayOpenTime,
                                      DelayOpenTimer,
                                      SendNOTIFICATIONwithoutOPEN,
                                      CollisionDetectEstablishedState

         Option 1:     DelayOpen

         Description: The DelayOpen optional session attribute allows
                      implementations to be configured to delay sending
                      an OPEN message for a specific time period
                      (DelayOpenTime).  The delay allows the remote BGP
                      Peer time to send the first OPEN message.

         Value:       TRUE or FALSE

         Option 2:    DelayOpenTime

         Description: The DelayOpenTime is the initial value set in the
                      DelayOpenTimer.

         Value:       Time in seconds

         Option 3:    DelayOpenTimer

         Description: The DelayOpenTimer optional session attribute is
                      used to delay the sending of an OPEN message on a




Rekhter, et al.             Standards Track                    [Page 41]

RFC 4271                         BGP-4                      January 2006


                      connection.  The DelayOpenTimer_Expires event
                      (Event 12) is described in Section 8.1.3.

         Value:       Time in seconds

         Option 4:    SendNOTIFICATIONwithoutOPEN

         Description: The SendNOTIFICATIONwithoutOPEN allows a peer to
                      send a NOTIFICATION without first sending an OPEN
                      message.  Without this optional session attribute,
                      the BGP connection assumes that an OPEN message
                      must be sent by a peer prior to the peer sending a
                      NOTIFICATION message.

         Value:       True or False

         Option 5:    CollisionDetectEstablishedState

         Description: Normally, a Detect Collision (see Section 6.8)
                      will be ignored in the Established state.  This
                      optional session attribute indicates that this BGP
                      connection processes collisions in the Established
                      state.

         Value:       True or False

      Note: The optional session attributes clarify the BGP FSM
            description for existing features of BGP implementations.
            The optional session attributes may be pre-defined for an
            implementation and not readable via management interfaces
            for existing correct implementations.  As newer BGP MIBs
            (version 2 and beyond) are supported, these fields will be
            accessible via a management interface.

8.1.2.  Administrative Events

   An administrative event is an event in which the operator interface
   and BGP Policy engine signal the BGP-finite state machine to start or
   stop the BGP state machine.  The basic start and stop indications are
   augmented by optional connection attributes that signal a certain
   type of start or stop mechanism to the BGP FSM.  An example of this
   combination is Event 5, AutomaticStart_with_PassiveTcpEstablishment.
   With this event, the BGP implementation signals to the BGP FSM that
   the implementation is using an Automatic Start with the option to use
   a Passive TCP Establishment.  The Passive TCP establishment signals
   that this BGP FSM will wait for the remote side to start the TCP
   establishment.




Rekhter, et al.             Standards Track                    [Page 42]

RFC 4271                         BGP-4                      January 2006


   Note that only Event 1 (ManualStart) and Event 2 (ManualStop) are
   mandatory administrative events.  All other administrative events are
   optional (Events 3-8).  Each event below has a name, definition,
   status (mandatory or optional), and the optional session attributes
   that SHOULD be set at each stage.  When generating Event 1 through
   Event 8 for the BGP FSM, the conditions specified in the "Optional
   Attribute Status" section are verified.  If any of these conditions
   are not satisfied, then the local system should log an FSM error.

   The settings of optional session attributes may be implicit in some
   implementations, and therefore may not be set explicitly by an
   external operator action.  Section 8.2.1.5 describes these implicit
   settings of the optional session attributes.  The administrative
   states described below may also be implicit in some implementations
   and not directly configurable by an external operator.

      Event 1: ManualStart

         Definition: Local system administrator manually starts the peer
                     connection.

         Status:     Mandatory

         Optional
         Attribute
         Status:     The PassiveTcpEstablishment attribute SHOULD be set
                     to FALSE.

      Event 2: ManualStop

         Definition: Local system administrator manually stops the peer
                     connection.

         Status:     Mandatory

         Optional
         Attribute
         Status:     No interaction with any optional attributes.

      Event 3: AutomaticStart

         Definition: Local system automatically starts the BGP
                     connection.

         Status:     Optional, depending on local system






Rekhter, et al.             Standards Track                    [Page 43]

RFC 4271                         BGP-4                      January 2006


         Optional
         Attribute
         Status:     1) The AllowAutomaticStart attribute SHOULD be set
                        to TRUE if this event occurs.
                     2) If the PassiveTcpEstablishment optional session
                        attribute is supported, it SHOULD be set to
                        FALSE.
                     3) If the DampPeerOscillations is supported, it
                        SHOULD be set to FALSE when this event occurs.

      Event 4: ManualStart_with_PassiveTcpEstablishment

         Definition: Local system administrator manually starts the peer
                     connection, but has PassiveTcpEstablishment
                     enabled.  The PassiveTcpEstablishment optional
                     attribute indicates that the peer will listen prior
                     to establishing the connection.

         Status:     Optional, depending on local system

         Optional
         Attribute
         Status:     1) The PassiveTcpEstablishment attribute SHOULD be
                        set to TRUE if this event occurs.
                     2) The DampPeerOscillations attribute SHOULD be set
                        to FALSE when this event occurs.

      Event 5: AutomaticStart_with_PassiveTcpEstablishment

         Definition: Local system automatically starts the BGP
                     connection with the PassiveTcpEstablishment
                     enabled.  The PassiveTcpEstablishment optional
                     attribute indicates that the peer will listen prior
                     to establishing a connection.

         Status:     Optional, depending on local system

         Optional
         Attribute
         Status:     1) The AllowAutomaticStart attribute SHOULD be set
                        to TRUE.
                     2) The PassiveTcpEstablishment attribute SHOULD be
                        set to TRUE.
                     3) If the DampPeerOscillations attribute is
                        supported, the DampPeerOscillations SHOULD be
                        set to FALSE.





Rekhter, et al.             Standards Track                    [Page 44]

RFC 4271                         BGP-4                      January 2006


      Event 6: AutomaticStart_with_DampPeerOscillations

         Definition: Local system automatically starts the BGP peer
                     connection with peer oscillation damping enabled.
                     The exact method of damping persistent peer
                     oscillations is determined by the implementation
                     and is outside the scope of this document.

         Status:     Optional, depending on local system.

         Optional
         Attribute
         Status:     1) The AllowAutomaticStart attribute SHOULD be set
                        to TRUE.
                     2) The DampPeerOscillations attribute SHOULD be set
                        to TRUE.
                     3) The PassiveTcpEstablishment attribute SHOULD be
                        set to FALSE.

      Event 7: AutomaticStart_with_DampPeerOscillations_and_
      PassiveTcpEstablishment

         Definition: Local system automatically starts the BGP peer
                     connection with peer oscillation damping enabled
                     and PassiveTcpEstablishment enabled.  The exact
                     method of damping persistent peer oscillations is
                     determined by the implementation and is outside the
                     scope of this document.

         Status:     Optional, depending on local system

         Optional
         Attributes
         Status:     1) The AllowAutomaticStart attribute SHOULD be set
                        to TRUE.
                     2) The DampPeerOscillations attribute SHOULD be set
                        to TRUE.
                     3) The PassiveTcpEstablishment attribute SHOULD be
                        set to TRUE.

      Event 8: AutomaticStop

         Definition: Local system automatically stops the BGP
                     connection.

                     An example of an automatic stop event is exceeding
                     the number of prefixes for a given peer and the
                     local system automatically disconnecting the peer.



Rekhter, et al.             Standards Track                    [Page 45]

RFC 4271                         BGP-4                      January 2006


         Status:     Optional, depending on local system

         Optional
         Attribute
         Status:     1) The AllowAutomaticStop attribute SHOULD be TRUE.

8.1.3.  Timer Events

      Event 9: ConnectRetryTimer_Expires

         Definition: An event generated when the ConnectRetryTimer
                     expires.

         Status:     Mandatory

      Event 10: HoldTimer_Expires

         Definition: An event generated when the HoldTimer expires.

         Status:     Mandatory

      Event 11: KeepaliveTimer_Expires

         Definition: An event generated when the KeepaliveTimer expires.

         Status:     Mandatory

      Event 12: DelayOpenTimer_Expires

         Definition: An event generated when the DelayOpenTimer expires.

                     Status:     Optional

         Optional
         Attribute
         Status:     If this event occurs,
                     1) DelayOpen attribute SHOULD be set to TRUE,
                     2) DelayOpenTime attribute SHOULD be supported,
                     3) DelayOpenTimer SHOULD be supported.

      Event 13: IdleHoldTimer_Expires

         Definition: An event generated when the IdleHoldTimer expires,
                     indicating that the BGP connection has completed
                     waiting for the back-off period to prevent BGP peer
                     oscillation.





Rekhter, et al.             Standards Track                    [Page 46]

RFC 4271                         BGP-4                      January 2006


                     The IdleHoldTimer is only used when the persistent
                     peer oscillation damping function is enabled by
                     setting the DampPeerOscillations optional attribute
                     to TRUE.

                     Implementations not implementing the persistent
                     peer oscillation damping function may not have the
                     IdleHoldTimer.

         Status:     Optional

         Optional
         Attribute
         Status:     If this event occurs:
                     1) DampPeerOscillations attribute SHOULD be set to
                        TRUE.
                     2) IdleHoldTimer SHOULD have just expired.

8.1.4.  TCP Connection-Based Events

      Event 14: TcpConnection_Valid

         Definition: Event indicating the local system reception of a
                     TCP connection request with a valid source IP
                     address, TCP port, destination IP address, and TCP
                     Port.  The definition of invalid source and invalid
                     destination IP address is determined by the
                     implementation.

                     BGP's destination port SHOULD be port 179, as
                     defined by IANA.

                     TCP connection request is denoted by the local
                     system receiving a TCP SYN.

         Status:     Optional

         Optional
         Attribute
         Status:     1) The TrackTcpState attribute SHOULD be set to
                        TRUE if this event occurs.

      Event 15: Tcp_CR_Invalid

         Definition: Event indicating the local system reception of a
                     TCP connection request with either an invalid
                     source address or port number, or an invalid
                     destination address or port number.



Rekhter, et al.             Standards Track                    [Page 47]

RFC 4271                         BGP-4                      January 2006


                     BGP destination port number SHOULD be 179, as
                     defined by IANA.

                     A TCP connection request occurs when the local
                     system receives a TCP SYN.

         Status:     Optional

         Optional
         Attribute
         Status:     1) The TrackTcpState attribute should be set to
                        TRUE if this event occurs.

      Event 16: Tcp_CR_Acked

         Definition: Event indicating the local system's request to
                     establish a TCP connection to the remote peer.

                     The local system's TCP connection sent a TCP SYN,
                     received a TCP SYN/ACK message, and sent a TCP ACK.

         Status:     Mandatory

      Event 17: TcpConnectionConfirmed

         Definition: Event indicating that the local system has received
                     a confirmation that the TCP connection has been
                     established by the remote site.

                     The remote peer's TCP engine sent a TCP SYN.  The
                     local peer's TCP engine sent a SYN, ACK message and
                     now has received a final ACK.

         Status:     Mandatory

      Event 18: TcpConnectionFails

         Definition: Event indicating that the local system has received
                     a TCP connection failure notice.

                     The remote BGP peer's TCP machine could have sent a
                     FIN.  The local peer would respond with a FIN-ACK.
                     Another possibility is that the local peer
                     indicated a timeout in the TCP connection and
                     downed the connection.

         Status:     Mandatory




Rekhter, et al.             Standards Track                    [Page 48]

RFC 4271                         BGP-4                      January 2006


8.1.5.  BGP Message-Based Events

      Event 19: BGPOpen

         Definition: An event is generated when a valid OPEN message has
                     been received.

         Status:     Mandatory

         Optional
         Attribute
         Status:     1) The DelayOpen optional attribute SHOULD be set
                        to FALSE.
                     2) The DelayOpenTimer SHOULD not be running.

      Event 20: BGPOpen with DelayOpenTimer running

         Definition: An event is generated when a valid OPEN message has
                     been received for a peer that has a successfully
                     established transport connection and is currently
                     delaying the sending of a BGP open message.

         Status:     Optional

         Optional
         Attribute
         Status:     1) The DelayOpen attribute SHOULD be set to TRUE.
                     2) The DelayOpenTimer SHOULD be running.

      Event 21: BGPHeaderErr

         Definition: An event is generated when a received BGP message
                     header is not valid.

         Status:     Mandatory

      Event 22: BGPOpenMsgErr

         Definition: An event is generated when an OPEN message has been
                     received with errors.

         Status:     Mandatory

      Event 23: OpenCollisionDump

         Definition: An event generated administratively when a
                     connection collision has been detected while
                     processing an incoming OPEN message and this



Rekhter, et al.             Standards Track                    [Page 49]

RFC 4271                         BGP-4                      January 2006


                     connection has been selected to be disconnected.
                     See Section 6.8 for more information on collision
                     detection.

                     Event 23 is an administrative action generated by
                     implementation logic that determines whether this
                     connection needs to be dropped per the rules in
                     Section 6.8.  This event may occur if the FSM is
                     implemented as two linked state machines.

         Status:     Optional

         Optional
         Attribute
         Status:     If the state machine is to process this event in
                     the Established state,
                     1) CollisionDetectEstablishedState optional
                        attribute SHOULD be set to TRUE.

                     Please note: The OpenCollisionDump event can occur
                     in Idle, Connect, Active, OpenSent, and OpenConfirm
                     without any optional attributes being set.

      Event 24: NotifMsgVerErr

         Definition: An event is generated when a NOTIFICATION message
                     with "version error" is received.

         Status:     Mandatory

      Event 25: NotifMsg

         Definition: An event is generated when a NOTIFICATION message
                     is received and the error code is anything but
                     "version error".

         Status:     Mandatory

      Event 26: KeepAliveMsg

         Definition: An event is generated when a KEEPALIVE message is
                     received.

         Status:     Mandatory







Rekhter, et al.             Standards Track                    [Page 50]

RFC 4271                         BGP-4                      January 2006


      Event 27: UpdateMsg

         Definition: An event is generated when a valid UPDATE message
                     is received.

         Status:     Mandatory

      Event 28: UpdateMsgErr

         Definition: An event is generated when an invalid UPDATE
                     message is received.

         Status:     Mandatory

8.2.  Description of FSM

8.2.1.  FSM Definition

   BGP MUST maintain a separate FSM for each configured peer.  Each BGP
   peer paired in a potential connection will attempt to connect to the
   other, unless configured to remain in the idle state, or configured
   to remain passive.  For the purpose of this discussion, the active or
   connecting side of the TCP connection (the side of a TCP connection
   sending the first TCP SYN packet) is called outgoing.  The passive or
   listening side (the sender of the first SYN/ACK) is called an
   incoming connection.  (See Section 8.2.1.1 for information on the
   terms active and passive used below.)

   A BGP implementation MUST connect