Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Eric Kuhnke]

I don't think that's a valid example at all since clearly the entity to
peer with for access to the BellMTS ASes and their customers is AS577.
Which definitely does peer and is present at IX points.

I am familiar with another entity which has an entire regional ILEC's AS
behind it, but where the newly created AS (part of the people who bought
the big chunk of ILEC) is present at many IX points and peers quite widely.

Was referring more to a theoretical example if somebody were to attempt to
build a medium to large sized ISP exclusively as a transit customer of some
top-50 CAIDA ASrank size transit providers, and do no peering whatsoever.

On Thu, Aug 19, 2021 at 3:05 PM Adam Thompson 
wrote:

> I have an example locally: BellMTS (ASNs 684, 7122, 4398), the local ILEC.
> To the best of my knowledge, they only peer with downstream customers
> (including myself) and their sole upstream, Bell Canada (AS577).  Meanwhile
> that's a ~700k eyeball network (with some hosting, sure), roughly ~400Gbps
> upstream connectivity, and no public peering whatsoever.  In fact, one
> might describe their peering model as "feudal", where they're subjugate to
> their corporate overlord (Bell Canada).
> It's unfortunate, I know there are some smart people working there, but
> either they don't understand the value of sub-1ms access to root
> nameservers (*cough* MBIX *cough*), or they're prevented from doing
> anything about it.
>
> [Disclaimer: I'm on the MBIX board.  But I also used to work for MTS, and
> tried to setup the first peering relationship but got shot down for
> "marketing" reasons, something about "legitimizing the competition".  Very
> monopolistic thinking, IMO.]
>
> Meanwhile, MTS still has a PeeringDB  record, even though it documents
> quite nicely the fact that perhaps that record shouldn't exist, or at least
> doesn't need to.
>
> FWIW, their upstream, Bell Canada, is a very different story.  And also
> mostly ~8msec away.
>
> -Adam
>
> *Adam Thompson*
> Consultant, Infrastructure Services
> [image: 1593169877849]
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca
> www.merlin.mb.ca
>
> --
> *From:* NANOG  on behalf
> of Eric Kuhnke 
> *Sent:* August 19, 2021 10:32
> *To:* Ben Maddison ; nanog@nanog.org list <
> nanog@nanog.org>
> *Subject:* Re: PeerinDB refuses to register certain networks [was:
> Setting sensible max-prefix limits]
>
> I agree with you in the utility of that, but sort of as a side topic...
>
> I wonder how many ASes are out there that have any significant volume of
> traffic/multi-site presences, but are exclusively 100% transit customers,
> do not have any PNIs at major carrier hotels, and are not members of any
> IX.
>
> What would be a good example of such an AS and how big of a network would
> it be? Undoubtedly there are some enterprise end user type customers set up
> like that, but I can't imagine they receive a very large volume of
> unsolicited peering requests.
>
> On Thu, Aug 19, 2021 at 6:32 AM Ben Maddison via NANOG 
> wrote:
>
> Hi Patrick,
>
> On 08/18, Patrick W. Gilmore wrote:
> > > Of course! Including headers to show authenticity. I was very amused
> by the
> > > explanation of the "chicken and egg" problem. Who's creating that? The
> networks
> > > who refuse to peer with non-peeringdb registered ASNs, or peeringdb
> who won't
> > > recognize ASNs that are not peering with anyone because nobody wants
> to peer
> > > with them because they are not registered in peeringdb because nobody
> wants to
> > > peer with them? You get the idea.
> >
> > First, most networks do not require a PDB record to peer. (Silly of
> > them, I know, but still true.)
> >
> > Second, you do not need to have a PDB record to get a link to an IXP.
> > Even membership in a free IXP is sufficient for an account in PDB, as
> > Grizz points out below.
> >
> > Third, if you have an agreement, even just an email, saying a network
> > will peer with you once you have a record, that may well suffice. Have
> > you asked any network to peer? Private peering (because you are not on
> > an IXP) is usually reserved for networks with more than a modicum of
> > traffic. If your network is large enough to qualify for private
> > peering, I have trouble believing you cannot get another network to
> > agree to peer so you can get a record.
> >
> > I guess you are right, the _Peering_DB does not register “certain”
> > networks. Those networks would be ones that do not peer. Which seems
> > pretty obvious

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Stefan Funke]

On 19.08.2021, at 22:39, Seth Mattinen  wrote:
> 
> 
> 
> On 8/19/21 11:19 AM, Ross Tajvar wrote:
>> I, and many others that I know, have successfully listed our networks in 
>> PeeringDB while having no peering. You may just need to try again.
> 
> 
> All of the argument is based around an email dated in *2015*. So yeah, try 
> again.

Every public AS (queried by RIR) is welcome and accepted. It is an automated 
process now. If you had trouble getting your ASN registered with PeeringDB in 
the past, try it again or get in contact with pdbs support.

-Stefan (pdb admin)

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Seth Mattinen]

On 8/19/21 11:19 AM, Ross Tajvar wrote:
I, and many others that I know, have successfully listed our networks in 
PeeringDB while having no peering. You may just need to try again.



All of the argument is based around an email dated in *2015*. So yeah, 
try again.

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Adam Thompson]

I have an example locally: BellMTS (ASNs 684, 7122, 4398), the local ILEC.
To the best of my knowledge, they only peer with downstream customers 
(including myself) and their sole upstream, Bell Canada (AS577).  Meanwhile 
that's a ~700k eyeball network (with some hosting, sure), roughly ~400Gbps 
upstream connectivity, and no public peering whatsoever.  In fact, one might 
describe their peering model as "feudal", where they're subjugate to their 
corporate overlord (Bell Canada).
It's unfortunate, I know there are some smart people working there, but either 
they don't understand the value of sub-1ms access to root nameservers (*cough* 
MBIX *cough*), or they're prevented from doing anything about it.

[Disclaimer: I'm on the MBIX board.  But I also used to work for MTS, and tried 
to setup the first peering relationship but got shot down for "marketing" 
reasons, something about "legitimizing the competition".  Very monopolistic 
thinking, IMO.]

Meanwhile, MTS still has a PeeringDB  record, even though it documents quite 
nicely the fact that perhaps that record shouldn't exist, or at least doesn't 
need to.

FWIW, their upstream, Bell Canada, is a very different story.  And also mostly 
~8msec away.

-Adam

Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca<mailto:athomp...@merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>


From: NANOG  on behalf of Eric 
Kuhnke 
Sent: August 19, 2021 10:32
To: Ben Maddison ; nanog@nanog.org list 

Subject: Re: PeerinDB refuses to register certain networks [was: Setting 
sensible max-prefix limits]

I agree with you in the utility of that, but sort of as a side topic...

