Re: [Idr] Fwd: New Version Notification for draft-spaghetti-idr-bgp-sendholdtimer-05.txt

[Robert Raszuk <[e-mail]>]

Thx for the example. Of course UPDATES work as KEEPALIVES, but this case
seems to be about not reading/draining either.

The current draft for adoption already recommends mangling with BGP State
Machine. If we go and solve it at TCP no change to BGP State Machine is
needed. So this is more than implementation choice.

- - -

So assume we bring the session back. Do we require manual UP ?

If this is RS who just restarted phone lines will likely get hot when 100s
of peers would need to jump to consoles and bring the session up calling IX
NOC to check what's going on .....

Thx,
R.






On Thu, Aug 4, 2022 at 8:50 PM heasley <[e-mail]> wrote:

> Thu, Aug 04, 2022 at 06:23:58PM +0200, Robert Raszuk:
> > So we are trying to drop a session towards the BGP peer who does not
> > respect basic RFC4271 obligation to drop the session when HOLD TIMER
> > expires. That to me is already marginal (read noise corner case).
>
> I hesitate to mention this, but a case for it to ignore a lack of reading
> KAs is that it has data that is readable - ie: there is data is in its
> socket's receive buffer.  If a speaker is heavily loaded, such as a
> booting RS, considering a non-empty receive buffer as requivalent to
> "KAs received" seems an entirely legitimate way to manage resources under
> load.
>
> How the draft addresses such a case, such as recommended values,  seems
> like something for post-adoption discussion.
>
> > Then we worry that LINUX TCP stack may have buggy implementation of
> > TCP_USER_TIMEOUT and instead of fixing it locally we dismiss this option.
>
> It being buggy is irrelevant - it need not be buggy and is also something
> that I can fix, which I can not fix the neighbor, only work-around.  The
> draft should not concentrate on a particular implementation's facilities
> to recognize the problem, different implementations do exist.
>