I agree the peerAS=originAS guardrail would be ideal both because it makes the risks associated with ignoring maxLength (for RTBH) in implementation less, but also I suspect many networks already enforce RTBH routes to have only 1 member in the AS_PATH. 

The problem then lies with RTBH routes that have >1 AS in the path, what do we do for those? Not support them? If we do support them, we still need route validation. 

Thanks, 

--
Bryton Herdes
Principal Network Engineer
AS13335 - Cloudflare

On Sat, Aug 8, 2026 at 7:03 PM Job Snijders <job@bsd.nl> wrote:
On Sat, Aug 08, 2026 at 11:27:05PM +0000, Job Snijders wrote:
> On Sat, Aug 08, 2026 at 06:15:08PM -0500, Bryton Herdes via routing-wg wrote:
> > if you're interested in a router feature knob that could selectively
> > ignore maxLength of ROAs while (only) performing RTBH route
> > validation, I can share at least the Juniper and Cisco feature
> > requests I've submitted. Let me know.
>
> Just ignoring maxLength because it is 'inconvenient' sounds pretty
> unsafe, right? The resources holder probably didn't set that maxLength
> to be ignored.
>
> What other safeguards will accompany such a risky feature?

A potential guardrail maybe is to only ignore maxLength if the peer-as
(the neighboring AS from which the blackhole route was received) is the
same AS as the Origin AS in the VRP for which the maxLength is ignored?

Then you'd basically have the same setup as the config example I shared
previously in this thread, and less need for automation.

Kind regards,

Job