Re: [Sidrops] rfc8210bis further review - question 4

[Claudio Jeker <[e-mail]>]

On Sat, Mar 09, 2024 at 01:52:45PM +0100, Job Snijders wrote:
> Dear all,
> 
> 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.
> 
> Thoughts?

This is roughly what OpenBGPD does. We added a timeout for good measure
for the case that a RTR cache went out for lunch while serving a delta.

So in OpenBGPD updates to the ROA and ASPA trees are atomic both for each
RTR server and for the startup config itself.

>From my understanding not all router do the same and so following the make
before break rules in section 11 is good.
-- 
:wq Claudio