<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="en-NL" link="blue" vlink="purple" style="word-wrap:break-word"> <div class="WordSection1"> Hi Job,<o:p></o:p> <o:p> </o:p> <ul style="margin-top:0cm" type="disc"> <li class="MsoListParagraph" style="margin-left:-15.75pt;mso-list:l0 level1 lfo3"> This BCOP proposal is not for all IXPs. First of all, it targets to be a RIPE document and thus, have validity in the EU/RIPE region. Unless another RIR decides to adopt it or publish a similar one, we don�t expect to become a global operational document. It is more of a strong recommendation rather than an enforced policy. Policies have major impact to anyone involved, BCOPs are optional recommendations. Do you believe the introduction or the scope is misleading and needs rephrasing? <o:p></o:p></li><li class="MsoListParagraph" style="margin-left:-15.75pt;mso-list:l0 level1 lfo3"> The IRRdv4 workaround is not a good one. Initially, not everyone can afford having an IRRDv4 instance in its infrastructure to use its features or can fit with the operational model . In AMS-IX infrastructure we do use IRRdv4 to mirror other IRR DBs and I have bumped into the "route object preference" feature. But we incorporated it into our operations last year. Moreover, as Sasha mentions in the document: �IRRd will act as if the object was deleted, but it may become visible again later.� due to creations/deletions. <o:p></o:p></li></ul> I consider the following approach a more feasible one for most of the users: �bgpq4 -4 -A -b -h my-whois.domain.net -S RIPE,LACNIC,APNIC,ARIN,AFRINIC,RADB AS-FOOBAR� But RADB will always prioritize their objects with SOURCE RADB over the official ones (which makes sense as they make money), and AS-TWITTER is a great example: There are 2 objects of AS-TWITTER in RADB, one from RIPE and one from RADB. If you select to prioritize the RIPE one instead of the RADB one, then you get nothing. That said, I can go tomorrow in RADB and create an AS-SET called �AS-AKAMAI� with no members, thus guess what will happen to all the folks who simply run �bgpq4 -A -h whois.radb.net AS-AKAMAI�<o:p></o:p> And this is just one example, but this BCOP is not about setting priorities on IRR DBs, it is a bit more ambitious. A small community of operators try to achieve a much broader goal (hopefully). <o:p></o:p> Kind Regards Stavros<o:p></o:p> <o:p> </o:p> <div id="mail-editor-reference-message-container"> <div> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm"> From: connect-wg <connect-wg-bounces@ripe.net> on behalf of Job Snijders <job@sobornost.net> Date: Thursday, 6 June 2024 at 13:22 To: connect-wg@ripe.net <connect-wg@ripe.net> Subject: Re: [connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call<o:p></o:p> </div> <div> Dear group, I have good news related to two remarks about prioritization of IRRs On Tue, Jun 04, 2024 at 10:08:53AM -0700, Randy Bush wrote: > > i would support preferring some irrs in case of duplication/conflict This is nowadays possible, see below. Also replying to part of Marco's message: On Thu, Jun 06, 2024 at 05:52:50AM +0200, Marco d'Itri wrote: > On Jun 04, Job Snijders <job@sobornost.net> wrote: > > It seems the proposal does not mention considerations on alternative > > approaches. > > I do not think that it is plausible for us to propose to all IRR > operators to implement something. Yet, this 'BCOP' draft proposal is exactly that? :-) On Thu, Jun 06, 2024 at 05:52:50AM +0200, Marco d'Itri wrote: > Maybe it could be implemented in bgpq4 at the price of a lot more > client-side processing, but since it would still allow hijacking > unallocated space then I do not believe that this complexity would be > justified. In IRRd v4 a feature was implemented called "route object preference": <a href="https://irrd.readthedocs.io/en/stable/admins/route-object-preference/">https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Firrd.readthedocs.io%2Fen%2Fstable%2Fadmins%2Froute-object-preference%2F&data=05%7C02%7Cstavros.konstantaras%40ams-ix.net%7C7489528349ec40bd3b7508dc861aefc5%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638532697446749115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=JHr8hq%2FeZjW%2FLRGptngGi5Oo%2BzuluAeTIxJVQJozTpA%3D&reserved=0</a> This is part of a broader set of tools to help mitigate risk associated with non-cryptographically signed IRR databases (such as RIPE, ARIN, RADB) <a href="https://irrd.readthedocs.io/en/stable/admins/object-suppression/">https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Firrd.readthedocs.io%2Fen%2Fstable%2Fadmins%2Fobject-suppression%2F&data=05%7C02%7Cstavros.konstantaras%40ams-ix.net%7C7489528349ec40bd3b7508dc861aefc5%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638532697446763652%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=uG0%2BsEMySqMPz92LYRjlnLNzmNj39buWVU3u6O40jL8%3D&reserved=0</a> Knowing that the software and tooling already today is out there to prioritize RIR databases over non-RIR databases, and knowing there also is RPKI-filtering on the route object level; what threats does this draft proposal address other than recommending to ignore potentially useful information? Did any of the authors actually try IRRd v4's route object preference feature and compared it with their own proposal? Kind regards, Job _______________________________________________ connect-wg mailing list connect-wg@ripe.net <a href="https://mailman.ripe.net/">https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fmailman%2Flistinfo%2Fconnect-wg&data=05%7C02%7Cstavros.konstantaras%40ams-ix.net%7C7489528349ec40bd3b7508dc861aefc5%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638532697446775809%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=5u9KDQxvy9HRrZbpdsjNiX32adhj6YW7d3rrRSRP3MU%3D&reserved=0</a> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: <a href="https://mailman.ripe.net/">https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fmailman%2Flistinfo%2Fconnect-wg&data=05%7C02%7Cstavros.konstantaras%40ams-ix.net%7C7489528349ec40bd3b7508dc861aefc5%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638532697446785253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=PD9orcSuklaqfWVoDm6c4fwZT7j6cYzeT6uz4NsHLYQ%3D&reserved=0</a><o:p></o:p> </div> </div> </div> </div> </body> </html>