FSM but FSM of what?

["Tom Petch" <[e-mail]>]

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
[e-mail]