On Tue, Nov 30, 2021 at 3:20 AM Ben Maddison <benm@workonline.africa> wrote:
Hi Chris,
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
On 11/29, Christopher Morrow wrote: 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.
yup, sure; "remove external dependencies, move them internal" :) you can STILL end up with zero prefixes even in this case, of course.
Of course, disruption of the NRTM connection between the mirror and the source DB can still result in local data becoming stale/incomplete.
yup!
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.
sure, there's a black-swan comment in here somewhere :) The overall comment set here is really: "Plan for errors and graceful resumption of service in their existence" (and planning is hard)
Cheers,
Ben