On Mon, Mar 02, 2026 at 02:12:37PM +0200, Saku Ytti wrote:
Active path verification is dicy.
- you can have multiple active paths, depending on POV
For sure, this while generating a prefix-list per customer, and one should be cognizant that a given IP prefix destination might appear in multiple prefix-lists. Indeed, there can be multiple plausible paths towards a given IP destination. Not a problem, right?
- but if you receive more-specific paths, you will likely collapse to 1 POV
Your route collector is assume to be peering with all your routers, one should be using the MRT UPDATES to generate the lists. Maybe I am misunderstanding you. BTW, I merely suggest a batch-processing-oriented workflow leveraging MRT UPDATE files, because it might lower the barrier to deployment (compared to, for example, a stream-oriented approach using BMP). Throughout this conversation I try to encourage people to consider other (non-IRR!) sources to automatically ascertain the plausibility of requests for blackholing.
- is blackhole desirable for all POV?
Great question. Must _every_ request for blackholing be honored? Probably not. As there is a risk of accepting unauthorized blackholes, it might be good to err to the side of caution and not be overly liberal in accepting any and all requests for blackholing.
Now you are blackholing everywhere, instead of the 1 active port. Above issue has happened to us, where the source would not have wanted the blackhole to appear.
Please elaborate on this scenario with more words.
Even without this problem, it's not entirely clear if the middle ASN generated blackhole is desirable or permitted by the source ASN.
Yes, for this reason a network operator might implement as their policy that blackholes are only permitted for routes originating in the directly adjacent ASN (the customer AS). Operators define the exact characteristics of the blackholing service themselves. Section 6 of RFC 7999 states: "The method of validating announcements is to be chosen according to the operator's routing policy." Darn those RFC authors for not providing a complete solution! ;-)
Perhaps if middle ASN thinks it should have this control over source ASN, they need to cooperate to figure out how to gain this capability. Either additional ROA or some mechanism between middle and source for source to generate it as needed.
So perhaps RPKI-valid-of-more-specific is safer.
I would benefit from a few more words on what exactly you mean with the above. Do you mean to say that if the customer AS is 65535, you'd only permit blackholes if they are contained within the prefixes for which AS65535 is an authorized origin, according to RPKI ROAs? Sure, that seems a reasonable precaution. Kind regards, Job