I wonder how many ASes are out there that have any significant volume of 
traffic/multi-site presences, but are exclusively 100% transit customers, do 
not have any PNIs at major carrier hotels, and are not members of any IX.

What would be a good example of such an AS and how big of a network would it 
be? Undoubtedly there are some enterprise end user type customers set up like 
that, but I can't imagine they receive a very large volume of unsolicited 
peering requests.

On Thu, Aug 19, 2021 at 6:32 AM Ben Maddison via NANOG 
mailto:nanog@nanog.org>> wrote:
Hi Patrick,

On 08/18, Patrick W. Gilmore wrote:
> > Of course! Including headers to show authenticity. I was very amused by the
> > explanation of the "chicken and egg" problem. Who's creating that? The 
> > networks
> > who refuse to peer with non-peeringdb registered ASNs, or peeringdb who 
> > won't
> > recognize ASNs that are not peering with anyone because nobody wants to peer
> > with them because they are not registered in peeringdb because nobody wants 
> > to
> > peer with them? You get the idea.
>
> First, most networks do not require a PDB record to peer. (Silly of
> them, I know, but still true.)
>
> Second, you do not need to have a PDB record to get a link to an IXP.
> Even membership in a free IXP is sufficient for an account in PDB, as
> Grizz points out below.
>
> Third, if you have an agreement, even just an email, saying a network
> will peer with you once you have a record, that may well suffice. Have
> you asked any network to peer? Private peering (because you are not on
> an IXP) is usually reserved for networks with more than a modicum of
> traffic. If your network is large enough to qualify for private
> peering, I have trouble believing you cannot get another network to
> agree to peer so you can get a record.
>
> I guess you are right, the _Peering_DB does not register “certain”
> networks. Those networks would be ones that do not peer. Which seems
> pretty obvious to me - it is literally in the name.
>
A PDB record for an Internet-connected ASN, listing no IXPs or
facilities, but with a note saying approximately "We only use transit,
and don't peer" has some utility: it saves prospective peers from
finding contacts to ask and sending emails, etc.

I'd argue this is in scope for PDB. But perhaps there was additional
context to the original decision that I'm missing?

Cheers,

Ben

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Brielle]

On 8/19/21 12:19 PM, Ross Tajvar wrote:
I, and many others that I know, have successfully listed our networks in 
PeeringDB while having no peering. You may just need to try again.




Yup, can confirm I had no issues registering too and I've only got a 
pretty small setup these days.


Looks like its a pretty good resource when people have filled out their 
network details, esp the contact information for abuse, etc.



--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Ross Tajvar]

I, and many others that I know, have successfully listed our networks in
PeeringDB while having no peering. You may just need to try again.

On Wed, Aug 18, 2021, 5:53 PM Sabri Berisha  wrote:

> - On Aug 18, 2021, at 2:21 PM, Patrick W. Gilmore patr...@ianai.net
> wrote:
>
> Hi,
>
> > On Aug 18, 2021, at 5:00 PM, Matthew Walster 
> wrote:
> >> On Wed, 18 Aug 2021, 21:37 Sabri Berisha, 
> wrote:
> >> - On Aug 18, 2021, at 2:46 AM, Steve Lalonde st...@enta.net wrote:
> >>
> >> Hi,
> >>
> >>> > We always use PeeringDB data and refuse to peer with networks not in
> PeeingDB
> >>>
> >>> You are aware that PeerinDB refuses to register certain networks,
> right? It is
> >>> most certainly not a single source of truth.
> >>>
> >> Would you care to expand on this?
> >
> > I am extremely interested in hearing about this as well.
> >
> > Specific examples would be useful.
>
> Of course! Including headers to show authenticity. I was very amused by
> the
> explanation of the "chicken and egg" problem. Who's creating that? The
> networks
> who refuse to peer with non-peeringdb registered ASNs, or peeringdb who
> won't
> recognize ASNs that are not peering with anyone because nobody wants to
> peer
> with them because they are not registered in peeringdb because nobody
> wants to
> peer with them? You get the idea.
>
> Thanks,
>
> Sabri
> AS31064
>
>
> Return-Path: gr...@peeringdb.com
> Received: from mail.cluecentral.net (LHLO mail.cluecentral.net)
>  (195.16.84.32) by mail.cluecentral.net with LMTP; Fri, 9 Oct 2015
> 01:47:22
>  -0700 (PDT)
> Received: from localhost (localhost [127.0.0.1])
> by mail.cluecentral.net (Postfix) with ESMTP id 4CED64001EF
> for ; Fri,  9 Oct 2015 01:47:22 -0700 (PDT)
> Received: from mail.cluecentral.net ([127.0.0.1])
> by localhost (mail.cluecentral.net [127.0.0.1]) (amavisd-new,
> port 10024)
> with ESMTP id 3TLvVaNdjHGA for ;
> Fri,  9 Oct 2015 01:47:21 -0700 (PDT)
> Received: from ubersmith.peeringdb.com (ubersmith.peeringdb.com
> [107.6.74.106])
> by mail.cluecentral.net (Postfix) with ESMTP id C5B164001A9
> for ; Fri,  9 Oct 2015 01:47:01 -0700 (PDT)
> Received: by ubersmith.peeringdb.com (Postfix, from userid 48)
> id D8AF377C1A; Fri,  9 Oct 2015 04:46:29 -0400 (EDT)
> Date: Fri, 9 Oct 2015 04:46:29 -0400
> To: Sabri Berisha 
> From: supp...@peeringdb.com
> Reply-To: supp...@peeringdb.com
> Subject: Re: [#9192] [PeeringDB] User (sabri) Requesting Access (New
> Company - Cluecentral Inc)
> Message-ID: <1bac170d74e5d3702d3a28b237c87...@ubersmith.peeringdb.com>
>
> Dear PeeringDB user,
>
> Registering with peeringDB and peering negotiations are sort of egg and
> chicken problem. We only want to have networks registered that already
> do have settlement free peering.
>
> After some basic checks it looks like you are only buying transit from
> 6939/Hurricane Electric, but are not connected to any Internet Exchange
> (e.g. AMS-IX/NL-ix) yet.
>
> Having said this, is it acceptable to you to wait until you have your
> 1st settlement free peering setup? If you already have existing peering
> sessions, please provide the following details to support your request for
> peeringdb access:
>
> Your AS number(s)
> Which IXP / facilities you are peering at
> Some of your peering partners (again AS numbers / name)
>
> Please send your answers to supp...@peeringdb.com or reply to this ticket.
>
>
> Best regards,
> PeeringDB admin on Duty
>
>
> PeeringDB Listserv information:
>
> PeeringDB Announce:
> http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-announce
>
> PeeringDB Governance:
> http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-gov
>
> PeeringDB Technical:
> http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech
>
> PeeringDB User Discuss:
> http://lists.peeringdb.com/cgi-bin/mailman/listinfo/user-discuss
>
> --
> Florian Hibler 
> PeeringDB Administrator
>

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Eric Kuhnke]

