Subject: FSM but FSM of what?

From: "Tom Petch" <[email-masked]>
Date: Sun, 15 Sep 2002 11:02:09 +0100

The business of what the FSM is the FSM of still nags me (I had a
problem with it when I first read BGP-17 and to some extent still
have).

I think it nags me most in connection collision detection.  This is
defined (bgp-17 s6.8) as taking place between the same pair of IP
addresses (so the TCP connections are differentiated by port numbers
as ever).  When the FSM says the new state after a collision should be
Idle (for the connection initiated by the lower value of BGP
Identifier), then that only applies to this connection (uniquely
identified by TCP protocol  and a source/destination duple of both IP
address and port number); the winning (different port number duple)
connection will go on to Established via OpenConfirm.

So clearly (to me) there are two FSM here, with the same pair of IP
addresses
but different port numbers ie we are defining the FSM of a particular
TCP connection.

But can that work in Idle state when we have no TCP connection, only a
putative one.

As ever, I raise this because I believe it is worth clarifying in so
far as we can.  IMHO, it also impacts the references to the need to
track
Transport Indicates while in OpenConfirm or Established.  The tracking
is of the same IP address pair with a different port number pair in a
(?)different FSM with the events coming from that FSM to our FSM to
cause our FSM to revert to Idle (or not as the case may be).  And this
is an area that grows more complex with the other drafts (currently
out of scope); so I want an unambiguous base to work from.

We could have a single FSM catering for multiple connections but I
think that that would be too complex to be useful.  So perhaps a
more explicit reference to the fact that we are processing a single
connection once that (TCP) connection has been established.

Like

"8 BGP FInite State Machine

This section specifies BGP operation - between a BGP speaker and its
peer over a single TCP connection - in terms of a Finite State Machine
(FSM).  Following is a brief summary ... "(as before)

Instead of just

"This section specifies BGP operation in terms of a Finite State
Machine (FSM).  Following is a brief summary ... "(as before).

A month ago I would have said transport connection instead of TCP
connection but I have been put right on that; I see BGP as TCP-based
as far as this draft is concerned.  And transport connection does then
make any reference to (TCP-specific) port numbers  ... err confusing?

Tom Petch
[email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Sep 2002 16:15:42 -0400

> but different port numbers ie we are defining the FSM of a particular

Does this clear things up at all?

   There is one FSM per connection.  Prior to determining what peer a
   connection is associated with there may be two connections for a
   given peer.  There should be no more than one connection per peer.
   The collision detection identifies the case where there is more
   than one connection per peer and provides guidance for which
   connection to get rid of.  When this occurs, the corresponding FSM
   for the connection that is closed should be disposed of.

> [email-masked]

I'm not sure which document containing an FSM we should be reading at
this point, but we could add the above paragraph if we need to
explicitly state that the extra connection and its FSM is disposed of
when a collision is detected.

When a TCP accept occurs, a connection is created and an FSM is
created.  Prior to the point where the peer associated with the
connection is known the FSM cannot be associated with a peer.  The
collision is a transient condition in which the rule of "one BGP
session per peer" is temporarily violated and then corrected.

Curtis