<div dir="ltr"><div>Hi,</div><div>thanks for your good questions - some answers inline:<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 27, 2019 at 11:55 PM sudhanshu kumar <<a href="mailto:sudhanshu22@gmail.com">sudhanshu22@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<br><div>I have 2 doubts regarding asynchronous dataplane implementation in FRR.</div><div>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().</div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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 ?</div><div><br></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Mark<br></div></div></div>