I agree with you in the utility of that, but sort of as a side topic...

I wonder how many ASes are out there that have any significant volume of
traffic/multi-site presences, but are exclusively 100% transit customers,
do not have any PNIs at major carrier hotels, and are not members of any
IX.

What would be a good example of such an AS and how big of a network would
it be? Undoubtedly there are some enterprise end user type customers set up
like that, but I can't imagine they receive a very large volume of
unsolicited peering requests.

On Thu, Aug 19, 2021 at 6:32 AM Ben Maddison via NANOG 
wrote:

> Hi Patrick,
>
> On 08/18, Patrick W. Gilmore wrote:
> > > Of course! Including headers to show authenticity. I was very amused
> by the
> > > explanation of the "chicken and egg" problem. Who's creating that? The
> networks
> > > who refuse to peer with non-peeringdb registered ASNs, or peeringdb
> who won't
> > > recognize ASNs that are not peering with anyone because nobody wants
> to peer
> > > with them because they are not registered in peeringdb because nobody
> wants to
> > > peer with them? You get the idea.
> >
> > First, most networks do not require a PDB record to peer. (Silly of
> > them, I know, but still true.)
> >
> > Second, you do not need to have a PDB record to get a link to an IXP.
> > Even membership in a free IXP is sufficient for an account in PDB, as
> > Grizz points out below.
> >
> > Third, if you have an agreement, even just an email, saying a network
> > will peer with you once you have a record, that may well suffice. Have
> > you asked any network to peer? Private peering (because you are not on
> > an IXP) is usually reserved for networks with more than a modicum of
> > traffic. If your network is large enough to qualify for private
> > peering, I have trouble believing you cannot get another network to
> > agree to peer so you can get a record.
> >
> > I guess you are right, the _Peering_DB does not register “certain”
> > networks. Those networks would be ones that do not peer. Which seems
> > pretty obvious to me - it is literally in the name.
> >
> A PDB record for an Internet-connected ASN, listing no IXPs or
> facilities, but with a note saying approximately "We only use transit,
> and don't peer" has some utility: it saves prospective peers from
> finding contacts to ask and sending emails, etc.
>
> I'd argue this is in scope for PDB. But perhaps there was additional
> context to the original decision that I'm missing?
>
> Cheers,
>
> Ben
>

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Ben Maddison via NANOG]

Hi Patrick,

On 08/18, Patrick W. Gilmore wrote:
> > Of course! Including headers to show authenticity. I was very amused by the 
> > explanation of the "chicken and egg" problem. Who's creating that? The 
> > networks
> > who refuse to peer with non-peeringdb registered ASNs, or peeringdb who 
> > won't 
> > recognize ASNs that are not peering with anyone because nobody wants to 
> > peer 
> > with them because they are not registered in peeringdb because nobody wants 
> > to
> > peer with them? You get the idea.
> 
> First, most networks do not require a PDB record to peer. (Silly of
> them, I know, but still true.)
> 
> Second, you do not need to have a PDB record to get a link to an IXP.
> Even membership in a free IXP is sufficient for an account in PDB, as
> Grizz points out below.
> 
> Third, if you have an agreement, even just an email, saying a network
> will peer with you once you have a record, that may well suffice. Have
> you asked any network to peer? Private peering (because you are not on
> an IXP) is usually reserved for networks with more than a modicum of
> traffic. If your network is large enough to qualify for private
> peering, I have trouble believing you cannot get another network to
> agree to peer so you can get a record.
> 
> I guess you are right, the _Peering_DB does not register “certain”
> networks. Those networks would be ones that do not peer. Which seems
> pretty obvious to me - it is literally in the name.
> 
A PDB record for an Internet-connected ASN, listing no IXPs or
facilities, but with a note saying approximately "We only use transit,
and don't peer" has some utility: it saves prospective peers from
finding contacts to ask and sending emails, etc.

I'd argue this is in scope for PDB. But perhaps there was additional
context to the original decision that I'm missing?

Cheers,

Ben


signature.asc
Description: PGP signature

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Nick Hilliard]

Sabri Berisha wrote on 19/08/2021 00:57:

- On Aug 18, 2021, at 4:03 PM, Rubens kuhlrube...@gmail.com  wrote:

Hi,


Currently RPKI can only validate origin, not paths. If/when a path
validation solution is available, then one easy way to know that
network A really means to peer with network B is to publish a path
validation that B can use and/or forward A's announcements.

Yes, that would be a relatively easy thing to calculate.


if this were easy, we'd have solved the problem space years ago.  It's 
complicated because the description mechanism needs to be able to 
describe the complete set of all inter-as connectivity arrangements 
written in a language which is simple enough for people to be able to 
update it easily, which can be parsed by language interpreters 
relatively easily (allowing toolkits to be written / ), and which is 
flexible enough to output complex instructions including optimized 
regexps, routing metrics, etc, on a per-prefix, per-asn, 
per-interconnection point basis.  RPSL attempted these things and 
probably failed on all three points.  There have been some other 
attempts, but none came up with any usable outputs.


Nick

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Matthew Walster]

On Thu, 19 Aug 2021 at 02:03, Randy Bush  wrote:

> > The difference is, if you are able to use PeeringDB as a single
> > source of truth, it is a lot easier to grab the data you need.
>
> < pushing the analogy to the absurd >
>
> great idea!  please tell me when i can use peeringdb as the single
> source of truth for my bank balance?  how about i can learn your bank
> balance?
>
> < / >
>
> peeringdb has a mission, public exchange point documentation.  please
> don't get creepy.
>

Randy, your hyperbole helps no-one. Having been on Sabri's side of your
targeting before, I can attest it does little else than create veiled
anger. We are all friends here.

PeeringDB's mission, as stated on the front page, is:

PeeringDB is a freely available, user-maintained, database of networks, and
> the go-to location for interconnection data. The database facilitates the
> global interconnection of networks at Internet Exchange Points (IXPs), data
> centers, and other interconnection facilities, and is the first stop in
> making interconnection decisions.


The barrier to entry ought to be as low as possible, PeeringDB should
facilitate peering, not hinder it. Right now, I believe it is a force for
good. Where Sabri believes (based on a 6 year old email) a denial of
presence on the platform, it has degraded the utility of PeeringDB by not
allowing a network to advertise where it can be peered with -- something
that extensively happens between networks in LATAM outside of public IXPs
for example, which is why that statement above indicates it also
facilitates the interconnection of networks outside of IXPs. Whether that
is desirable or not is a topic for another day.

