Subject: Re: Comments 21-30

From: "Tom Petch" <[email-masked]>
Date: Fri, 13 Dec 2002 22:29:23 -0000

Comments in-line on 23 and 29

Tom Petch
[email-masked]

-----Original Message-----
From: Jeffrey Haas <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: 12 December 2002 23:08
Subject: Re: Comments 21-30

>On Thu, Dec 05, 2002 at 04:21:00PM -0500, Susan Hares wrote:
>> 23) Handling events 20, 21 in the Connect State and Active State
>>
>> We need to consider the case where we receive events 20 (message
>> header error) and 21 (Open message error) when the delay timer is
>> running.
>>
>> Since the connection has been established at this point, we need to
>> send a Notification message and then terminate the connection.
>>
>> Alternative comments:
>>
>> 1) We have not sent an Open statement.
>> 2) Why do we have to send an Notification? I see no justification
>>    for it.
>>
>> Suggestion:
>> Do you have implementations that send notification?  Do
>> you know of others that don't.
>
>This points out a potential issue.
>From section 4.2 of -18:
>: 4.2 OPEN Message Format
>:
>:    After a TCP is established, the first message sent by each side
is an
>:    OPEN message. If the OPEN message is acceptable, a KEEPALIVE
message
>:    confirming the OPEN is sent back. Once the OPEN is confirmed,
UPDATE,
>:    KEEPALIVE, and NOTIFICATION messages may be exchanged.
>
>This text implies that NOTIFICATIONs can only be sent once we
>have sent an open and then a keepalive, generally meaning we're in
the
>Established state.
>
>Anyone suggestions for modifying the wording?
>
>Section 6.1 (Message header error) is one situation that implies
>that a NOTIFICATION can be sent without sending even an OPEN message.
>Note that since the base FSM implies that we send an OPEN message
>immediately when we have a completed trasnport connection, we SHOULD
>be in at least OpenSent.  However, the DelayOpen timer means that we
>MAY send a NOTIFICATION when we are in the Connect state.
>
>GateD, at least, will not send a NOTIFICATION without first sending
>an OPEN.
>
>We need to pick one: You can send NOTIFICATIONS before OPEN or before
>OPEN if the OpenDelay timer is running.  However, we MUST fix the
text
>above.

A NOTIFICATION without a preceding OPEN is rather hard to interpret;
it is the OPEN that gives the recipient what it needs to know about
its potential peer (Version, AS number, ID, options etc) so it makes
sense to send an OPEN even if it is followed by a NOTIFICATION to say
goodbye :-( as opposed to a KEEPALIVE which says hello:-).

But as ever, what is implemented?

>
>> =============================
>>
>> 26) Handling Event 17 in The connect state
>>
>> >  If the transport connection fails (timeout or transport
>> >  disconnect) [Event17], the local system:
>> >      - changes its state to Active.=20
>>
>> >If the transport connection fails when the BGP Open Delay timer is
>> > running, should we still be going into the Active state ?
>>
>> see mail thread on eventse 13-17
>
>In this particular case, I think the issue is separate from the
issues
>for events 13-17 since this isn't particular to how deep the BGP
>implementation meddles in the TCP implementation.
>
>If we are in the Connect state, because we have an incoming transport
>connection that has completed, but we have the OpenDelay timer
>running and the transport connection is closed, we can simply
>drop into Active after resetting the ConnectRetry timer and clearing
>the OpenDelay timer (if set/exists).  In the case of an unconfigured
>peer, we can discard the FSM instance.
>

Yup, makes sense to me

>> =========================================
>>
>> 29) Handling Event 2 in Active state
>>
>> >> A manual stop event[Event2], the local system:
>> >> - Sends a notification with a Cease,
>> >> - drops the Transport connection,=20
>> >
>> >These two actions are possible only if a transport connection had
=
>> > already been established. How about changing the text to
>> >
>> > % - If a transport connection had been successfully established
>> > % - Send a Notification with a Cease
>> > % - Drop the Transport Connection
>>
>> How about this text:
>>
>>  A manual stop event [Event 2], the local system
>> - Drop the TCP connection,
>> - Release all BGP resources,
>> - resets the connection retry timer [sets to zero],
>> - goes to Idle.
>
>I'm rather confused.  Under exactly what circumstances can we be
>in the Active state and have an active TCP connection at all?
>Ditto for having any BGP resources?
>
>Going to Idle is fine.
>
>
eg start with passive flag, TCP SYN received, SYN-ACK sent, ACK
received, Delay Open flag set and there we are.  Most events are now
possible either from a well-implemented remote peer or a badly
implemented remote peer.

>--
>Jeff Haas
>NextHop Technologies