<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Depending on what failure cases you actually see from your peers in the wild, I can see (at least as a thought experiment), a two-bucket solution - "transit" and "everyone else".  (Excluding downstream customers, who you obviously hold some responsibility for the hygiene of.)<br></blockquote><div><br></div><div>Although I didn't say it clearly, that's exactly what we do. The described 'bucket' logic is only applied to the 'everyone else' pile ; our transit stuff gets its own special care and feeding. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">How often do folks see a failure case that's "deaggregated something and announced you 1000 /24s, rather than the expected/configured 100 max", vs "fat-fingered being a transit provider, and announced you the global table"?<br></blockquote><div><br></div><div>I can count on one hand the number of times I can remember that a peer has gone on a deagg party and ran over limits. Maybe twice in the last 8 years? It's possible it's happened more that I'm not aware of. </div><div><br></div><div>We have additional protections in place for that second scenario. If a generic peer tries to send us a route with a transit provider in the as-path, we just toss the route on the floor. That protection has been much more useful than prefix limits IMO. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 18, 2021 at 11:37 AM <a href="mailto:tim@pelican.org">tim@pelican.org</a> <<a href="mailto:tim@pelican.org">tim@pelican.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wednesday, 18 August, 2021 14:21, "Tom Beecher" <beecher@beecher.cc> said:<br>
<br>
> We created 5 or 6 different buckets of limit values (for v4 and v6 of<br>
> course.) Depending on what you have published in PeeringDB (or told us<br>
> directly what to expect), you're placed in a bucket that gives you a decent<br>
> amount of headroom to that bucket's max. If your ASN reaches 90% of your<br>
> limit, our ops folks just move you up to the next bucket. If you start to<br>
> get up there in the last bucket, then we'll take a manual look and decide<br>
> what is appropriate. This covers well over 95% of our non-transit sessions,<br>
> and has dramatically reduced the volume of tickets and changes our ops team<br>
> has had to sort through.<br>
<br>
Depending on what failure cases you actually see from your peers in the wild, I can see (at least as a thought experiment), a two-bucket solution - "transit" and "everyone else".  (Excluding downstream customers, who you obviously hold some responsibility for the hygiene of.)<br>
<br>
How often do folks see a failure case that's "deaggregated something and announced you 1000 /24s, rather than the expected/configured 100 max", vs "fat-fingered being a transit provider, and announced you the global table"?<br>
<br>
My gut says it's the latter case that breaks things and you need to make damn sure doesn't happen.  Curious to hear others' experience.<br>
<br>
Thanks,<br>
Tim.<br>
<br>
<br>
</blockquote></div>