Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-00.txt

[Randy Bush <[e-mail]>]

>> However, scaling rsync so it is available when all clients fallback in
>> a short period (we see ~1170 unique ips retrieve notification.xml in a
>> 10 minute window) is difficult.
> 
> Have you considered using a TCP proxy application like 'haproxy' to
> distribute rsync clients across multiple rsync backends? One can even
> anycast rsync servers to distribute load!

it is inappropriate to place undue financial and ops burden on the
operator of a publication point because we can not design protocols.

> It appears Randy came up with a simple suggestion:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpki-rov-timing-03

if you mean jittering fallover, credit to ggm.  but it is not clear to
me that it is actualy needed if the rrdp clients are not in convoy.

> The rpki-client default installation on OpenBSD/Ubuntu/Debian will be
> launched at a random minute of the hour, and will (for the lifetime of
> the governing cron/systemd process) fetch at that choosen minute of the
> hour.

yes, copied from drl's.  but those are arbitrary implementations, not
protocol specifications.

> Validator implementations which are started in 'oneshot' mode
> (rpki-client, 'routinator vrps', 'fort --mode=standalone') should
> immediately try rsync when RRDP fails for one reason or another.
> 
> A 'oneshot' implementation should not insert a 'sleep' between a failed
> rrdp fetch and an attempt to connect using rsync.

so you argue against ggm's jittered fallover delay?  maybe give us more
of a hint as to the motivation here.

randy

---
[e-mail]
`gpg --locate-external-keys --auto-key-locate wkd [e-mail]`
signatures are back, thanks to dmarc header butchery