[Sidrops] Re: rfc8210bis further review - question 3

[Randy Bush <[e-mail]>]

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

agree it is a delimited protocol, i.e. there are publication demarcs.
but one does not know if correlated updates make it into the same
demarc, which is the pojnt here.

randy