In-line. On Fri, Apr 15, 2016 at 2:27 PM, Anil Vishnoi <[email protected]> wrote:
> 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. > Abhijit>> Yes - I was referring to the same contention. I guess - one possibility could be to just use the same mechanism for the RPC installed flows for the Li design as for the He design? > 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
