Hi Chris, On 11/29, Christopher Morrow wrote: > On Mon, Nov 29, 2021 at 8:14 AM Job Snijders via NANOG <nanog@nanog.org> > wrote: > > > Hi Anurag, > > > > Circular dependencies definitely are a thing to keep in mind when > > designing IRR and RPKI pipelines! > > > > In the case of IRR: It is quite rare to query the RIR IRR services > > directly. Instead, the common practise is that utilities such as bgpq3, > > peval, and bgpq4 query “IRRd” (https://IRRd.net) instances at for example > > whois.radb.net and rr.ntt.net. You can verify this with tcpdump. These > > IRRd instances serve as intermediate caches, and will continue to serve old > > cached data in case the origin is down. This phenomenon in the global IRR > > deployment avoids a lot of potential for circular dependencies. > > > > Also, some organisations use threshold checks before deploying new > > IRR-based filters to reduce risk of “misfiring”. > > > > > beyond just 'did the filter deployed change by +/- X%' > you probably don't want to deploy content if you can't actually talk to the > source... which was anurag's proposed problem. > The point that Job was (I think?) trying to make was that by querying a mirror for IRR data at filter generation time, as opposed to the source DB directly, the issue that Anurag envisioned can be avoided.
I would recommend that anyone (esp. transit operators) using IRR data for filter generation run a local mirror whose reachability is not subject to IRR-based filters. Of course, disruption of the NRTM connection between the mirror and the source DB can still result in local data becoming stale/incomplete. You can imagine a situation where an NRTM update to an object covering the source DB address space is missed during a connectivity outage, and that missed change causes the outage to become persistent. However, I think that is fairly contrived. I have certainly never seen it in practise. Cheers, Ben
signature.asc
Description: PGP signature
