Abhijit, for RPC,s flow id doesn't matter, because they just ignore it, because OF switch don't have any flow id construct. Flow id contention that luis mentioned above comes when you use a specific flow-id to dump stats in operational data store for rpc installed flows, but user uses the same flow-id to install some other flow through data store. In that case, whenever plugin fetch stats of the both the flow, it will update the stats of the flow that is present in the config data store, but not for the one that is installed through rpc. Now this issue can occur for both type of flow id, but as luis mentioned there is a higher probability of conflict when you use simple incremental number for flow id, rather the using a specific format flow id like (UF*TABLE*X--Y).
It's not a bug if user is careful, but it's pretty nasty bug if user is not careful and uses the incremental numbers as a flow id (which is not very unlikely scenario). On Fri, Apr 15, 2016 at 9:00 AM, Abhijit Kumbhare <[email protected]> wrote: > 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 > > -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