Matthew Walster

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Randy Bush]

> The difference is, if you are able to use PeeringDB as a single 
> source of truth, it is a lot easier to grab the data you need.

< pushing the analogy to the absurd >

great idea!  please tell me when i can use peeringdb as the single
source of truth for my bank balance?  how about i can learn your bank
balance?

< / >

peeringdb has a mission, public exchange point documentation.  please
don't get creepy.

randy

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Randy Bush]

> Currently RPKI can only validate origin, not paths.

not exactly  you ar speaking of route origin validation

RPKI

The RPKI is an X.509 based hierarchy [RFC 6481] which is congruent
with the internet IP address allocation administration, the IANA,
RIRs, ISPs, ...  It is just a database, but is the substrate on
which the next two mechanisms are based.  It is currently deployed
in all five administrative regions.

RPKI-based Origin Validation (ROV)

RPKI-based Origin Validation [RFC 6811] uses some of the RPKI data
to allow a router to verify that the autonomous system originating
an IP address prefix is in fact authorized to do so.  This is not
crypto checked so can be violated.  But it should prevent the vast
majority of accidental 'hijackings' on the internet today, e.g. the
famous Pakistani accidental announcement of YouTube's address space.
RPKI-based origin validation is in shipping code from AlcaLu, Cisco,
Juniper, and possibly others.

BGPsec

RPKI-based Path Validation, AKA BGPsec, a future technology still
being designed [draft-ietf-sidr-bgpsec-overview], uses the full
crypto information of the RPKI to make up for the embarrassing
mistake that, like much of the internet BGP was designed with no
thought to securing the BGP protocol itself from being
gamed/violated.  It allows a receiver of a BGP announcement to
cryptographically validate that the autonomous systems through which
the announcement passed were indeed those which the sender/forwarder
at each hop intended.

Sorry to drone on, but these three really need to be differentiated.

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Niels Bakker]

When did PeeringDB turn into a routing (policy) registry?
You should use an IRRdb if you want to write RPSL.


* sa...@cluecentral.net (Sabri Berisha) [Thu 19 Aug 2021, 01:59 CEST]:
The difference is, if you are able to use PeeringDB as a single 
source of truth, it is a lot easier to grab the data you need.


But again, their database, their rules.


So you were planning to abuse, er, creatively implement their 
datamodel to declare yourself an IXP and list all your peers as 
members of said IXP, and then convince the world to build filter 
lists based on said participant list?


Creative, but indeed not what PeeringDB is about.


-- Niels.

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Sabri Berisha]

- On Aug 18, 2021, at 4:03 PM, Rubens Kuhl rube...@gmail.com wrote:

Hi,

> Currently RPKI can only validate origin, not paths. If/when a path
> validation solution is available, then one easy way to know that
> network A really means to peer with network B is to publish a path
> validation that B can use and/or forward A's announcements.

Yes, that would be a relatively easy thing to calculate. 

Niels has, of course, a fair point when he writes:

> When did PeeringDB turn into a routing (policy) registry?
> You should use an IRRdb if you want to write RPSL.

The difference is, if you are able to use PeeringDB as a single 
source of truth, it is a lot easier to grab the data you need.

But again, their database, their rules.

Thanks,

Sabri

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Rubens Kuhl]

Currently RPKI can only validate origin, not paths. If/when a path
validation solution is available, then one easy way to know that
network A really means to peer with network B is to publish a path
validation that B can use and/or forward A's announcements.

Rubens

On Wed, Aug 18, 2021 at 7:53 PM Sabri Berisha  wrote:
>
> - On Aug 18, 2021, at 3:02 PM, Patrick W. Gilmore patr...@ianai.net wrote:
>
> Hi,
>
> > Those networks would be ones that do not peer. Which seems pretty obvious 
> > to me
> > - it is literally in the name.
>
> I have an AS, I advertise IP space to the world. I want to be a Good Netizen 
> and
> register my BGP peers. Your definition of BGP peering is different from mine, 
> at
> least in this context.
>
> > I guess you are right, the _Peering_DB does not register “certain” networks.
>
> Which was my point. I'm glad you agree. My little AS is not allowed to play 
> with
> the big kids.
>
> If you only want to register settlement-free peering, that's totally fine 
> with me.
> Your database, your rules.
>
> But, the fact stays that you can have an AS, advertise your prefixes to the 
> world,
> and not be permitted to register with peeringdb. Which means it can't be used 
> as
> a single source of truth. Which would have been a shame because with a little 
> bit
> of automation it would be feasible to "score" advertisements. That would help
> determine the likelihood of an advertisement to be erroneous (whether by 
> accident
> or malice).
>
> For example, if I were to register my peers (53356 and 136620) and AS5524 
> would
> all of a sudden start to advertise my AS as behind it, you'd be able to flag 
> that.
>
> But again, your database, your rules.
>
> Thanks,
>
> Sabri

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Niels Bakker]

* sa...@cluecentral.net (Sabri Berisha) [Thu 19 Aug 2021, 00:55 CEST]:

For example, if I were to register my peers (53356 and 136620) and AS5524 would
all of a sudden start to advertise my AS as behind it, you'd be able to flag 
that.


I'm confused. When did PeeringDB turn into a routing (policy) registry?
You should use an IRRdb if you want to write RPSL.


-- Niels.

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Sabri Berisha]

- On Aug 18, 2021, at 3:02 PM, Patrick W. Gilmore patr...@ianai.net wrote:

Hi,

> Those networks would be ones that do not peer. Which seems pretty obvious to 
> me
> - it is literally in the name.

I have an AS, I advertise IP space to the world. I want to be a Good Netizen and
register my BGP peers. Your definition of BGP peering is different from mine, at
least in this context.

> I guess you are right, the _Peering_DB does not register “certain” networks.

Which was my point. I'm glad you agree. My little AS is not allowed to play with
the big kids.

If you only want to register settlement-free peering, that's totally fine with 
me.
Your database, your rules.

But, the fact stays that you can have an AS, advertise your prefixes to the 
world,
and not be permitted to register with peeringdb. Which means it can't be used as
a single source of truth. Which would have been a shame because with a little 
bit
of automation it would be feasible to "score" advertisements. That would help 
determine the likelihood of an advertisement to be erroneous (whether by 
accident
or malice).

For example, if I were to register my peers (53356 and 136620) and AS5524 would 
all of a sudden start to advertise my AS as behind it, you'd be able to flag 
that. 

But again, your database, your rules.

Thanks,

Sabri

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Patrick W. Gilmore]

