Curious if any IRR databases are mirroring/importing ROA data - creating
route>6 objects from ROA?
LACNIC requires a route object to be created when creating a ROA.
APNIC you create a route object, then may generate a ROA during that
process.
Other RIR's, curious if anything tries to bring the two together?
Applicable for networks that only use IRR data (do not yet validate RPKI),
they could benefit.
IRR questions:
How do most large networks maintain (automate) their IRR records?
Is it standard practice to accept more specifics (append IPv4 "le /24" and
IPv6 "le /48")?
Or is it expected to have one IRR route per BGP announcement?
Curious if any IRR databases are mirroring/importing ROA data - creating
route>6 objects from ROA?
LACNIC requires a route object to be created when creating a ROA.
APNIC you create a route object, then may generate a ROA during that
process.
This is a mis-characterisation of the situation. In APNIC, we have
implemented abstract routing management: you tell us the routes you
want to declare and have to elect to do ONLY route: object or ONLY ROA
-we make the ROA & route: objects aligned, to represent what you asked
for in the abstracted route. It's only if you specifically ask us to
make discrete, unaligned states in both worlds we do that. By default,
they mirror each other (modulo the limits of maxlen over the prefix at
hand: we don't make the "forest" of routes which would be needed
beyond a small distance maxlen - prefixlen)
Separately we kept the old whois object update path. you can elect to
make a route: object directly in the RPSL maintenance engine. If you
come into routes management, we flag the mis-alignment such as it is,
and you can make the ROA.
But this is not used to create route(6) objects in the TC source, only
to invalidate route(6) objects that users create at TC. Mirrored IRRs
like RADB are not subject to RPKI validation, only to scope filter
(private IP addresses, private ASNs).
IRR questions:
How do most large networks maintain (automate) their IRR records?
Is it standard practice to accept more specifics (append IPv4 "le /24" and
IPv6 "le /48")?
Or is it expected to have one IRR route per BGP announcement?
IMO, many accept more specifics, but you shouldn't rely on this under
normal circumnstance.
IRR questions:
How do most large networks maintain (automate) their IRR records?
Is it standard practice to accept more specifics (append IPv4 "le /24" and
IPv6 "le /48")?
Or is it expected to have one IRR route per BGP announcement?
We (37271) use different policies depending on our relationship to the
neighbor.
From customers, we require an exactly matching route(6) object.
From peers, we accept more specifics up to /24 or /48.
The rationale for this is:
1. We consider that we have a higher "duty of care" with respect to
routes that we intend to announce to the wider Internet; and
2. Having a customer facing policy that is at least as strict as our
strictest neighbor helps eliminate hard to troubleshoot propagation
issues.
We've been doing things this way for several years now, and it seems to
be a good middle ground.