https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/OPNFLWPLUG-651 OpenFlowPlugin <p>New FRM calculates the delta between the config modifications. It would not work correctly without retries in negative scenario. We expect that we need to improve FRM while testing&amp;debugging <a href="https://bugs.opendaylight.org/show_bug.cgi?id=5576" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=5576</a>.</p> <p>Operating System: All<br/> Platform: All</p> OPNFLWPLUG-651

New FRM RETRY mechanism for RCP call

Bug Resolved Done Jozef Bacigal Jozef Slezák Tue, 22 Mar 2016 08:52:16 +0000 Mon, 27 Sep 2021 09:01:46 +0000 Tue, 21 Jun 2016 09:12:50 +0000 General 0 4 <p>Hi Jozef,</p> <p>Where is this new FRM sitting? Can you please explain what this new FRM is doing different then the existing FRM and what's the need for having new FRM and not modifying the existing one ?</p> <p>@Anil Vishnoi, there are several advantages of new FRM but the main are:<br/> 1/ when switch is connected to the Controller then Mark&amp;Sweep will be done. It means add missing flows/groups/meters, update and after that remove.<br/> 2/ there are automatic barriers between dependent objects (flow -&gt; group, group -&gt; group...)<br/> 3/ state compression while writing to the switch (on per switch granularity)</p> <p>will not adding barriers between dependent objects take a performance hit in case multiple dependent objects in the order of 1000s are being pushed ?</p> <p>Hi Shuva, <br/> as there must be barriers between dependent objects anyway, it is about trade-off between traffic and latency.</p> <p>We can wait for implicit barrier (or gathered statistics) which stands for lower traffic but higher latency. Or we can send explicit barrier which causes higher traffic but lower latency. The second approach seems more reasonable to me.</p> <p>In addition, we would like to continue with optimization in new FRM and don't wait for barriers in requests where it's not necessary.</p> <p>gerrit: <a href="https://git.opendaylight.org/gerrit/#/c/39309/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/39309/</a></p> <p>Hi Andrej,</p> <p>I can't access this gerrit for some reason.</p> <p>Thanks<br/> Anil</p> <p>As per my understanding this new implementation is going to clean up the switch and write all the configuration (flow/group/meter) back when switch connects. How do you handle a situation where flows have specific timeout and they expired when switch was disconnected from the controller. With the current approach, whenever switch will connect back to the controller, it will install the flow again on the switch, which actually is not a correct behavior.</p> <p>Hi Anil,<br/> it will not clean up the switch by default. Actually, reconciliation with actual config will be done (on device contected). See also <a href="https://jira.opendaylight.org/browse/OPNFLWPLUG-692" title="FR-sync - Improve FRM reconciliation - do not wipe out device when it is not configured" class="issue-link" data-issue-key="OPNFLWPLUG-692"><del>OPNFLWPLUG-692</del></a>.</p> <p>Hi Andrej,</p> <p>I looked at the <a href="https://jira.opendaylight.org/browse/OPNFLWPLUG-692" title="FR-sync - Improve FRM reconciliation - do not wipe out device when it is not configured" class="issue-link" data-issue-key="OPNFLWPLUG-692"><del>OPNFLWPLUG-692</del></a> but didn't get the clarity about what new FRM will do in case of the scenario i mentioned in above comment.Let me know if this scenario is not clear to you.</p> <p>HI Andrej, </p> <p>You have mentioned that that the new FRM will use barriers between dependent objects. But, how would the dependent objects be detected ? By doing "full scan of datastore" ?</p> <p>@Anil<br/> Scenario is clear, unfortunately it is not related to retry mechanism. Retry should start when config change failed and enforce reconciliation (syncup) with recent config against operational data. <br/> Ad your scenario - AFAIK, it is not in the scope of new or actual FRM to keep track of flow timeouts in case of device disconnection. From my point of view, user should look after these flows. If we would try to address all details like this, we will have clever but at the same time much more complicated and complex app.</p> <p>@Muthukumaran<br/> FR-sync is now using SalFlatBatchService from OFP which works with the list of batches of changes with the same type (F/G/M - A/U/R). This service decides in the process of assembling batch plan if barrier is needed before next (actually after previous) plan step or not. If yes, it is marked in plan step, then batch chain is prepared and executed. Check SalFlatBatchServiceImpl, FlatBatchUtil, etc. in openflowplugin-impl.</p> Blocks OPNFLWPLUG-649 OPNFLWPLUG-673 Development External issue ID 5577 External issue URL ODL SR Target Milestone Rank 0|i032gv: