Yes. On Fri, Apr 15, 2016 at 3:29 PM, Anil Vishnoi <vishnoia...@gmail.com> wrote:
> 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
