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

From: Deniz Bahadir <[email-masked]>
Date: Mon, 19 Oct 2015 20:48:04 +0200

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: [email-masked]
www.benocs.com

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

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 19 Oct 2015 16:03:20 -0400

Deniz,

> "PassiveTcpEstablishment".

Caveat: RFC 4271 went out with small issues with the FSM.  Unfortunately I
lost my errata list while changing jobs.  Most are subtle things and require
actively listing all FSM states and transititions to find, but most people
implement some variation on the simpler mechanism from 1771 instead anyway.

There are two types of passive BGP peering that are common.
1. Configured peers that do not initiate outbound peering.  This is the
intended item in the FSM.
2. Peers that are configured via an allowed prefix range and not explicitly
configured.  This is not really in the FSM but is largely indistinguishable
from 1 with the exception that the FSM is intended to be per-peer and these
"allow" prefix ranges don't fit into the FSM model.

Passive peers do not actively try to establish outbound connections.  I
think you can reach the opposite conclusion from the current FSM text.

-- Jeff

---

From: Deniz Bahadir <[email-masked]>
Date: Tue, 20 Oct 2015 11:20:11 +0200

Jeffrey,

Am 19.10.2015 um 22:03 schrieb Jeffrey Haas:
> Passanywayive peers do not actively try to establish outbound connections.  I

Thank you for your clarification.

I think, I will then extend my implementation to incorporate "special 
behavior" for the case of "PassiveTcpEstablishment" being enabled.
I will implement it as if the paragraph for state ACTIVE in RFC 4271 
reads like this:

       In response to a ConnectRetryTimer_Expires event (Event 9), the
       local system checks the PassiveTcpEstablishment optional attribute
       prior to processing.

         If the PassiveTcpEstablishment attribute is set to TRUE, the
         local system:

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

           - stays in the Active state.

         If the PassiveTcpEstablishment attribute is set to FALSE, the
         local system:

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

Should I commit this as error-report? Or is it too technical and, 
because it changes the behavior described in the RFC, would be rejected 
anyway?

Deniz

Board of Management:

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 20 Oct 2015 09:00:48 -0400

Deniz,

On Tue, Oct 20, 2015 at 11:20:11AM +0200, Deniz Bahadir wrote:
> I think, I will then extend my implementation to incorporate
> "special behavior" for the case of "PassiveTcpEstablishment" being
> enabled.

The ConnectRetryTimer is intended to provide an upper bound to an outbound
TCP session that hasn't reached the established state.  In passive mode, no
outbound session should be happening and thus no timer should be started.

> because it changes the behavior described in the RFC, would be
> rejected anyway?

In IETF, correct technical errata are always worth reporting.  In this
specific case, the BGP state machine is complicated enough that I would
consider auditing the states to look for side effects needed for correct
functioning before filing such errata.  In this particular case, I think
this is simply wrong and the errata would be clear as noted above with the
connectretrytimer not being started when in passive mode.

It should be noted that the FSM doesn't really accommodate reconfiguration
events that may toggle flags such as passive, and thus excessive pedantry in
the specification will still not cover all possible changes.

-- Jeff

---

From: Deniz Bahadir <[email-masked]>
Date: Tue, 20 Oct 2015 16:16:58 +0200

Jeffrey,

> outbound session should be happening and thus no timer should be started.

If this is the intention of the ConnectRetryTimer then it probably 
should be mentioned in the RFC. I quickly searched through it but did 
not find a real definition of what this timer and its counter really 
should be used for.
To be fair, the name might be a hint to its intended meaning, but an 
explicit definition in the RFC would be more helpful.

However, if the ConnectRetryTimer should not be started/used when using 
PassiveTcpEstablishment why is it started in the first place when the 
FSM starts with event 4 (ManualStart_with_PassiveTcpEstablishment) or 
event 5 (AutomaticStart_with_PassiveTcpEstablishment)?

I guess, this is one of the several (minor) issues with the FSM you 
mentioned in your earlier email.

> connectretrytimer not being started when in passive mode.

Sounds quite complicated and time-consuming but I will try it, when I 
find some time for it.

> the specification will still not cover all possible changes.

Maybe it is time for an RFC revising and clarifying the BGP FSM (similar 
to RFC 7606)? ;-)
But I assume, that there will not be too much interest in it, as most 
(or all?) implementations work to satisfaction.

Thanks again,
Deniz

Board of Management: