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

[Jeffrey Haas <[e-mail]>]

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.
> 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:
> 
>           - restarts the ConnectRetryTimer (with initial value),

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.

> 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?

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