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