> Of course! Including headers to show authenticity. I was very amused by the 
> explanation of the "chicken and egg" problem. Who's creating that? The 
> networks
> who refuse to peer with non-peeringdb registered ASNs, or peeringdb who won't 
> recognize ASNs that are not peering with anyone because nobody wants to peer 
> with them because they are not registered in peeringdb because nobody wants to
> peer with them? You get the idea.

First, most networks do not require a PDB record to peer. (Silly of them, I 
know, but still true.)

Second, you do not need to have a PDB record to get a link to an IXP. Even 
membership in a free IXP is sufficient for an account in PDB, as Grizz points 
out below.

Third, if you have an agreement, even just an email, saying a network will peer 
with you once you have a record, that may well suffice. Have you asked any 
network to peer? Private peering (because you are not on an IXP) is usually 
reserved for networks with more than a modicum of traffic. If your network is 
large enough to qualify for private peering, I have trouble believing you 
cannot get another network to agree to peer so you can get a record.

I guess you are right, the _Peering_DB does not register “certain” networks. 
Those networks would be ones that do not peer. Which seems pretty obvious to me 
- it is literally in the name.

-- 
TTFN,
patrick

> On Aug 18, 2021, at 5:50 PM, Sabri Berisha  wrote:
> 
> - On Aug 18, 2021, at 2:21 PM, Patrick W. Gilmore patr...@ianai.net 
>  wrote:
> 
> Hi,
> 
>> On Aug 18, 2021, at 5:00 PM, Matthew Walster  wrote:
>>> On Wed, 18 Aug 2021, 21:37 Sabri Berisha,  wrote:
>>> - On Aug 18, 2021, at 2:46 AM, Steve Lalonde st...@enta.net wrote:
>>> 
>>> Hi,
>>> 
> We always use PeeringDB data and refuse to peer with networks not in 
> PeeingDB
 
 You are aware that PeerinDB refuses to register certain networks, right? 
 It is
 most certainly not a single source of truth.
 
>>> Would you care to expand on this?
>> 
>> I am extremely interested in hearing about this as well.
>> 
>> Specific examples would be useful.
> 
> Of course! Including headers to show authenticity. I was very amused by the 
> explanation of the "chicken and egg" problem. Who's creating that? The 
> networks
> who refuse to peer with non-peeringdb registered ASNs, or peeringdb who won't 
> recognize ASNs that are not peering with anyone because nobody wants to peer 
> with them because they are not registered in peeringdb because nobody wants to
> peer with them? You get the idea.
> 
> Thanks,
> 
> Sabri
> AS31064
> 
> 
> Return-Path: gr...@peeringdb.com 
> Received: from mail.cluecentral.net  (LHLO 
> mail.cluecentral.net )
> (195.16.84.32) by mail.cluecentral.net  with 
> LMTP; Fri, 9 Oct 2015 01:47:22
> -0700 (PDT)
> Received: from localhost (localhost [127.0.0.1])
>   by mail.cluecentral.net  (Postfix) with 
> ESMTP id 4CED64001EF
>   for mailto:sa...@cluecentral.net>>; Fri,  9 Oct 
> 2015 01:47:22 -0700 (PDT)
> Received: from mail.cluecentral.net  
> ([127.0.0.1])
>   by localhost (mail.cluecentral.net  
> [127.0.0.1]) (amavisd-new, port 10024)
>   with ESMTP id 3TLvVaNdjHGA for  >;
>   Fri,  9 Oct 2015 01:47:21 -0700 (PDT)
> Received: from ubersmith.peeringdb.com  
> (ubersmith.peeringdb.com  [107.6.74.106])
>   by mail.cluecentral.net  (Postfix) with 
> ESMTP id C5B164001A9
>   for mailto:sa...@cluecentral.net>>; Fri,  9 Oct 
> 2015 01:47:01 -0700 (PDT)
> Received: by ubersmith.peeringdb.com  
> (Postfix, from userid 48)
>   id D8AF377C1A; Fri,  9 Oct 2015 04:46:29 -0400 (EDT)
> Date: Fri, 9 Oct 2015 04:46:29 -0400
> To: Sabri Berisha mailto:sa...@cluecentral.net>>
> From: supp...@peeringdb.com 
> Reply-To: supp...@peeringdb.com 
> Subject: Re: [#9192] [PeeringDB] User (sabri) Requesting Access (New Company 
> - Cluecentral Inc)
> Message-ID: <1bac170d74e5d3702d3a28b237c87...@ubersmith.peeringdb.com 
> >
> 
> Dear PeeringDB user,
> 
> Registering with peeringDB and peering negotiations are sort of egg and
> chicken problem. We only want to have networks registered that already
> do have settlement free peering.
> 
> After some basic checks it looks like you are only buying transit from 
> 6939/Hurricane Electric, but are not connected to any Internet Exchange (e.g. 
> AMS-IX/NL-ix) yet.
> 
> Having said this, is it acceptable to you to wait until you have your
> 1st settlement free peering setup? If you already have 

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Sabri Berisha]

- On Aug 18, 2021, at 2:21 PM, Patrick W. Gilmore patr...@ianai.net wrote:

Hi,

> On Aug 18, 2021, at 5:00 PM, Matthew Walster  wrote:
>> On Wed, 18 Aug 2021, 21:37 Sabri Berisha,  wrote:
>> - On Aug 18, 2021, at 2:46 AM, Steve Lalonde st...@enta.net wrote:
>> 
>> Hi,
>> 
>>> > We always use PeeringDB data and refuse to peer with networks not in 
>>> > PeeingDB
>>> 
>>> You are aware that PeerinDB refuses to register certain networks, right? It 
>>> is
>>> most certainly not a single source of truth.
>>> 
>> Would you care to expand on this?
> 
> I am extremely interested in hearing about this as well.
> 
> Specific examples would be useful.

Of course! Including headers to show authenticity. I was very amused by the 
explanation of the "chicken and egg" problem. Who's creating that? The networks
who refuse to peer with non-peeringdb registered ASNs, or peeringdb who won't 
recognize ASNs that are not peering with anyone because nobody wants to peer 
with them because they are not registered in peeringdb because nobody wants to
peer with them? You get the idea.

Thanks,

Sabri
AS31064


Return-Path: gr...@peeringdb.com
Received: from mail.cluecentral.net (LHLO mail.cluecentral.net)
 (195.16.84.32) by mail.cluecentral.net with LMTP; Fri, 9 Oct 2015 01:47:22
 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by mail.cluecentral.net (Postfix) with ESMTP id 4CED64001EF
