Re: Theorical question about cyclic dependency in IRR filtering

[Ben Maddison via NANOG <nanog () nanog org>]

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

Attachment: signature.asc
Description: