On Sat, Sep 02, 2017 at 12:08:41PM -0400, Christopher Morrow wrote:
I think you'll find that some of your peers will make an educated guess and set an inbound limit anyway. Actively requesting that no limit is applied may make one part of a fringe minority.
This is a quick survey of your peers and setting the buckets from above at 'sane' limits, right?
yes
Speaking as an ISP for ISPs: NTT/2914 applies an inbound maximum-prefix limit on each and every EBGP session.
you can answer this if you want, or not.. but I'm curious, is this tuned-per-peer? or via some bucket form as I proposed above? I expect ntt COULD per-peer, since I think almost-all-config is auto-generated, but I'd be curious still if you decided at the bucket level instead because it's saner to think about it that way (for me anyway) or just went 'current +N%' for each peer?
I can contribute two examples: NTT (AS 2914): We use both approaches. For downstream customers a simple bucket system is used (currently with just one bucket: 31000 for IPv4, 2000 for IPv6). On the peering side of things the announcement count for each peer is polled at regular intervals and a +N% limit is set. In both approaches an override option is available in case someone emails the NOC "hey, we are about to turn up something big, can you ensure there is sufficient headroom". Coloclue (AS 8283): For every peering partner, data is fetched from the PeeringDB API and the fields visible here https://www.peeringdb.com/asn/2914 as 'IPv4 Prefixes' and 'IPv6 Prefixes' are used as input into the router configuration process. Coloclue's formula is simple, if the field's value is less than 100, set the limit to 100, if the value is over 100: add 10% to whatever value was published. This process is executed every 12 hours. In case no PDB record for the ASN exists: set 10,000 for IPv4 / 1,000 for IPv6. A manual override mechanism exists. If I compare the two: NTT's method emphasizes business continuity and has no external dependencies, Coloclue (being a network for experimentation) explores how to avoid explicit noc-to-noc coordination and relies on self-published data being kept up to date. Whatever your cooking method, maximum prefix limits should never get in the way of normal operations (e.g. organic growth), but exist only to try to nip obvious route leaks in the bud. This means one can be quite generous when picking values. Kind regards, Job