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

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