for ; Fri,  9 Oct 2015 01:47:22 -0700 (PDT)
Received: from mail.cluecentral.net ([127.0.0.1])
by localhost (mail.cluecentral.net [127.0.0.1]) (amavisd-new, port 
10024)
with ESMTP id 3TLvVaNdjHGA for ;
Fri,  9 Oct 2015 01:47:21 -0700 (PDT)
Received: from ubersmith.peeringdb.com (ubersmith.peeringdb.com [107.6.74.106])
by mail.cluecentral.net (Postfix) with ESMTP id C5B164001A9
for ; Fri,  9 Oct 2015 01:47:01 -0700 (PDT)
Received: by ubersmith.peeringdb.com (Postfix, from userid 48)
id D8AF377C1A; Fri,  9 Oct 2015 04:46:29 -0400 (EDT)
Date: Fri, 9 Oct 2015 04:46:29 -0400
To: Sabri Berisha 
From: supp...@peeringdb.com
Reply-To: supp...@peeringdb.com
Subject: Re: [#9192] [PeeringDB] User (sabri) Requesting Access (New Company - 
Cluecentral Inc)
Message-ID: <1bac170d74e5d3702d3a28b237c87...@ubersmith.peeringdb.com>

Dear PeeringDB user,

Registering with peeringDB and peering negotiations are sort of egg and
chicken problem. We only want to have networks registered that already
do have settlement free peering.

After some basic checks it looks like you are only buying transit from 
6939/Hurricane Electric, but are not connected to any Internet Exchange (e.g. 
AMS-IX/NL-ix) yet.

Having said this, is it acceptable to you to wait until you have your
1st settlement free peering setup? If you already have existing peering
sessions, please provide the following details to support your request for
peeringdb access:

Your AS number(s)
Which IXP / facilities you are peering at
Some of your peering partners (again AS numbers / name)

Please send your answers to supp...@peeringdb.com or reply to this ticket.


Best regards,
PeeringDB admin on Duty


PeeringDB Listserv information:

PeeringDB Announce: 
http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-announce

PeeringDB Governance:
http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-gov

PeeringDB Technical:
http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech

PeeringDB User Discuss:
http://lists.peeringdb.com/cgi-bin/mailman/listinfo/user-discuss

-- 
Florian Hibler 
PeeringDB Administrator

Re: Setting sensible max-prefix limits

[Jon Lewis]

On Wed, 18 Aug 2021, John Kristoff wrote:


On Wed, 18 Aug 2021 11:33:09 +0200
Lars Prehn  wrote:


As I understand by now, it is highly recommended to set a max-prefix
limit for peering sessions. Yet, I can hardly find any recommendations
on how to arrive at a sensible limit.


Maybe because there isn't a simple, universal approach to setting it.
Probably like a lot of people, historically I'd set it to
some % over the current stable count and then manually adjust when the
limits were about to be breached, or often was the case when they were
and I wasn't ready for it. Not ideal.


We tackled this problem at $work recently after I wrote some code to audit 
configured prefix-limits and found how inconsistent we were.  My guess 
was, this was due to combination of each engineer "doing their own thing" 
with regard to how to set prefix-limits based on what was published in 
peeringdb and growth (peers increasing the suggested limits over time, 
after we'd configured [some of] their sessions).


The solution I implemented was:

In the script that builds peering config, fetch the peer's suggested 
limits from peeringdb via API (I still miss the open mysql access).


Multiply those values by 2.

If that's too close to the "full table size", try suggested limits * 1.5.

If that's still too close to the "full table size", just use the suggested 
limits.



I've never felt the automation of this setting however was worth the
effort.  Of course I am not usually responsible for hundreds of routers
and thousands of peering sessions.


Yeah...that changes things when you have thousands of peering sessions to 
maintain.



At the risk of advocating for more junk in BGP or the RPKI, a max prefix
setting might be something that could be set by the announcing peer in
a BGP message, or possibly as an RPKI object with an associated ASN.


It actually sounds like a cool feature, and could be implemented entirely 
on the sender's side.  i.e. You configure a peer with a self-imposed limit 
of 1000 routes.  If you screw up your routing policy facing that peer and 
leak the full table, once you hit 1001 advertised routes, your router's 
BGP process terminates the session.


Who hasn't had a new peer leak full routes to them at least once?

Who hasn't configured a new peer, only to have them immediately trip your 
prefix-limit because they haven't updated peeringdb for "some time" and 
advertise more routes than their suggested limits?


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Patrick W. Gilmore]

On Aug 18, 2021, at 5:00 PM, Matthew Walster  wrote:
> On Wed, 18 Aug 2021, 21:37 Sabri Berisha,  wrote:
> - On Aug 18, 2021, at 2:46 AM, Steve Lalonde st...@enta.net wrote:
> 
> Hi,
> 
>> > We always use PeeringDB data and refuse to peer with networks not in 
>> > PeeingDB
>> 
>> You are aware that PeerinDB refuses to register certain networks, right? It 
>> is most certainly not a single source of truth.
>> 
> Would you care to expand on this?

I am extremely interested in hearing about this as well.

Specific examples would be useful.

-- 
TTFN,
patrick

Re: Setting sensible max-prefix limits

[Matthew Walster]

On Wed, 18 Aug 2021, 21:37 Sabri Berisha,  wrote:

> - On Aug 18, 2021, at 2:46 AM, Steve Lalonde st...@enta.net wrote:
>
> Hi,
>
> > We always use PeeringDB data and refuse to peer with networks not in
> PeeingDB
>
> You are aware that PeerinDB refuses to register certain networks, right?
> It is most certainly not a single source of truth.
>

Would you care to expand on this?

Matthew Walster

>

Re: Setting sensible max-prefix limits

[Sabri Berisha]

- On Aug 18, 2021, at 2:46 AM, Steve Lalonde st...@enta.net wrote:

Hi,

> We always use PeeringDB data and refuse to peer with networks not in PeeingDB

You are aware that PeerinDB refuses to register certain networks, right? It is 
most certainly not a single source of truth.


Thanks,

Sabri

Re: Setting sensible max-prefix limits

[Tom Beecher]

>
> Depending on what failure cases you actually see from your peers in the
> wild, I can see (at least as a thought experiment), a two-bucket solution -
> "transit" and "everyone else".  (Excluding downstream customers, who you
> obviously hold some responsibility for the hygiene of.)
>

Although I didn't say it clearly, that's exactly what we do. The described
'bucket' logic is only applied to the 'everyone else' pile ; our transit
stuff gets its own special care and feeding.

How often do folks see a failure case that's "deaggregated something and
> announced you 1000 /24s, rather than the expected/configured 100 max", vs
> "fat-fingered being a transit provider, and announced you the global table"?
>

I can count on one hand the number of times I can remember that a peer has
gone on a deagg party and ran over limits. Maybe twice in the last 8 years?
It's possible it's happened more that I'm not aware of.

