Hi Sascha

If there is an existing, exact matching ROUTE object the creation of the new ROUTE object must be authorised by the existing object. There is a flow chart here explaining the sequence of checks:
https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/route-object-creation-flowchart.pdf

If you want to 'replace' the existing ROUTE object the maintainer of the less specific INETNUM allocation object can delete the existing ROUTE object using the authorisation of the allocation object. This is explained here:
https://www.ripe.net/manage-ips-and-asns/db/support/managing-route-objects-in-the-irr#4--reclaiming-access-to-blocking-route-objects

cheers
denis

co-chair DB-WG



On Thursday, 11 June 2020, 01:31:36 CEST, Sascha E. Pollok via db-wg <db-wg@ripe.net> wrote:


Dear friendly DB people,

here is a problem I don't find easy to solve. Would you assist me in understanding the
constraints?

Customer has a /22 network 194.76.156.0/22 with the proper inetnum object. The inetnum
objects has a mnt-by: IPHH-NOC and mnt-routes: IPHH-NOC.

A route object exists but with a different maintainer:

route:          194.76.156.0/22
descr:          CMELCHERS-QSC-NET
descr:          via Plusnet
origin:        AS20676
mnt-by:        PLUSNET-NOC    <<<---- not IPHH-NOC

We are now trying to create an additional route object for a different ASN:

route:          194.76.156.0/22
descr:          C. Melchers via MEKO-S
origin:        AS207630
mnt-by:        IPHH-NOC    <<<--- This is the maintainer in the inetnum object
source:        RIPE

The RIPE DB refuses the update:

Create FAILED: [route] 194.76.156.0/24AS207630
route:          194.76.156.0/24
descr:          C. Melchers via MEKO-S
descr:          belongs to 194.76.156.0/22
origin:        AS207630
mnt-by:        IPHH-NOC
source:        RIPE
***Error:  Authorisation for [route] 194.76.156.0/22AS20676 failed
            using "mnt-by:"
            not authenticated by: PLUSNET-NOC

So the DB expects the maintainer from the other route object. But I don't understand why
the mnt-routes in the inetnum-object doesnt give preference over the maintainer on a
different route-object.

Anyone who could share their honest opinion?

Cheers
Sascha