<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 30, 2021 at 3:20 AM Ben Maddison <benm@workonline.africa> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Chris,<br>
<br>
On 11/29, Christopher Morrow wrote:<br>
> On Mon, Nov 29, 2021 at 8:14 AM Job Snijders via NANOG <<a href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a>><br>
> wrote:<br>
> <br>
> > Hi Anurag,<br>
> ><br>
> > Circular dependencies definitely are a thing to keep in mind when<br>
> > designing IRR and RPKI pipelines!<br>
> ><br>
> > In the case of IRR: It is quite rare to query the RIR IRR services<br>
> > directly. Instead, the common practise is that utilities such as bgpq3,<br>
> > peval, and bgpq4 query “IRRd” (<a href="https://IRRd.net" rel="noreferrer" target="_blank">https://IRRd.net</a>) instances at for example<br>
> > <a href="http://whois.radb.net" rel="noreferrer" target="_blank">whois.radb.net</a> and <a href="http://rr.ntt.net" rel="noreferrer" target="_blank">rr.ntt.net</a>. You can verify this with tcpdump. These<br>
> > IRRd instances serve as intermediate caches, and will continue to serve old<br>
> > cached data in case the origin is down. This phenomenon in the global IRR<br>
> > deployment avoids a lot of potential for circular dependencies.<br>
> ><br>
> > Also, some organisations use threshold checks before deploying new<br>
> > IRR-based filters to reduce risk of “misfiring”.<br>
> ><br>
> ><br>
> beyond just 'did the filter deployed change by +/- X%'<br>
> you probably don't want to deploy content if you can't actually talk to the<br>
> source... which was anurag's proposed problem.<br>
> <br>
The point that Job was (I think?) trying to make was that by querying a<br>
mirror for IRR data at filter generation time, as opposed to the source<br>
DB directly, the issue that Anurag envisioned can be avoided.<br>
<br>
I would recommend that anyone (esp. transit operators) using IRR data<br>
for filter generation run a local mirror whose reachability is not<br>
subject to IRR-based filters.<br>
<br></blockquote><div><br></div><div>yup, sure; "remove external dependencies, move them  internal" :)</div><div>you can STILL end up with zero prefixes even in this case, of course.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Of course, disruption of the NRTM connection between the mirror and the<br>
source DB can still result in local data becoming stale/incomplete.<br>
<br></blockquote><div><br></div><div>yup!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
You can imagine a situation where an NRTM update to an object covering<br>
the source DB address space is missed during a connectivity outage, and<br>
that missed change causes the outage to become persistent.<br>
However, I think that is fairly contrived. I have certainly never seen<br>
it in practise.<br>
<br></blockquote><div><br></div><div>sure, there's a black-swan comment in here somewhere :)</div><div>The overall comment set here is really:</div><div>  "Plan for errors and graceful resumption of service in their existence"</div><div>  (and planning is hard)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Cheers,<br>
<br>
Ben<br>
</blockquote></div></div>