<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 29, 2021 at 8:14 AM Job Snijders via NANOG <<a href="mailto:nanog@nanog.org">nanog@nanog.org</a>> 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"><div dir="auto">Hi Anurag,</div><div dir="auto"><br></div><div dir="auto">Circular dependencies definitely are a thing to keep in mind when designing IRR and RPKI pipelines!</div><div dir="auto"><br></div><div dir="auto">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” (<a href="https://IRRd.net" target="_blank">https://IRRd.net</a>) instances at for example <a href="http://whois.radb.net" target="_blank">whois.radb.net</a> and <a href="http://rr.ntt.net" target="_blank">rr.ntt.net</a>. 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.</div><div dir="auto"><br></div><div dir="auto">Also, some organisations use threshold checks before deploying new IRR-based filters to reduce risk of “misfiring”.</div><div dir="auto"><br></div></blockquote><div><br></div><div>beyond just 'did the filter deployed change by +/- X%'</div><div>you probably don't want to deploy content if you can't actually talk to the source... which was anurag's proposed problem.<br><br>I suppose there are a myriad of actual failure modes though ;) and we'll always find more as deployments progress... hurray? </div></div></div>