By same mechanism you mean, using the same format for the flow-id creation?
On Fri, Apr 15, 2016 at 3:27 PM, Abhijit Kumbhare <abhijitk...@gmail.com> wrote: > In-line. > > On Fri, Apr 15, 2016 at 2:27 PM, Anil Vishnoi <vishnoia...@gmail.com> > 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 <abhijitk...@gmail.com> >> 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 <ece...@gmail.com> 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 >>>> l2switch-...@lists.opendaylight.org >>>> https://lists.opendaylight.org/mailman/listinfo/l2switch-dev >>>> >>> >>> >>> _______________________________________________ >>> openflowplugin-dev mailing list >>> openflowplugin-dev@lists.opendaylight.org >>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >>> >>> >> >> >> -- >> Thanks >> Anil >> > > -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list openflowplugin-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
