On 02/07/2020 16:47, ripedenis--- via db-wg wrote:
> Given that the discussion you tried to get going recently on the future
> of RPSL hardly got off the ground, then unless someone already has
> advanced plans on a replacement for RPSL I don't see it going away
> anytime soon.

As it is possibly my fault for setting Nick off on the most recent of
discussions with regards to RPSL, it might be worth re-iterating now
what I asked on IRC: who is still using the RPSL in aut-nums for
important work?

As per my understanding from the ensuing conversation, RPSL in an
aut-num is used:-

  i) to build as-path/prefix-list filters for your peers/customers
 ii) as internal interconnection documentation, in lieu of other OSS

As far as I know, (ii) isn't too common (I can think of a few very
admirable examples) but mostly this is internal documentation that
doesn't need to be publicised.

In the case of (i), who in their right mind expects that data to be
accurate? There's no validation happening. AS35425 had ridiculously
outdated RPSL for years, and this only ever incurred emails from RIPE
about reclaimed ASNs that it referenced.

Parsing as-sets to find route objects, and hopefully filtering that list
through some RPKI Invalid filtering, appears to me to be the correct way
to do (i) as of today, and that has been the case for some time.

So... The question in so much as "what do we replace RPSL with?" doesn't
seem to be as pertinent, "Why are we all still collectively waving our
[outdated] routing policies about in public?" Bragging rights? Eye
candy? As far as I can tell, no-one is actually paying attention...!


[ N.B. I realise that RPSL is optional in aut-nums, but the RIPE NCC
also populate new ASNs with import/export lines, which infers that it
*is* a requirement to the uninitiated. It also helps it look entirely
superfluous when you forget to update it for 3 years & nothing breaks. ]


Regards,

-- 
Tom

Reply via email to