[routing-wg] RFO for RIPE NCC RPKI outage 16 February 2022

On Wed, 16 Feb 2022 at 19:49, Rob Austein <sra at hactrn.net> wrote:

> On Wed, 16 Feb 2022 13:10:27 -0500, Job Snijders wrote:
> > On Wed, 16 Feb 2022 at 19:07, Randy Bush <randy at psg.com> wrote:
> >
> >  sra commented to me that, an rp doing protocol fall-over from rrdp to
> >  rsync, or vice versa, has to do the full download as the data structure
> >  is so different.  i.e. load spike
> >
> > Perhaps it doesn’t need to be a full load: “rsync ―compare-dest”
> > (against a previously downloaded and validated set of signed
> > objects) offers a path towards optimising the protocol fall-over.
>
> Even assuming the RRDP client stores and believes the rsync URIs in
> the RRDP data stream, and further assuming that the client is clever
> enough to write out its RRDP-derived database into a directory tree
> which exactly matches an rsync filesystem layout before failing over,



The OpenBSD RPKI validator does the above, while maintaining robust
cryptographic integrity (in version 7.6 and higher). I hope other
validators take inspiration from this, similar to how we (OpenBSD) took
inspiration from the Dragon Labs implementation. Your work lives on and on,
hat tip to you Rob! :-)


RRDP doesn't convey things like file modification dates that rsync
> needs to perform an efficient incremental transfer, so the first rsync
> pass is still going to be expensive.
>
> Not obvious to me that there's any good way to optimize this.  YMMV.
>

Ties once pointed me at the GPL rsync “-c” (checksum) option, which makes
transfers more focussed on content rather than filesystem attributes. From
my (openrsync) this is still work to be done. I see a path :-)

Kind regards,

Job
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/routing-wg/attachments/20220216/51ea667b/attachment.html>