[lacnog] lack of feature parity between IRR and RPKI?

[Job Snijders]

Dear all,

I was impressed to learn that a very significant portion of LACNIC
managed space is covered by RPKI ROAs. This places the LACNIC region
high on the leadership board! Which leads me to the ask you as community
the following.

If we (for the sake of this discussion) consider the RPKI ROA object as
concept similar to the IRR "route:" object, from a provisioning
perspective I'm wondering whether the LACNOG community has found a
similar analogy for the IRR "as-set:".

Some background on the 'as-set': predominantly outside the LACNIC
region, the IRR "as-set:" object is used as a computer parsable grouping
of downstream ASNs. For instance if I (AS 15562) would purchase IP
connectivity services from a transit carrier or IXP route server, I'd
communicate to the provider that "RIPE::AS-SNIJDERS" should be used to
create a whitelist of potential BGP prefixes I as AS15562 may announce.
The whitelist is usually generated by doing an inverse lookup for all
prefixes for which it has been indicated that 15562 is an authorised
origin ASN. These reverse lookups can be done in various IRR databases,
the IRR or in the case of ARIN in the WHOIS. The "as-set:" object often
times is also used to generate AS_PATH filters which form an additional
layer of protection.

As far as I know there is no equivalent of "as-sets" in the RPKI world,
which makes me wonder: has the LACNOG community solved this via some
other method? (Perhaps simply periodically emailing each other a list of
downstream ASNs, or some tool I'm not aware of?) - or is this something
that should be addressed through global coordination in for example te
IETF SIDROPS working group?

In an RPKI-only world, how does an operator discover what the downstream
ASNs are of the operator's peers and customers? Or is the IRR still used
for that particular function?

Kind regards,

Job