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

[Job Snijders <[e-mail]>]

reminder, this is the 'sidr operations group of 2020/2021'.

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

I understand a desire to phrase ideas 'in the abstract' and talk about
protocols as a sequence of communication steps between 'autonomous
systems', rather than reference individual software processes by their
brand name. However, some in this working group are implementing without
any perspective on the entire inter-domain system, and they might
benefit from guidance spelled out in terms such as 'oneshot' and
'server' modes.

To complicate things further, in some RPKI ROV deployments the
'fetcher', 'validator', and 'RTR server' are conflated into a single
software process, which can muddy dialogue at times.

> > 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.

you hint here https://mailarchive.ietf.org/arch/msg/sidrops/LrNY0v3dy6WQDIrtzazHjhgygh0/

My observation is that unavailability of RRDP service indicates nothing
about the state and availability of a CA Repository's RSYNC service.

The only important thing for me (as Relying Party) is to only spend
bandwidth and CPU on fetching via RSYNC, iff I was NOT able to
successfully fetch from the CA's RRDP service.

Whether the RRDP or RSYNC fetch were successful or not, in the next
fetching event (which is expected to occur between 30 and 60 minutes
later) I should first try fetching from RRDP URIs discovered in the
objects fetched via RSYNC (or fetched via RRDP). If the RRDP fetching
process resulted in some kind of error (HTTP 404, 5xx, connection
refused, DNS problem, etc), I should try to fetch the data via RSYNC
service.

As the world's Relying Parties' software instances were not all booted
at the exact same moment, logically, the collective's fetch events are
not synchronized to any other particular minute of the hour. This is an
excellent characteristic of the existing global RPKI deployment! :)

In retrospect it seems it might have been a mistake to ever even hint
RRDP could be polled every minute.

[ process thought:
    We now have RFC 6481, RFC 8182, draft-ietf-sidrops-prefer-rrdp,
    draft-ietf-sidrops-rov-timing, and now these emails. Confusion might
    be growing instead of being reduced...

    ... would the working group perhaps benefit from a Finite State
    Machine (FSM) specification in which fetches via both RRDP and RSYNC
    protocols are described as events and various timers are also
    described? ]

Is the below the short summary people agree to?

	- Try RRDP first
	- Immediately fall back to RSYNC if RRDP didn't work
	- Don't contact RRDP URIs more than once every 10 minutes
	- Don't contact RSYNC URIs more than once every 30 minutes
	- Don't contact RRDP or RSYNC URIs less than once ever 60 minutes

Kind regards,

Job