[connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call

On Jun 06, "Nick Hilliard (INEX)" <nick at inex.ie> wrote:

> The first, and main one, is that this isn't current operational practice
> across a lot of IXPs. It might happen one day that it'll be adopted widely
> across IXPs, but as far as I'm aware, we're not at that point yet. When
We are not at that point because our plan was to first publish 
a document with a timeline of future actions.
If we have totally misunderstood the process of publishing a RIPE BCOP 
then we can just move on with the plan and come back in a couple of 
years to publish the document (if anybody will still care to do the work 
when ~everybody in Europe will already have adopted it).

> In the case of routing security, there are still difficulties for
> organisations who have ASNs, as-sets and route lists which span different
> RIRs, and for whom third party IRRDBs provide a reasonable and responsible
> mechanism for expressing their intended routing policies. Cutting these
I do not believe that this is a real issue: while it may be slightly 
more convenient for some networks to just dump all route objects in 
RADB instead of using the appropriate IRR which is authoritative for 
each prefix, I think that at this point it is a fact that filters are 
generated as the union of the results from multiple IRRs.
So I do not believe that allowing this is worth the troubles which come 
from using non-authoritative IRRs.

> organisations off is not going to help routing security overall - they'll
> simply bypass route servers and then the industry will be back to unfiltered
> bgp sessions again.
The proposal does not specify any actions for non-RS BGP filters, so 
I am not sure that I understand your point.

-- 
ciao,
Marco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.ripe.net/ripe/mail/archives/connect-wg/attachments/20240606/3b3ee9a2/attachment-0001.sig>