[outages] Major Level3 (CenturyLink) Issues

Thu Sep 3 22:19:24 UTC 2020

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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200904/dd3ede44/attachment.html>