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

Randy Bush <> Sat, 27 March 2021 03:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF3133A1BA3 for <>; Fri, 26 Mar 2021 20:16:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fyw_LgnLA1io for <>; Fri, 26 Mar 2021 20:16:28 -0700 (PDT)
Received: from ( [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 460973A1BAF for <>; Fri, 26 Mar 2021 20:16:24 -0700 (PDT)
Received: from localhost ([] by with esmtp (Exim 4.90_1) (envelope-from <>) id 1lPzQw-0004VP-4V; Sat, 27 Mar 2021 03:16:18 +0000
Date: Fri, 26 Mar 2021 20:16:17 -0700
Message-ID: <>
From: Randy Bush <>
To: Job Snijders <>
Cc: Ties de Kock <>, SIDR Operations WG <>, Tim Bruijnzeels <>
In-Reply-To: <YF5YxjxVVgjugJHQ@snel>
References: <> <> <> <YF4Irln8qM4w8i3o@snel> <> <YF5YxjxVVgjugJHQ@snel>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 27 Mar 2021 03:16:31 -0000

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

yup.  indeed that is why we do abstract protocol specs.

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

i confess to trolling.  as we were taught in first year

    a manhattenite has a lover in brooklyn and one in the bronx (hint:
    they are in opposite directions).  at the manhattan station, both
    trains come every ten minutes.  but our friend finds that, if they
    take the first that comes, they visit the lover in brooklyn far more
    frequently than the one in the bronx.

    it’s the interleave.  the one to brooklyn comes two minutes before
    the one to bronx.  so there is an eight minute window for brooklyn
    and a two minute window for the bronx.

i have not yet seen a case that rrdp exhibits convoy behavior

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

except in extreme cases such as destination unreachable.  but i take
your point.

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

i suspect you could be made to regret "only important."  we would prefer
rrdp; when it works.

> 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! :)

yes.  as i said, i have yet to see an argument for convoy phenomena.

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


>     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? ]

in the words of vince perriello, send code :)

> 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

i certainly do not agree to that last line, and doubt you do

as far as the other numbers, see draft-ietf-sidrops-rpki-rov-timing for
my current opinion.  but i am willing to listen.