On Sat, Sep 02, 2017 at 04:27:03PM +0900, Randy Bush wrote: > > I am not sure what the issue here is. If I can tell my peering > > partner a recommended maximum prefix value for them to set on their > > side, surely I can configure that same value on my side as the upper > > outbound limit. > > which is why i do not tell peers a max count.
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. Most networks publish a baseline number via a rendezvous point like PeeringDB, this makes it easy to signal to larger groups what the recommended values are. > this stuff works for small isps, in the lab, ... but not at scale; > especially when you have isps as customers. i wish it did. In this context "small ISPs" may account for the majority of the target audience. It appears there are about 50,000 "origin only" ASNs [1], for the majority of those it'll be straightforward to decide on a sensible max-out value. BGP speaking CDN caching nodes are also low hanging fruit. But even for a network like NTT I can see benefits of a max-out limit in a number of scenarios. > bgp at scale is rather dynamic. i suspect your $dayjob's irr filters > being exact help a bit. Yes, BGP is dynamic, but these days a lot of the topology at the wholesale level has been firmly pinned down through mechanisms like 'peerlock' [2]. Speaking as an ISP for ISPs: NTT/2914 applies an inbound maximum-prefix limit on each and every EBGP session. Kind regards, Job [1]: http://bgp.potaroo.net/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2%2e0%2fbgp-as-term%2etxt&descr=Origin%20only%20ASes&ylabel=Origin%20only%20ASes&with=step [2]: http://instituut.net/~job/peerlock_manual.pdf
