search

peeringdb / peeringdb

Server code for https://www.peeringdb.com/
BSD 2-Clause "Simplified" License
340 stars 111 forks source link

RFE for IRRdb support on Route Servers #1600

Closed stkonst closed 1 week ago

stkonst commented 3 weeks ago

Hi PDB team,

I am submitting this issue to request a new feature for the Peering DB Route Server records. To be more specific, while examining our Route Server object (https://www.peeringdb.com/net/4277) I noticed I cannot mention anywhere which IRR databases we are officially supporting to configure the Route Servers. This is relevant to a work that is being done in Connect WG at RIPE community. There is an upcoming BCP in the RIPE community (Arnold knows about it) where IXPs will restrict the amount of IRRs being used to configure the Route servers with the end goal to support official IRRs only.

Thus, it would be nice to have a list of supported IRR databases where we can fill it in (perhaps via a drop-down menu?). That can help customers to understand:

Do you think would be feasible to add such a feature in PeeringDB?

Kind Regards Stavros Konstantaras | AMS-IX

arnoldnipper commented 3 weeks ago
  • which IRRs are being supported in the IXP’s Route Servers

Iirc, we allow all DB listed at irr.net

stkonst commented 3 weeks ago

Hi @arnoldnipper correct. But is there a way to present a list of supported IRRs under the Route Servers object where I can define the individual items of this list? For example I can have a list for the AMS-IX NL Route Servers where the items are [ RIPE, ARIN, APNIC, LACNIC, AFRINIC ] while another IXP in Asia might declare [ ARIN, IDNIC, RADB ] IRR dbs.

I am not against if PeeringDB provides all possible IRRdbs for me to fill in my list but I would love to have a list and fill it with the items I want based on our strategy.

BR Stavros

arnoldnipper commented 3 weeks ago

Hi @stkonst, I still fail to see why it would make sense having this in PeeringDB. If an ASN wants to peer with your RS, you probably will let them know your policy.

@peeringdb/pc, thoughts?

stkonst commented 3 weeks ago

Hi Arnold,

Let me elaborate a bit further. Although I can define in Peering DB where my Peering Policy is with "RIPE::AS1200" or where my AS-SET is with "RIPE::AS6777:AS-AMS-IX-RS", it will still be valuable to present a list of supported IRRdbs where IXPs consult in order to retrieve Policies and AS-SETs to configure Prefix Lists for Route Servers.

Maybe for a small-medium IXP where the customer-base is mostly in RIPE region doesn't make much sense, but for bigger ones where a big portion of customer base is coming via remote peering (and rely a lot to peering db to retrieve info), it makes sense for them to know in advance which IRRdbs this IXP/Peering LAN supports. This list increases awareness which can help them to create/update/configure their objects accordingly, but I can also envision a list of useful upcoming features that will help operations in the future:

Does the above text help a bit?

arnoldnipper commented 2 weeks ago

Does the above text help a bit?

No really, @stkonst. As mentioned before, if an ASN wants to connect to one of your IXP they will contact you for the requirements, resp. you will have this information as part of your peering policy. Hence, no need having this information in PeeringDB. We are supporting all IRR. KISS :)

mcmanuss8 commented 1 week ago

-1 from me unless we hear a lot of request for this across a large enough numbers of IXes

jackcarrozzo commented 1 week ago

PC call: sounds AMS-IX specific? Not clear we need this without clear use cases.

Martolins commented 1 week ago

Hi, as Namex

Let me elaborate a bit further. Although I can define in Peering DB where my Peering Policy is with "RIPE::AS1200" or where my AS-SET is with "RIPE::AS6777:AS-AMS-IX-RS", it will still be valuable to present a list of supported IRRdbs where IXPs consult in order to retrieve Policies and AS-SETs to configure Prefix Lists for Route Servers.

I agree on this, and thinking about members who are in different IXPs can use PeeringDB as a single source to retrieve this information. Plus if it could be a way to not generate empty prefix lists, even better.

irinovna commented 1 week ago

Hello Stavros,

From LU-CIX side I would agree that this is a rather useful feature request which will allow better IX operations.

grizz commented 1 week ago

To add a bit more context, we discussed at the last PC meeting and felt that the Notes field is the correct place for this.

Adding a field to the object does not give any sort of actionable programmatic response that a network can use to add themselves to one of the IRRs.

rafeurdean commented 1 week ago

I think there is a real use of an "Supported IRRs" field. While there my not be some immediate use "in a programmatic way", it gives clear visibility where different networks stand with respect to "IRR filtering" (which is unfortunately not such a simple problem as some people may think).

Putting that info in the "notes" field (with each network presenting it in a different/random format) approaches the level of "useless".

moshivji commented 1 week ago

Hi Stavros From LINX we also agree that this feature would be useful.

martinhannigan commented 6 days ago

-1 lets move on.

On Tue, May 7, 2024 at 06:21 Mo Shivji @.***> wrote:

Hi Stavros From LINX we also agree that this feature would be useful.

— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1600#issuecomment-2097980257, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQVNEM6HGRMEQMTL3NDZBCTMLAVCNFSM6AAAAABGMWPBA2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJXHE4DAMRVG4 . You are receiving this because you are on a team that was mentioned.Message ID: @.***>