[Idr] RFC 4721 FSM - Clarification needed for optional attribute "PassiveTcpEstablishment"

[Deniz Bahadir <[e-mail]>]

Hello BGP-experts,

While re-reading the main BGP4 RFC (4271) and re-viewing my 
implementation (which I did some time ago) of the FSM described therein
I came across a question concerning the optional FSM-attribute 
"PassiveTcpEstablishment".

What is it really for?

My original interpretation of its meaning was, that it allows to 
configure the local BGP4-speaker to just listen for incoming connections 
from a BGP4-peer, instead of ever trying to actively initiate one.

I thought of this being a sensible interpretation as I could imagine 
some use-cases where it would be handy to just wait for incoming 
connections instead of trying to initiate one.

This would also comply with what was stated in its description. [1]

However, the description of the FSM-states made me rethink.

In state IDLE, if started with "PassiveTcpEstablishment enabled, via 
event 4 ("ManualStart_with_PassiveTcpEstablishment") or event 5 
("AutomaticStart_with_PassiveTcpEstablishment"), the FSM among other 
things starts the "ConnectRetryTimer" and transitions into state ACTIVE. [2]
Then, in state ACTIVE, the "ConnectRetryTimer" could run out and 
FSM-event 9 ("ConnectRetryTimer_Expires") would get triggered, which as 
a result _actively_ initiates a TCP-connection to the other BGP-peer and 
transitions into state CONNECT. [3]

So, if the FSM just has to wait long enough, it actively tries to 
initiate a TCP-connection whether "PassiveTcpEstablishment" was enabled 
or not.

So it seems, my original interpretation of the meaning of the optional 
FSM-attribute "PassiveTcpEstablishment" (as well as its description [1]) 
are not fully accurate.
Or the described handling of "ConnectRetryTimer_Expires" events in state 
ACTIVE [3] is missing some special behavior in case the 
"PassiveTcpEstablishment" is enabled.

Note: I wrote "special behavior" instead of "different behavior" because 
there might be some other ways to reach state ACTIVE and receive a 
"ConnectRetryTimer_Expires" event, even if started without 
"PassiveTcpEstablishment". E.g. by receiving event 18 
("TcpConnectionFails") in state CONNECT while the "DelayOpenTimer" was 
running, in which case the FSM would transition into state ACTIVE and 
could then receive the "ConnectRetryTimer_Expires" event. In that 
situation it would make sense to initiate a new TCP-connection to the 
peer and transition back to state CONNECT.

I hope, someone of you could clarify this situation and the meaning of 
"PassiveTcpEstablishment".

Thanks in advance,
Deniz Bahadir


References:

[1] Quote from pages 39 and 40, RFC 4271:

       Group 3: TCP processing

          Optional Session Attributes: PassiveTcpEstablishment,
                                       TrackTcpState

          Option 1:    PassiveTcpEstablishment

          Description: This option indicates that the BGP FSM will
                       passively wait for the remote BGP peer to
                       establish the BGP TCP connection.

          value:       TRUE or FALSE

          Option 2:    TrackTcpState
          [...]

[2] Quote from page 53, RFC 4271:

       In response to a ManualStart_with_PassiveTcpEstablishment event
       (Event 4) or AutomaticStart_with_PassiveTcpEstablishment event
       (Event 5), the local system:

         - initializes all BGP resources,

         - sets the ConnectRetryCounter to zero,

         - starts the ConnectRetryTimer with the initial value,

         - listens for a connection that may be initiated by the remote
           peer, and

         - changes its state to Active.

[3] Quote from page 59, RFC 4271:

       In response to a ConnectRetryTimer_Expires event (Event 9), the
       local system:

         - restarts the ConnectRetryTimer (with initial value),

         - initiates a TCP connection to the other BGP peer,

         - continues to listen for a TCP connection that may be initiated
           by a remote BGP peer, and

         - changes its state to Connect.

       The exact value of the ConnectRetryTimer is a local matter, but it
       SHOULD be sufficiently large to allow TCP initialization.


-- 
BENOCS GmbH
Dipl.-Inform. Deniz Bahadir
Winterfeldtstr. 21
10781 Berlin
Germany
Phone: +49 - 30 / 577 0004-22
Email: [e-mail]
www.benocs.com

Board of Management:
   Michael Wolz, Dr.-Ing. Oliver Holschke, Dr.-Ing. Ingmar Poese
Commercial Register: Amtsgericht Bonn HRB 19378