> 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, b
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
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.
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
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
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
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.
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
>
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
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
> 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
> 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
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
- 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
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
* 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
- 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
> 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
- 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
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
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
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?
>
- 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,
>
> 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
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,
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
> 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
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
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
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
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
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,
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
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
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 !
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
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
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,
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
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
40 matches
Mail list logo
