Re: Collision detect [Re-Posting]

[Eric Leisheng Ji <[e-mail]>]

I think Sathya's idea is applicable. In our implementation of
BGP in company, we try to follow the RFC, but get a little 
lost there about the FSMs, for we use only one FSM and two
connections.  
So we still follow the RFC, but under the situation of
collision detection, the received Notification Packet are
just ignored. So it's equal to no sending this.
I didnt' get the previous emails on this question, but it
seems to me a problem how do we indicate the peer state 
under the picture of one FSM and two connections? we should
make sure the two connections dont race to set the FSM
peer state.

--Eric Ji


On Fri, 25 Jan 2002, Alex Zinin wrote:

> 
> Sathya,
> 
>   In fact, that was one of my concerns about the spec.
> 
>   Regardless of whether we stay with the two-FSMs based scheme
>   or move to two transport connections under one, I think
>   we should have a section on processing of incoming transport
>   connection (I actually have it in my version of the FSM I sent
>   to the list a while ago).
> 
>   From my knowledge, at least some major implementations do not
>   treat competing connections as different FSMs. Whether they
>   make the majority or not is something that we should probably
>   ask the WG chairs to check.
> 
> -- 
> Alex Zinin
> 
> Wednesday, January 23, 2002, 7:18:21 PM, Sathya Perla wrote:
> 
> 
> > I think the fundamental problem with Collision Detection is that the spec
> > assumes (without stating it explicitly) that there are two FSMs to deal with
> > the possible two transport connections between a pair of peers. This is
> > evident from the usage of "FSM Cease" to close a transport connection. 
> 
> > One could manage both the transport connections using the same FSM and after
> > the collision detect algorithm is run the "unwanted" transport connection
> > can be closed without requiring a "FSM Cease".
> 
> > If this is not OK, the draft should explicitly state that a separate FSM has
> > to be used for a second connection with the same peer.
> 
> > -Sathya
> 
> 
> > -----Original Message-----
> > From: Kunihiro Ishiguro [mailto:[e-mail]]
> > Sent: Wednesday, January 23, 2002 7:36 AM
> > To: Mathew Richardson
> > Cc: [e-mail]
> > Subject: Re: Collision detect
> 
> 
> >>t0: BoxA initiates TCP connection to BoxB (we'll call this connection 1)
> >>t0: BoxB initiates TCP connection to BoxA (we'll call this connection 2)
> >>t1: BoxA accepts incoming connection from BoxB
> >>t1: BoxB accepts incoming connection from BoxA
> >>t2: BoxA sends an Open message on connection 1
> >>t2: BoxB sends an Open message on connection 2
> 
> > When BoxA accept incoming connection 2 from BoxB, BoxA lookup
> > corresponding status and it is Connect for connection 1.  Here we have
> > a problem.  If BoxA decides which connection should be closed at this
> > moment, BoxB will do the same thing.  Then both connection will be
> > closed.  OK, to avoid this situation collision detect should be done
> > by Open message then take one of them based upon router-id.  (In my
> > very private opinion, if jitter is there this will not happen
> > frequently).  Until that time the both connections should be
> > maintained.
> 
> > BTW, here is my question, when BoxA sends an Open message to BoxB
> > (t2).  BoxA has two connections.  Connection 1 is OpenSent status.
> > Connection 2 will be Connect status.  But where connection 2 status
> > comes from?  Is that generated based upon Connection 1 status?  It is
> > very ambiguous in RFC and draft description.  Initially the peer has
> > only one status.  Some moment the peer has two connections and two
> > independent status.  Finally collision detect close one connection.
> > The status related the connection also goes away.
> 
> > When I implemented BGP this was the biggest obstacle to understand FSM
> > and collision detect.  Still description is not clear.  Should we fix
> > this also?
> 
>