[Sidrops] Re: rfc8210bis further review - question 3

[Randy Bush <[e-mail]>]

howdy

pushing a rev with the ASPA PDU as martin suggested.  the associated
text may still need some thinking.  i suspect we will chase this woozle
around the tree a couple more times.

> Section 12 "Deployment Scenarios" - I'm not sure this section serves a
> purpose in an already lengthy document.

tend to agree, and love removing code, except for

        To keep load on Global RPKI services from unnecessary peaks, it
        is recommended that caches which fetch from the Global RPKI not
        do so all at the same times, e.g., on the hour.  Choose a random
        time, perhaps the ISP's AS number modulo 60, and jitter the
        inter-fetch timing.

moved it up to Router-Cache Setup and removed § Deployment Scenarios

> Question 4
> ==========
> 
> Section 11 "ROA PDU Race Minimization" talks about how 'an initial
> full load' might cause issues, and therefor the cache should send the
> PDUs in a specific order and also try to group the PDUs together in a
> specific way.
> 
> But this protocol also has an 'End of Data' marker, which is a strong
> signal that the router received a complete and full load, after which
> the router can commit to using the received data and commence
> convergence.
> 
> It seems to me that a potential for race conditions is avoided by
> recommending/mandating the router to buffer up the cache's response
> until it sees the End-of-Data marker. And of course that caches don't
> needlessly sprinkle ROAs for the same prefix across different Cache
> Responses.
> 
> 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."

if you have simple wording for a simple recipe which does not break or
place undue burden on existing router implementations, e.g. not making
existing platforms to buffer in memory a jillion vrps before processing
them, we're all ears.  being able to run rov on existing platforms has
been a major reason why it has succeeded.

also tried to make data merging more clear in § Serial Query.

randy