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

[Deniz Bahadir <[e-mail]>]

Jeffrey,

Am 20.10.2015 um 15:00 schrieb Jeffrey Haas:
>
> 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.

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.

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

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

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

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

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