Re: [Idr] BGP Message level ACKs

[Robert Raszuk <[e-mail]>]

Mikael at all,


> You're free to go work on this (I'm not opposed), but please don't hold up
> sendholdtimer in the meantime.


No - I do not intend to block anything. Just providing an alternative
approach for all of us to consider.

With that I spent a few minutes writing it up to better explain what I
really meant by BGP ACKs approach.

So here it is:

*PROBLEM SUMMARY:*

Operators reported that today some BGP implementations demonstrate no
reaction to missing BGP KEEPALIVES or BGP UPDATE MESSAGES over an extended
period of time. At the same time they still keep generating and sending BGP
KEEPALIVES or BGP UPDATE MESSAGES to the other side.

That results in a phenomenon called "stuck peer" where the healthy side of
the connection does not have a mechanism to bring such connection down -
resulting in possibly introducing a level of  routing inconsistency in the
network.

The other assumption here stated is that network connectivity between such
peers is healthy and TCP connection is also sound.

*DIAGNOSIS:*

The root of the stated problem is clearly in the buggy side of the BGP
session. However, today protocol does not have a way to detect it. Moreover
BGP KEEPALIVES generation and handling is very often separated from other
BGP processing. Smart implementations also try to offload BGP KEEPALIVE
processing to independent CPUs or perhaps even hardware (DPUs).

*PROPOSAL - BGP ENHANCED KEEPALIVES MESSAGE:*

When trying to explore solution space it appeared that what we are really
facing here is lack of acknowledgements sent by the BGP peer that he is
receiving our data.

While originally thought about generating and sending BGP ACK messages
after digesting input expressed on the list it appeared that for the
problem at hand it would be way too complex and involved extension.

Instead I would suggest defining the exact mirror of today's BGP KEEPALIVE
MESSAGE with only one difference - it is sent towards the peer only if the
RCV_PEER_MSG flag is set.

And let's make it up front cristal clear that this is NOT in any form or
shape REPLACEMENT of current BGP KEEPALIVES. It is envisioned that both can
operate in parallel - as both have different roles. Of course frequency of
both MAY and in fact SHOULD be different - so the multiplier (counter)
where peer may act if such BGP ENHANCED KEEPALIVES are missing.

By acting here it is RECOMMENDED to take a phased approach. After missing N
ENHANCED KEEPALIVES peer should be moved out of its current update/peer
group and declare to be slow peer. After missing N+X ENHANCED KEEPALIVES
BGP should inject syslog WARNING level message indicating that we are
dealing with stuck peer. After missing N+Y ENHANCED KEEPALIVES BGP should
close the session. The selection of number of missing messages in each step
as well as activating given step should be subject to local configuration.

Clearly we can almost fully reuse current BGP KEEPALIVES code for it - as
the only difference (as stated above) is conditional send when RCV_PEER_MSG
flag is set. And that flag (1 bit per peer) should be set every time we
receive any BGP message from the peer. Sending BGP ENHANCED KEEPALIVE MSG
resets the flag back to 0.

The frequency of BGP KEEPALIVE TIMER can be a fixed by the specification as
multiplier of negotiated BGP HOLD TIME VALUE. In addition BGP CAPABILITIES
MUST be used to signal it.


That's about it :) Simplicity !

Cheers,
Robert