Re: [Sidrops] rfc8210bis further review - question 4

[Job Snijders <[e-mail]>]

Hi Claudio,

Right this should be mandated: an expectation should be set that valid ROAs
on the same manifest, or multiple VRPs in single ROA end up in a single RTR
delta. Similarly, VRPs shouldn’t take effect until the End of Data marker
is been received. Hoping for the best as information drips in is a needless
complication.

Section 11 needs work, the race conditions it warns about can be avoided
with more stringent and precise guidance.

Kind regards,

Job

On Sat, 9 Mar 2024 at 17:23, Claudio Jeker <[e-mail]> wrote:

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