Question is - is this a bug or a feature? i.e. in case of L2 switch - they would not have any issues as they have just used the RPCs and have no flow in the config datastore. In the case of the apps or someone manually using the config datastore (via RESTCONF) - if the code is magically making sure the flow ID is the same when the flow is put in the operational datastore - then that should not be a problem (I think?). The potential problem may be if there are some flows written in via RPCs - get a particular flow ID & then some app uses config datastore and their flow ID is already taken by the flow programmed using RPC.
On Thu, Apr 14, 2016 at 3:34 PM, Luis Gomez <[email protected]> wrote: > Hi ofplugin devs, > > I have just realized about a difference between He and Li plugins when > testing openflow app (l2switch): l2switch does not use config datastore to > program flows (I guess it does RPC) so with: 1) He plugin I see these flows > in operational with alien id (e.g. #UF$TABLE*0-2) while with 2) Li plugin I > see these flows in operational with normal id (e.g. 2). Even when there is > no much difference on how we generate these IDs, today if someone adds a > flow in DS with an ID that exists in operational but not in config, the > controller adds the new flow in the switch and stops reporting the original > flow even when it exists in the switch, this can be seen as a controller > issue. So in our case, if an app/user wanted to add a flow in config > datastore, with 1) it seems very unlike it would use the same flow ID as > l2switch uses, but with 2) this probability increases very much. So any > reason for this change in Li plugin or is this a bug? > > BR/Luis > _______________________________________________ > L2switch-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/l2switch-dev >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
