Thus spake Chriztoffer Hansen (ch@ntrv.dk) on Wed, Aug 18, 2021 at 12:03:51PM +0200:
On Wed, 18 Aug 2021 at 11:33, Lars Prehn <lprehn@mpi-inf.mpg.de> wrote:
I guess for long standing peers one could just eyeball it, e.g., current prefix count + some safety margin. How does that work for new peers?
sadly, this is the state of the art.
If you have automation in place. Another approach is to count the received prefix. Store the counted value in a database. Based on the avg prefix count over X (time period). Add e.g. 10 - 25 % headroom over the avg prefix count and use the calculated value as the max-prefix limit?
PeeringDB data (sometimes or often?) be somewhat misleading (in contrast to actual avg prefix count) in the sense 'some' networks will input a value with headroom percentages already included.
Our code tries all 3: a) using the max values in peeringdb b) expand all the routes in the IRR record from peeringdb b.1) if no object is specified, try to guess if it's named ASnnnnn c) count the currently received prefixes Many times the values in peeringdb can be off, or increasingly this is a good warning not to peer with a negligent operator. For some peers 'b' can expand to a huge, unrealistic set (not always their fault), so if it's substantially larger than 'a' we throw it out. (c) has proven the most reliable. The count chosen then fits in the appropriate sized bin and given 30% headroom. The code compares all this and gives the user a warning that in proactive gets ignored for option 'c'. (For example we can override 'b' with a more appropriate object record in our provisioning db) Dale