We have additional protections in place for that second scenario. If a
generic peer tries to send us a route with a transit provider in the
as-path, we just toss the route on the floor. That protection has been much
more useful than prefix limits IMO.

On Wed, Aug 18, 2021 at 11:37 AM t...@pelican.org  wrote:

> On Wednesday, 18 August, 2021 14:21, "Tom Beecher" 
> said:
>
> > We created 5 or 6 different buckets of limit values (for v4 and v6 of
> > course.) Depending on what you have published in PeeringDB (or told us
> > directly what to expect), you're placed in a bucket that gives you a
> decent
> > amount of headroom to that bucket's max. If your ASN reaches 90% of your
> > limit, our ops folks just move you up to the next bucket. If you start to
> > get up there in the last bucket, then we'll take a manual look and decide
> > what is appropriate. This covers well over 95% of our non-transit
> sessions,
> > and has dramatically reduced the volume of tickets and changes our ops
> team
> > has had to sort through.
>
> Depending on what failure cases you actually see from your peers in the
> wild, I can see (at least as a thought experiment), a two-bucket solution -
> "transit" and "everyone else".  (Excluding downstream customers, who you
> obviously hold some responsibility for the hygiene of.)
>
> How often do folks see a failure case that's "deaggregated something and
> announced you 1000 /24s, rather than the expected/configured 100 max", vs
> "fat-fingered being a transit provider, and announced you the global table"?
>
> My gut says it's the latter case that breaks things and you need to make
> damn sure doesn't happen.  Curious to hear others' experience.
>
> Thanks,
> Tim.
>
>
>

Re: Setting sensible max-prefix limits

[Dale W. Carder]

Thus spake Chriztoffer Hansen (c...@ntrv.dk) on Wed, Aug 18, 2021 at 12:03:51PM 
+0200:
> On Wed, 18 Aug 2021 at 11:33, Lars Prehn  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 ASn
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

Re: Setting sensible max-prefix limits

[t...@pelican.org]

On Wednesday, 18 August, 2021 14:21, "Tom Beecher"  said:

> We created 5 or 6 different buckets of limit values (for v4 and v6 of
> course.) Depending on what you have published in PeeringDB (or told us
> directly what to expect), you're placed in a bucket that gives you a decent
> amount of headroom to that bucket's max. If your ASN reaches 90% of your
> limit, our ops folks just move you up to the next bucket. If you start to
> get up there in the last bucket, then we'll take a manual look and decide
> what is appropriate. This covers well over 95% of our non-transit sessions,
> and has dramatically reduced the volume of tickets and changes our ops team
> has had to sort through.

Depending on what failure cases you actually see from your peers in the wild, I 
can see (at least as a thought experiment), a two-bucket solution - "transit" 
and "everyone else".  (Excluding downstream customers, who you obviously hold 
some responsibility for the hygiene of.)

How often do folks see a failure case that's "deaggregated something and 
announced you 1000 /24s, rather than the expected/configured 100 max", vs 
"fat-fingered being a transit provider, and announced you the global table"?

My gut says it's the latter case that breaks things and you need to make damn 
sure doesn't happen.  Curious to hear others' experience.

Thanks,
Tim.

Re: Setting sensible max-prefix limits

[Jared Mauch]

> On Aug 18, 2021, at 9:38 AM, John Kristoff  wrote:
> 
> Maybe because there isn't a simple, universal approach to setting it.
> Probably like a lot of people, historically I'd set it to
> some % over the current stable count and then manually adjust when the
> limits were about to be breached, or often was the case when they were
> and I wasn't ready for it. Not ideal.
> 
> I've never felt the automation of this setting however was worth the
> effort.  Of course I am not usually responsible for hundreds of routers
> and thousands of peering sessions.

We did a variant of this at NTT, with certain baseline settings.  Sometimes 
networks would advertise more routes because they onboarded a large customer 
and it would cause manual updates to be necessary.

Polling daily and snapshotting these values is important to understand what is 
changing.  The reason I just posted a message about Akamai max-prefix is we 
have been giving some general guidance that is out of line/norm compared to 
what perhaps what we want.  This won’t cause a service outage per-se but will 
cause suboptimal routing as we continue to make improvements and upgrades to 
our network.

- Jared

Re: Setting sensible max-prefix limits

[Andrew Gallo]

On 8/18/2021 5:33 AM, Lars Prehn wrote:
As I understand by now, it is highly recommended to set a max-prefix 
limit for peering sessions. Yet, I can hardly find any recommendations 
on how to arrive at a sensible limit.


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? Do 
you negotiate/exchange sensible values whenever you establish a new 
session? Do you rely on PeeringDB (if available)? Do you apply default 
values to everyone except the big fishes?


Apart from your peers, do you also apply a limit to your transit sessions?

Best regards,

Lars





