[OPNFLWPLUG-625] FRM Reconciliation (Synchronization, Mark&Sweep) Created: 24/Feb/16  Updated: 27/Sep/21  Resolved: 26/May/16

Status: Resolved
Project: OpenFlowPlugin
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Jozef Slezák Assignee: Andrej Leitner
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 5411

 Description   

Features needed:

  • Barrier between dependent Groups (Select Groups, FF Groups)
  • Barrier between Groups and Flows programming
  • Mark&Sweep reconciliation needed (instead of Switch wipeout)
  • Add new (new Flows/Groups with IDs that do not exist in Inventory Operational Store)
  • Update existing (existing IDs in both Inventory CONFIG and OPERATIONAL)
  • Remove old (old Flows/Groups with IDs that exist in Inventory Operational Store but not in Inventory Config)
  • Do not change order of instructions that needs to be programmed to Switches (parallel write to Inventory CONFIG and Switch reconnections) - synchronization needed.

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.

 Comments   
Comment by Shuva Jyoti Kar [ 04/May/16 ]

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

Comment by Andrej Leitner [ 10/May/16 ]

Hi Shuva,
works on upgraded FRM are already in progress - the chain is here:
https://git.opendaylight.org/gerrit/#/q/status:open+project:openflowplugin+branch:master+topic:bug5575-frm Check it out. You can find more information also in OPNFLWPLUG-649 & OPNFLWPLUG-651.

Comment by Shuva Jyoti Kar [ 11/May/16 ]

thanks Andrej,could you please let us know in what way is this better over the current FRM ?

Comment by Andrej Leitner [ 12/May/16 ]

Hopefully, we will discuss it during the next OF meeting, but the advantages are:

  • state compression (calculating diff) for new config changes (while writing to the switch, on per switch granularity)
  • support for batched changes - as it is currently using batch RPCs (actual FRM uses only incremental, thinking about possibility to make it switchable)
  • consistent pushing of dependent G/F/M (order and automatic barriers between dependent objects)
  • 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)
  • faster operations as the barrier usage can be optimized and still provide valid RPC outcome for all changes
  • possibility of strict config enforcement (config flag - default set to false)
Comment by Andrej Leitner [ 26/May/16 ]

Closing this unifying bug since new FRM (OPNFLWPLUG-649) is already merged - resides in applications as forwardingrules-sync - and all actual or future needs are described in other bugs.

Generated at Wed Feb 07 20:32:57 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.