On Mon, May 24, 2021 at 02:04:32PM -0400, Luca Salvatore wrote:

Curious if anyone is aware of other Tier1s deprecating support for RADB?

Rather than deprecating RADB, I think the industry would be better off if either RADB or the Tier1s (in their local caching layer) deploy IRR database software capable of RPKI Origin Validation ala RIPE-731. https://www.ripe.net/publications/docs/ripe-731 http://irrd.net/ Kind regards, Job

Hello Jon , On Mon, 24 May 2021, Jon Lewis wrote:

On Mon, 24 May 2021, Job Snijders via NANOG wrote:

...

On Mon, May 24, 2021 at 02:04:32PM -0400, Luca Salvatore wrote:

...

Curious if anyone is aware of other Tier1s deprecating support for RADB?

Rather than deprecating RADB, I think the industry would be better off if either RADB or the Tier1s (in their local caching layer) deploy IRR database software capable of RPKI Origin Validation ala RIPE-731.

I suspect the attitude is "why bother when we can just require that everyone use the IRR run by their RIR, rely on the RIR to not allow bogosity in thier IRR, and keep using our existing software, just limiting the IRR sources from which it'll accept objects?"

While I am not a big player (or even a bump in the road) in this group I do find it rather odd that people & corporate entities allow (& sponsor) another grab at , imo , taking over the proper way we as players in this arena should be working WITH each other . The "just leave it to big brother" is just plain a cop out to laziness<whatever verb you'd wish to use> (agn imo) . Sorry I'll say no more on the above as I'd just rant .

BTW...speaking of MANRS, if there's someone on-list who can help out with some questions, I'd appreciate the contact. For $work, I'd been talking to Kevin Meynell about our joining. It fell through the cracks and recently popped back up. Recent email to Kevin got no reply. The MANRS web site could use quite a bit of clarification (or maybe just toss it and start over).

To be honest the manrs site left me feeling rather blase' , The place that interested me is the Implementation Guide . Which seems to be a compendium of the [RFC|BCP]'s of the Proper way to maintain records at and with the entity that dispenses the resource(s) being used .

Also, I'm curious how common it is for networks to build IRR-based prefix-list filters for all their peers (i.e. IX peers, where you have lots of peers)?

---------------------------------------------------------------------- Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

Twyl , Back to silent mode . JimL -- +---------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network & System Engineer | 3237 Holden Road | Give me Linux | | jiml@system-techniques.com | Fairbanks, AK. 99709 | only on AXP | +---------------------------------------------------------------------+

On Sun, May 23, 2021 at 4:29 PM Laura Smith via NANOG <nanog@nanog.org> wrote:

I thought everyone was supposed to be migrating to MANRS. ;-)

...if you aren't cracking a joke about the 15th of 14 standards... MANRS is an umbrella project that is supposed to (depending on where you fit in the ecosystem, but generally): 1) bcp-38 your customer/your traffic 2) publish your routing intent data in an IRR 3) publish your routing origin data in RPKI 4) filter your customer/peer/partner/<nouns> routes to/from them: "Do not send them nonsesne, do not accept nonsense" 5) tell more people about the above (there, I accomplished a MANRS requirement!!) srsly though... manrs is about being a reasonable adult on the inter-tubes. The particular question from the OP was: "Hey, I have routing data, others also do, what does it take to get people to believe my routing data?" I think: 1) publish your IRR content properly, keep it updated 2) publish your ROA/RPKI data, keep it updated 3) automate the above 2 so you don't have to make a hoomon do the work

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Saturday, 22 May 2021 00:40, Clinton Work <clinton@scripty.com> wrote:

...

Is there any compiled information for Tier1 providers on the supported BGP filter generation data sources and frequency?

This is what I have been able to determine so far:

- TATA AS6453: IRR and RPKI ROAs ( http://lg.as6453.net/doc/cust-routing-policy.html) - Cogent AS174: unknown - NTT 2914: IRR, ARIN WHOIS OriginAS, NIC.br whois, RPKI ROAs ( https://www.gin.ntt.net/support-center/policies-procedures/routing/) - Lumen AS3356: IRR - Telia AS1299: IRR

TATA is going to deprecate new RADB, NTTCOM, and ALTDB route objects starting Aug 15, 2021 and I was hoping that more providers would add RPKI ROAs as a data source for BGP filter generation. Supporting RPKI ROAs would mean that you don't have to create both IRR route objects and RPKI ROAs for each IP block.

-- Clinton Work