Our semi-automated process...
Check the peering routers for any peers that have a prefix limit set (we 
don't set limits on transit or iBGP, so we skip those groups)


Record what the current limit is.

Check peeringDB for what the network says the limit should be.

If configured max prefix < peeringDB, inform a config change is needed;
if configured max prefix > peeringDB, the network isn't keeping its 
record up to date.  no need for change


I've thought about adding additional headroom to what is advertised in 
peeringDB, but we haven't had the limits triggered in so long, it may 
not be worth it.




OpenPGP_0x1C61021F8B5942A2.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Setting sensible max-prefix limits

[John Kristoff]

On Wed, 18 Aug 2021 11:33:09 +0200
Lars Prehn  wrote:

> As I understand by now, it is highly recommended to set a max-prefix 
> limit for peering sessions. Yet, I can hardly find any recommendations 
> on how to arrive at a sensible limit.

Maybe because there isn't a simple, universal approach to setting it.
Probably like a lot of people, historically I'd set it to
some % over the current stable count and then manually adjust when the
limits were about to be breached, or often was the case when they were
and I wasn't ready for it. Not ideal.

I've never felt the automation of this setting however was worth the
effort.  Of course I am not usually responsible for hundreds of routers
and thousands of peering sessions.

At the risk of advocating for more junk in BGP or the RPKI, a max prefix
setting might be something that could be set by the announcing peer in
a BGP message, or possibly as an RPKI object with an associated ASN.
I'll let the masses debate how that would work and all the reasons that
isn't ideal, but I'm not sure there is a one-size-fit all solution for
this in the near term.

John

Re: Setting sensible max-prefix limits

[Tom Beecher]

While there are good solutions in this thread, some of them have scaling
issues with operator overhead.

We recently implemented a strategy that I proposed a couple years ago that
uses a bucket system.

We created 5 or 6 different buckets of limit values (for v4 and v6 of
course.) Depending on what you have published in PeeringDB (or told us
directly what to expect), you're placed in a bucket that gives you a decent
amount of headroom to that bucket's max. If your ASN reaches 90% of your
limit, our ops folks just move you up to the next bucket. If you start to
get up there in the last bucket, then we'll take a manual look and decide
what is appropriate. This covers well over 95% of our non-transit sessions,
and has dramatically reduced the volume of tickets and changes our ops team
has had to sort through.

Of course, we can also afford to be a little looser in limits based on the
capability of the equipment that these sessions land on, other environments
may require tighter restrictions.


On Wed, Aug 18, 2021 at 5:34 AM Lars Prehn  wrote:

> As I understand by now, it is highly recommended to set a max-prefix
> limit for peering sessions. Yet, I can hardly find any recommendations
> on how to arrive at a sensible limit.
>
> 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? Do
> you negotiate/exchange sensible values whenever you establish a new
> session? Do you rely on PeeringDB (if available)? Do you apply default
> values to everyone except the big fishes?
>
> Apart from your peers, do you also apply a limit to your transit sessions?
>
> Best regards,
>
> Lars
>
>
>

Re: Setting sensible max-prefix limits

[Hank Nussbacher]

On 18/08/2021 13:03, Chriztoffer Hansen wrote:

On Wed, 18 Aug 2021 at 11:33, Lars Prehn  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?


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?


That works but all too often people forget to update it.  Set a 
quarterly reminder in your calendar to check max-prefix setting.


-Hank

Re: Setting sensible max-prefix limits

[Lars Prehn]

Okay, so some automated PeeringDB-based approach seems to be the 
preferred road.


~30% and ~40% of IPv4 and IPv6 PeeringDB prefix count recommendations 
are 0. How do you treat those cases? Does it also boils down to a simple 
"we don't peer with them" ?


Best regards,

Lars

On 18.08.21 12:31, Denis Fondras wrote:

Le Wed, Aug 18, 2021 at 10:46:34AM +0100, Steve Lalonde a écrit :

We always use PeeringDB data and refuse to peer with networks not in PeeingDB


That !

Re: Setting sensible max-prefix limits

[Lars Prehn]

On 18.08.21 12:36, Saku Ytti wrote:

On Wed, 18 Aug 2021 at 12:36, Lars Prehn  wrote:


As I understand by now, it is highly recommended to set a max-prefix
limit for peering sessions. Yet, I can hardly find any recommendations
on how to arrive at a sensible limit.

You are missing two important questions
a) should I apply it to before or after policy
b) what should I do when it triggers, should I reset or stop accepting new


When I read through [1] earlier today, I had the feeling that these 
question rather strictly translate to:


a) Do I keep rejected routes around?

b) Can I traffic-wise afford dropping the session to send a strong 
signal to my peer?


Hence, I didn't dig deeper.

Best regards,

Lars

[1] 
https://tools.ietf.org/id/draft-sa-grow-maxprefix-00.html#rfc.section.3.1

Re: Setting sensible max-prefix limits

[Saku Ytti]

On Wed, 18 Aug 2021 at 12:36, Lars Prehn  wrote:

> As I understand by now, it is highly recommended to set a max-prefix
> limit for peering sessions. Yet, I can hardly find any recommendations
> on how to arrive at a sensible limit.

You are missing two important questions
a) should I apply it to before or after policy
b) what should I do when it triggers, should I reset or stop accepting new

--
  ++ytti

Re: Setting sensible max-prefix limits

[Denis Fondras]

Le Wed, Aug 18, 2021 at 10:46:34AM +0100, Steve Lalonde a écrit :
> 
> We always use PeeringDB data and refuse to peer with networks not in PeeingDB
> 

That !

Re: Setting sensible max-prefix limits

[Lukas Tribus]

On Wed, 18 Aug 2021 at 12:03, Chriztoffer Hansen  wrote:
>  'some' networks will input a value with headroom percentages already 
> included.

That's what it's for.

There is no point in periodically copying the actual prefix-count into
peeringdb records, that would just be redundant data which would be
wrong more often than not.

PeerginDB tool tips:
Recommended maximum number of IPv4 routes/prefixes to be configured on
peering sessions for this ASN
Recommended maximum number of IPv6 routes/prefixes to be configured on
peering sessions for this ASN



Lukas

Re: Setting sensible max-prefix limits

[Chriztoffer Hansen]

On Wed, 18 Aug 2021 at 11:33, Lars Prehn  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?

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.

Re: Setting sensible max-prefix limits

[Lukas Tribus]

On Wed, 18 Aug 2021 at 11:33, Lars Prehn  wrote:
>
> As I understand by now, it is highly recommended to set a max-prefix
> limit for peering sessions. Yet, I can hardly find any recommendations
> on how to arrive at a sensible limit.
>
> 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? Do
> you negotiate/exchange sensible values whenever you establish a new
> session? Do you rely on PeeringDB (if available)? Do you apply default
> values to everyone except the big fishes?

- review max prefix suggestions from the peer itself, either from the
email or peeringdb
- check actual current prefix count (bgp.he.net et all)
- check whether the disparity between the two matches your expectation
of a safety margin, based on your own operational experience and
context
- defaults for low prefix count peers
- actually monitor warning/critical levels of max-prefix counts

Don't use too small a safety margin, you don't want to spend your days
adjusting max-prefix levels all the time.

I don't have strict rules for the safety margin itself; it depends
very much on the network (size, growing rate, trust, history).


lukas

Re: Setting sensible max-prefix limits

[Steve Lalonde]

On 18 Aug 2021, at 10:33, Lars Prehn mailto:lpr...@mpi-inf.mpg.de>> wrote:
> 
> As I understand by now, it is highly recommended to set a max-prefix limit 
> for peering sessions. Yet, I can hardly find any recommendations on how to 
> arrive at a sensible limit.
> 
> 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? Do you 
> negotiate/exchange sensible values whenever you establish a new session? Do 
> you rely on PeeringDB (if available)? Do you apply default values to everyone 
> except the big fishes?
> 
> Apart from your peers, do you also apply a limit to your transit sessions?

We always use PeeringDB data and refuse to peer with networks not in PeeingDB ( 
I think there are only 2 exceptions ) Automation keeps the max_prefix numbers 
up to date. 

Our transits we use data from the weekly routing table reports and allow some 
expansion room.

So far this works for us

Regards

Steve

Setting sensible max-prefix limits

[Lars Prehn]

As I understand by now, it is highly recommended to set a max-prefix 
limit for peering sessions. Yet, I can hardly find any recommendations 
on how to arrive at a sensible limit.


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? Do 
you negotiate/exchange sensible values whenever you establish a new 
session? Do you rely on PeeringDB (if available)? Do you apply default 
values to everyone except the big fishes?


Apart from your peers, do you also apply a limit to your transit sessions?

Best regards,

Lars