Subject: Re: Draft bgp19 - issue #42 NOTIFICATION before OPEN

From: "Tom Petch" <[email-masked]>
Date: Tue, 28 Jan 2003 19:00:53 -0000

Isssue 42 queries whether or not we can send a NOTIFICATION when we
have not sucessfully exchanged OPENs.  I propose we should, following
the suggestions of Jeff and Yakov.

As Yakov suggested, this requires the removal of the second sentence,
first paragraph, of 4.2 which implies a NOTIFICATION can only be sent
after a succesful exchange of OPENs.  I think this fits best with the
other references to the uses of NOTIFICATION in the draft.

In terms of the FSM, it means that in Connect and Active states, on
receipt of events 20 or 21, we should send a NOTIFICATION so that the
last section starting

In response to any other event.............

is replaced by (and noting we have agreed to drop references to MIB
actions)

If the BGP message header checking or OPEN message
       checking detect an error (see Section 6.2) [Events 20 or 21],
the local system:
             - sends a NOTIFICATION message with the appropriate error
code,
             - resets the connect retry timer (sets to zero),
             - releases all BGP resources,
             - drops the TCP connection
             - increments the ConnectRetryCnt (connect retry count) by
1,
             - [optionally] performs peer oscillation damping
             - and goes to the Idle state.

  In response to any other event (Events 7-8, 10-11,18, 22-27), the
local system:
              - resets the connect retry timer (sets to zero),
              - releases all BGP resources,
              - drops the TCP connection,
              - increments the ConnectRetryCnt (connect retry count)
by one,
             - [optionally] performs peer oscillation damping,
              - and goes to the Idle state

(Note that this text is not quite watertight.  Suppose we are in
Active state, having been started with CRT running, receive an SYN
(event 13), send SYN-ACK and then get a malformed message (events
20/21).  We have not yet received an ACK and so should not send
anything over TCP; I would expect TCP to buffer this awaiting the ACK
except we then take down the TCP connection - or try to; I don't know
what happens next but regard it as sufficiently obscure not to be
concerned).

(My other concern is greater; why do we now not send NOTIFICATIONs for
other events; in Open Sent, Open Confirm or Established, we send one
for the 'default event list' so what makes events 20 and 21 in Active
and Connect so special?  I can justify the absence of a NOTIFICATION
for events 7, 8, 10, 11, 18, 22 since there is no evidence of a TCP
connection to send it on; but events 23-27 in Active or Connect say we
have received an erroneous message, the TCP connection is there so why
not send a NOTIFICATION?
       Event7:  Automatic stop
       Event8:  Idle hold timer expires
       Event10: Hold timer expires
       Event11: Keepalive timer expires
       Event18: BGPOpen
       Event22: Open collision dump
       Event23: NotifMsgVerErr
       Event24: NotifMsg
       Event25: KeepAliveMsg
       Event26: UpdateMsg
       Event27: UpdateMsgErr

Tom Petch
[email-masked]