Re: [Idr] BGP Message level ACKs

[Claudio Jeker <[e-mail]>]

On Fri, Mar 10, 2023 at 12:34:08PM +0100, Robert Raszuk wrote:
> I don't really want to measure proposals in lines of code it takes to
> prototype it.
> 
> Your diff does not even expose any CLI or YANG model as an example :)

It is my diff everyone talks about. There was no need to add extra code
because both the last write time and the timers are already automatically
exposed. So there was no need to do any of that.
 
> In fact in respect to your draft you do not need a new per peer timer at
> all. What seems more than sufficient is just a simple counter to record how
> many messages BGP was not able to enqueue to a peer.
> 
> If it was not able to write 10 or 20 or 100 messages (KEEPALIVES or
> UPDATES) the effect would be the same as comparing each time message fails
> a timer value.

You realize that the output message queue of a BGP process grows to a
multiple 1000 messages during a full sync. So your suggestion will not
work. I don't understand this resistance against a new timer.
Every BGP implementation has some form of timer API implemented and
extending it should not be that complicated.

There is a reason why progress is measured as any byte sent during a
timeperiod. As I exlained already the goal here is not to have something as
precise as the HoldTimer which is re-triggered by any message. The goal is
to have something in place for the uncommon case that a system still sends
messages but refuses to accept messages. It is extra conservative to not
trigger too early (since that should happen via HoldTimer) or even worse
trigger when systems get busy because of larger network changes.
 
> See timer in HoldTime is needed as we need to send periodic keepalives and
> negotiate it with the peer. In your case you are not sending anything so no
> need for a timer based approach.

Not quite true, there are two timers running. The HoldTimer and the
KeepaliveTimer. One is to send KEEPALIVE packets and the other is used to
detect sessions that don't send any messages anymore.

-- 
:wq Claudio