Subject: Re: problem in collision strategy?

From: "Tom Petch" <[email-masked]>
Date: Thu, 12 Sep 2002 19:06:09 +0100

Interesting, fascinating even.
 
The two ends should implement the same Connection collision detection and arrive at the same conclusion.  The way I read it, both should retain the (TCP) connection initiated by the BGP speaker with the higher value of BGP Identifier; assuming that that is speaker 2, then 
This triggers the collision detection in speaker 2. As he still 
believes that connection 1 is established, he decides to close the connection 2 

is in error; speaker 2 should close the first connection just as speaker one has done.
 
Tom Petch, Network Consultant
[email-masked]

    -----Original Message-----
    From: [email-masked] <[email-masked]>
    To: BGP mailing list <[email-masked]>
    Date: 12 September 2002 15:38
    Subject: problem in collision strategy?
    
    <snip>
    (in the scenario below time progresses downwards) 

    +---------------+                  +---------------+ 
    ! BGP speaker A !                  ! BGP speaker B ! 
    ! 10.10.10.10   !------------------+ 10.10.11.11   ! 
    !               !                  !               ! 
    +---------------+                  +---------------+ 
             !          Setup TCP connection 1! 
             !===============================>! 
             !                                ! 

    BGP speaker 1 initiates a TCP connection towards speaker2 
    This action is successfull. 

             !   OPEN for connection 1        ! 
             !===============================>! 

    Speaker 1 being informed that the TCP is up, sends an OPEN 
    message for the connection he initiated. The OPEN message 
    is NOT yet treated by speaker 2. (probably speaker 2 is not 
    yet aware of the connection because he did not check the TCP 
    events ). 

    The states in BGP are: 
     Connection 1: Open Sent           Connection 1: idle? 

            !   Setup TCP connection 2        ! 
            !<================================! 
            !                                 ! 

    At this stage, speaker 2 also sets up a TCP connection to speaker A 
    (this happens before the BGP application of speaker 2 is 
    aware of the connection of speaker 1). 

            !       OPEN for connection 2     ! 
            !================================>! 

    Now BGP speaker 1, being informed of a new connection immediatelly 
    sends an OPEN message. On Speaker 2 we have either a slow TCP, a slow BGP 
    or a slow link in between (actually it was a test tool, so I do not know 
    really).but in any case it seems that the BGP states now became: 

    The states in BGP are: 
     Connection 1: Open Sent           Connection 1: idle? 
     Connection 1: Open Sent           Connection 2: idle? 

           !        OPEN for connection 1      ! 
           !<==================================! 
           !                                   ! 
           !        KEEPALIVE for connection 1 ! 
           !==================================>! 

    BGP speaker 2 'wakes up' and responds to connection 1. BGP speaker 1 
    who is reacting alert, sends a KEEPALIVE for connection 1 
    The states in BGP are: 
     Connection 1: Open confirm        Connection 1: see below 
     COnnection 1: Open Sent           Connection 2: ? 

    AT this stage, the collision detection mechanism starts in BGP 
    speaker 1. Since BGP speaker 2 has the highest id, speaker 1 decides 
    to tear down his original TCP connection (connection 1). 

           !   KEEPALIVE for connection 1   ! 
           !<===============================! 
      Connection 1: gone 
      COnnection 2 : Open Sent 

    In the mean time BGP speaker 2, not being aware of the fact that 
    speaker 1 closed the connection 1 wakes up again, and receives the 
    keealive from speaker 1 , sends back a keepalive and bring the 
    connection 1 in establsihed state.(note that on this keepalive will be 
    lost, as the connection is closed. 
                                       Connection 1: established 

    Also at this moment, BGP speaker 2 notices that connection 2 is up 
    and sends an OPEN mesage for connection 2, and trasitions to OPEN SENT 
                                       Connection 2: OPEN sent. 

          !        OPEN for connection 2        ! 
          !<====================================! 

    BGP speaker 2 then treats the OPEN mesage from speaker 1 (which arrived 
    quite some time ago, but was not treated until now). 
    for connection 2. 

    This triggers the collision detection in speaker 2. As he still 
    believes that connection 1 is established, he decides to close the connection 2 

    The end result is that both connection are cleared.

---

From: Susan Hares <[email-masked]>
Date: Thu, 12 Sep 2002 20:17:04 -0400

Tom:

Didn't the improved words and state machine (hares-statemt-02.txt)
and backoff draft fix this?  I thought you had agreed
to that earlier.

If it doesn't could you let me know:

         1) which document you are referencing
         2) what section and page
         3) What you think is wrong with the text.

I am very much looking for any holes in these specifications.

**Top Priority** is the FSM words.  I have always indicated that
the hares-statemt and hares-backoff-01 drafts are additional
documents which address why I think I've nailed the connection
code.

I think we've done the sequence below.  Can you give text and
explain to me why this is not done?

Sue

At 07:06 PM 9/12/2002 +0100, Tom Petch wrote:
>The two ends should implement the same Connection collision detection and 
>arrive at the same conclusion.  The way I read it, both should retain the 
>(TCP) connection initiated by the BGP speaker with the higher value of BGP 
>Identifier; assuming that that is speaker 2, then
><mailto:[email-masked]>[email-masked]
>>From: 
>><mailto:[email-masked]>[email-masked] 
>><<mailto:[email-masked]>[email-masked]>
>>To: BGP mailing list <<mailto:[email-masked]>[email-masked]>