<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Detailed explanation can be found below. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><a href="https://blog.thousandeyes.com/centurylink-level-3-outage-analysis/">https://blog.thousandeyes.com/centurylink-level-3-outage-analysis/</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">NANOG <nanog-bounces+lguillory=reservetele.com@nanog.org> on behalf of Baldur Norddahl <baldur.norddahl@gmail.com><br>
<b>Date: </b>Wednesday, September 2, 2020 at 12:09 PM<br>
<b>To: </b>"nanog@nanog.org" <nanog@nanog.org><br>
<b>Subject: </b>Re: [outages] Major Level3 (CenturyLink) Issues<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><b><span style="font-size:12.0pt;font-family:"Courier New";color:black">*External Email: Use Caution*</span></b>
<o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">I believe someone on this list reported that updates were also broken. They could not add prepending nor modify communities.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Anyway I am not saying it cannot happen because clearly something did happen. I just don't believe it is a simple case of overload. There has to be more to it.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">ons. 2. sep. 2020 15.36 skrev Saku Ytti <<a href="mailto:saku@ytti.fi" target="_blank">saku@ytti.fi</a>>:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">On Wed, 2 Sep 2020 at 16:16, Baldur Norddahl <<a href="mailto:baldur.norddahl@gmail.com" target="_blank">baldur.norddahl@gmail.com</a>> wrote:<br>
<br>
> 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.<br>
<br>
I can imagine writing BGP implementation like this<br>
<br>
a) own queue for keepalives, which i always serve first fully<br>
b) own queue for update, which i serve second<br>
c) own queue for withdraw, which i serve last<br>
<br>
Why I might think this makes sense, is perhaps I just received from<br>
RR2 prefix I'm pulling from RR1, if I don't handle all my updates<br>
first, I'm causing outage that should not happen, because I already<br>
actually received the update telling I don't need to withdraw it.<br>
<br>
Is this the right way to do it? Maybe not, but it's easy to imagine<br>
why it might seem like a good idea.<br>
<br>
How well BGP works in common cases and how it works in pathologically<br>
scaled and busy cases are very different cases.<br>
<br>
I know that even in stable states commonly run vendors on commonly run<br>
hardware can take +2h to finish converging iBGP on initial turn-up.<br>
<br>
-- <br>
++ytti<o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</body>
</html>