[db-wg] RIPE DB Route Object fails creation

> On 11/06/2020 14:17, Job Snijders wrote:
>>>> ***Error:   Authorisation for [route] 194.76.156.0/22AS20676 failed
>>>>             using "mnt-by:"
>>>>             not authenticated by: PLUSNET-NOC
>>> Could we reduce the confusion, and/or spread some more clue, by being
>>> more specific with this error? e.g.
>>>
>>> Authorisation for [blah] failed using "mnt-by:"
>>>  - matching route object already exists
>>>  - not authenticated by: PLUSNET-NOC
>> Perhaps instead of an error message, the operation that Sasha tried to
>> do should just be allowed?
>
> Because of the following (stunningly regular) corner case:
>
> 1. PI space owner doesn't understand what the implications are of
> migrating prefixes between origins/networks, or dual-homing from two
> networks
>
> 2. New origin/network creates route without the knowledge of the
> existing origin/network provider (whom are often different providers)

Now you lost me.  There is something you're not explicitly saying
here, and that is what negative event occurs when a new route
object with a new origin is registered in the IRR.

The prefix could via this operation be accepted by peers and
upstreams from the new origin AS, through re-generation of filter
lists and installing those on routers.  But as long as the new
origin doesn't actually announce the route, what wrong/unexpected
event would occur?

> 3. Customer blames existing origin/network for breaking their traffic
> routing, whom had no idea anything was going on

Why would simply adding the route object to the IRR break the
customer's routing?  Again, I think there is a pre-condition you
are not stating out loud here, and I think it should be.

Of course, if the new provider doesn't actually have connectivity
to the customer, but still proceeds to announce the route, it's
obvious that will create reachability issues for the customer but
I would not blame the IRR for such utter stupidity in ISP
operations.

> Having that route object check at the beginning of the flow
> chart ensures that all parties required to provide service, are
> aware of the changes to advertisements & can properly prepare
> their networks/customer networks, and prevent outages.

I used to have another perspective, and that is that the
relationship between the customer and the old provider had gone
sour for some reason or other, and that the old provider could
hold the customer hostage by the "blocking" route object.  Then
the "forcefully delete route object via inetnum authorization"
was introduced as an IMHO ugly workaround for this issue.
Besides, going the path from "1 old route object" to "1 new route
object" via a state of "0 matching route objects" doesn't exactly
sound safe to me -- what if filter regeneration somewhere hits in
the time period where there is no matching route object in the
DB?

> If all our customers knew exactly what they were doing, they'd
> usually be running their own BGP AS and handling their own
> announcements, resilience, and/or migrations.

There is some truth to that, but I suspect there's a fair number
of PI holders which don't have their own AS number, and instead
rely on their upstream to originate the route for them.

Regards,

- Håvard