[dev] Some doubts regarding asynchronous data plane in FRR

Mark Stapp mjs at voltanet.io
Mon Jul 29 08:58:25 EDT 2019

thanks for your good questions - some answers inline:

On Sat, Jul 27, 2019 at 11:55 PM sudhanshu kumar <sudhanshu22 at gmail.com>

> Hi,
> I have 2 doubts regarding asynchronous dataplane implementation in FRR.
> 1. When there are multiple dplanes, each can process the same route
> context and modify the status in the context. But while
> processing rib_process_after(), we only consider the status returned by the
> last processed provider. Is this correct? We should, in this case, consider
> status returned by all the providers. If all of them return success, then
> only, we should consider the status as success in rib_process_after().

One correction - we actually consider an update to be an 'error' as soon as
an error status is set by a provider. so we are capturing the _first_
error, not the last status.

We've had conversation about this from time to time, but there are several
related/entangled issues. the core, platform-neutral zebra code is only
prepared to process one result. given the way that zebra (and frr) are
being used in most cases, in systems where there is only a single FIB, a
single dataplane, that makes sense and is appropriate. if more complex
systems become more common, we may want to revisit how we capture and
report status. at the very least, it may make sense to be able to report
more complex results through the management system.

> 2. Currently, zebra fpm interaction happens in rib context using hook. I
> would like to know why this was done ? Can this be made as a separate
> dplane ?
we've talked about this a bit too. moving the fpm messaging to be a dplane
plugin would be pretty natural (since it's one-way, outgoing only). it just
hasn't been a priority for anyone yet. I expect it will happen, and it
would allow some simplification of zebra code in some places.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20190729/5c03b69b/attachment.html>

More information about the dev mailing list