Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0

Jakob,

> On 12.12.2020, at 15:07, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
> 
> No.

I guess, this may be the reason why we are having this conversation. ;-) This is why I am asking: Because from reading the RFC4271 Section 6.5 I would assume that not sending messages to the neighbor for HOLD TIME will *always* result in a HoldTimer_Expires event, that leads to a NOTIFICATION, release of all BGP resources, drop of TCP connection, … and no way to recover from that.

Cheers Christoph

-- 
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

> On 12.12.2020, at 15:07, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
> 
> No.
> 
> Regards,
> Jakob.
> 
> 
>> On Dec 12, 2020, at 6:01 AM, Christoph Loibl <c@tix.at> wrote:
>> 
>>  Hi,
>> 
>> Isn’t it save to assume that if a system cannot send any messages to its BGP-neighbor (for whatever reason) for HOLD TIME seconds, that the neighbor on the other side has by that time already declared the BGP session dead (is already “trying" to deliver a NOTIFICATION and has removed the routes from its RIB). If this is the case I see no point in trying to keep the session alive, because it will *always* sooner or later lead to a new session-setup + flapping routes. The BGP session (if the NOTIFICATION is queued) cannot recover from that state anymore (can it?) and is useless, even if there are chances that messages may get delivered later. 
>> 
>> Cheers Christoph
>> 
>> -- 
>> Christoph Loibl
>> c@tix.at <mailto:c@tix.at> | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at <http://www.nextlayer.at/>
>> 
>> 
>> 
>>> On 12.12.2020, at 10:22, Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>> wrote:
>>> 
>>> 
>>> I went back and reread the thread: 
>>> 
>>>    https://mailarchive.ietf.org/arch/msg/idr/q0Sx5d3zZjfOmOQ4lO2OZAHh9Lc/ <https://mailarchive.ietf.org/arch/msg/idr/q0Sx5d3zZjfOmOQ4lO2OZAHh9Lc/> 
>>> 
>>> Shouldn't it be better if we first ask implementations to provide show command/api to list all peers and min-max durations of TCP Window being 0 without actually doing any automagic RST/NOTIFICATION/FIN ? 
>>> 
>>> This could allow to better understand which peers are getting behind in their control plane and perhaps also allow to set the RST timer under such conditions by operator? If he chooses this to be equal to HOLD TIME so be it but I am not sure this would be universally an optimal choice. 
>>> 
>>> Along the same lines we should perhaps also list per BGP peer number of DUPLICATE ACKS, RETRANSMISSIONS etc ... 
>>> 
>>> Are there implementations already deployed in DFZ allowing such data to be displayed per each BGP peer ?
>>> 
>>> Thx,
>>> Robert.
>>> 
>>> _______________________________________________
>>> Idr mailing list
>>> Idr@ietf.org <mailto:Idr@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/idr
>> 
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr