Re: Max Prefix Out, was Re: Verizon 701 Route leak?

[Job Snijders <job () instituut net>]

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