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-625 OpenFlowPlugin <p>Features needed:</p> <ul class="alternate" type="square"> <li>Barrier between dependent Groups (Select Groups, FF Groups)</li> <li>Barrier between Groups and Flows programming</li> <li>Mark&amp;Sweep reconciliation needed (instead of Switch wipeout)</li> <li>Add new (new Flows/Groups with IDs that do not exist in Inventory Operational Store)</li> <li>Update existing (existing IDs in both Inventory CONFIG and OPERATIONAL)</li> <li>Remove old (old Flows/Groups with IDs that exist in Inventory Operational Store but not in Inventory Config)</li> <li>Do not change order of instructions that needs to be programmed to Switches (parallel write to Inventory CONFIG and Switch reconnections) - synchronization needed.</li> </ul> <p>These features are needed in specific Controller based on Beryllium. We assume that it is possible to used Beryllium Controller with newer version of OpenFlow Plugin (hybrid Karaf ZIP). This feature should be back-ported later in Service Release 1 of stable/Beryllium.</p> <p>Operating System: All<br/> Platform: All</p> OPNFLWPLUG-625

FRM Reconciliation (Synchronization, Mark&Sweep)

Bug Resolved Done Andrej Leitner Jozef Slezák Wed, 24 Feb 2016 12:21:07 +0000 Mon, 27 Sep 2021 09:01:44 +0000 Thu, 26 May 2016 11:54:23 +0000 General 0 3 <p>The current reconciliation does account for group-chaining and maintains the order of tables, groups, flows and meters and also does a stale marking of flows/groups/meters that have been removed while the connection was absent</p> <p>Hi Shuva,<br/> works on upgraded FRM are already in progress - the chain is here:<br/> <a href="https://git.opendaylight.org/gerrit/#/q/status:open+project:openflowplugin+branch:master+topic:bug5575-frm" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/q/status:open+project:openflowplugin+branch:master+topic:bug5575-frm</a> Check it out. You can find more information also in <a href="https://jira.opendaylight.org/browse/OPNFLWPLUG-649" title="New FRM client of Batch RPC" class="issue-link" data-issue-key="OPNFLWPLUG-649"><del>OPNFLWPLUG-649</del></a> &amp; <a href="https://jira.opendaylight.org/browse/OPNFLWPLUG-651" title="New FRM RETRY mechanism for RCP call" class="issue-link" data-issue-key="OPNFLWPLUG-651"><del>OPNFLWPLUG-651</del></a>.</p> <p>thanks Andrej,could you please let us know in what way is this better over the current FRM ?</p> <p>Hopefully, we will discuss it during the next OF meeting, but the advantages are:</p> <ul class="alternate" type="square"> <li>state compression (calculating diff) for new config changes (while writing to the switch, on per switch granularity)</li> <li>support for batched changes - as it is currently using batch RPCs (actual FRM uses only incremental, thinking about possibility to make it switchable)</li> <li>consistent pushing of dependent G/F/M (order and automatic barriers between dependent objects)</li> <li>in order to stay consistent, new FRM listens to whole node and decides the order of changes when pushing to device (changes have to be written atomically within one node)</li> <li>faster operations as the barrier usage can be optimized and still provide valid RPC outcome for all changes</li> <li>possibility of strict config enforcement (config flag - default set to false)</li> </ul> <p>Closing this unifying bug since new FRM (<a href="https://jira.opendaylight.org/browse/OPNFLWPLUG-649" title="New FRM client of Batch RPC" class="issue-link" data-issue-key="OPNFLWPLUG-649"><del>OPNFLWPLUG-649</del></a>) is already merged - resides in applications as forwardingrules-sync - and all actual or future needs are described in other bugs.</p> Development External issue ID 5411 External issue URL ODL SR Target Milestone Rank 0|i032b3: