[Sidrops] Re: rfc8210bis further review - question 3

[Job Snijders <[e-mail]>]

On Tue, Aug 06, 2024 at 10:33:19AM -0700, Randy Bush wrote:
> > Issues in 'time delay' can be avoided by framing RTR as a
> > delta-delimited (not time-dependent) protocol, which it of course is.
> > Reading RTR PDUs off the wire straight into the route decision engine
> > without waiting for the End-of-Data marker is what may cause issues.
> > I expect that the router can do various pre-processing while reading &
> > waiting for the end-of-data marker, so I suspect promoting the
> > end-of-marker to be the pivot point, doesn't need to cause additional
> > delays.
> 
> it is a time delimited protocol because we do not know in what order
> the user enters data at the CA and we have no assurance that the CA/PP
> will push/publish two associated PDUs in the same link()/delta.  "uh,
> let's wait 37 seconds to see if the user hits the web page again."

No, it is not a time-delimited protocol. Because of RPKI Manifests, RPs
can calculate exactly when a publication point is complete and what the
CA intended to share with the world, and thus when what PDUs are to be
transmitted to RTR clients; even if information is smeared across
multiple RRDP deltas.