Sure, I'll take the ER. We are requesting a multi RTR db solution from Nokia, as well as ASN origin-check (like junos, iosxr) to facilitate 'prefixless' IRR validation via synthetic RPKI coverage. I'm on the fence calling JNPR approach hacky, I'd more inclined to call it expressive, where design allows emergent features to be implemented that were not specifically designed. This is a common theme comparing Junos and IOS-XR, expressive or specific. I understand what you are asking 'rpki-valid-or-longer', and how that is more convenient than setting up a second RTR database, but also it's less expressive and has less control. I am not against it, just undecided if I should penalise Juniper asking specific features when functionality already can be met. On Tue, 28 Jul 2026 at 21:49, Bryton Herdes <bryton@cloudflare.com> wrote:
Yes it is possible in JunOS and BIRD both, JunOS with some hackery. I’m talking about formally supported knobs from the big vendors.
If you’re interested in the feature request IDs I’ve submitted to Juniper/HPE and Cisco I’m happy to provide those off-list, or you can see them in my NANOG 98 slides in a few months.
-- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare
On Tue, Jul 28, 2026 at 2:23 PM Saku Ytti <saku@ytti.fi> wrote:
On Tue, 28 Jul 2026 at 19:58, Bryton Herdes via NANOG <nanog@lists.nanog.org> wrote:
I’ve went back and forth on solutions for RTBH, and my latest opinion is vendors should implement a separate knob to bypass maxLength checking for specifically routes tagged as BLACKHOLE, and still validate origin AS via RPKI-ROV. The risk of operators using such a knob in “a bad way” is known, but we need this tool. Let’s talk about this more at NANOG 98.
Yes. And this is possible today on Junos, as Martin Tonusoo shared in this list (not this thread) earlier.
-- ++ytti
-- ++ytti