> On Sep 2, 2017, at 12:41 PM, Job Snijders <j...@instituut.net> wrote: > > 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.
How has the Coloclue max-prefix method described worked out? This sounds pretty effective for this type of network. How often has manual intervention (beyond a pre-arranged manual override) been required? Theodore Baschak - AS395089 - Hextet Systems https://bgp.guru/ - https://hextet.net/ http://mbix.ca/ - http://mbnog.ca/
