And just to add just a little bit of fuel to this fire let me share that the base principle of BGP spec mandating to withdraw the routes when the session goes down could be in the glory of IETF soon a history :(

It started with the proposal to make BGP state "persistent": https://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-00

Now it got smoothed and improved a bit, but the effect is still the same - keep the routes and do not withdraw when session goes down: https://tools.ietf.org/html/draft-ietf-idr-long-lived-gr-00

Sure it is up to the operator discretion to enable it or not. But soon we can no longer blame such behaviour as violation of BGP RFC if this proceeds forward to formal RFC.

Hint: Max LLST value (24 bits in seconds) is over 194 days of prefix expiration not just mentioned here with dislike 5 hours or so :)

Best

R,.

On Thu, Sep 3, 2020 at 6:20 PM Mark Tinka <mark.tinka@seacom.com> wrote:

On 2/Sep/20 15:12, Baldur Norddahl wrote:

> I am not buying it. No normal implementation of BGP stays online,
> replying to heart beat and accepting updates from ebgp peers, yet
> after 5 hours failed to process withdrawal from customers.

A BGP RFC spec. is not the same thing as a vendor translating that spec.
into code. If it were, we'd never need this list.

Triple the effort when deployed and operated at scale.

Mark.