I think it would be better to use the [#UF$TABLE*0-7] for flow id in case of flows that are installed through RPC to prevent any nasty bugs.
Date: Fri, 15 Apr 2016 15:31:15 -0700 From: Abhijit Kumbhare <[email protected]<mailto:[email protected]>> To: Anil Vishnoi <[email protected]<mailto:[email protected]>> Cc: OpenDayLight-L2switch-Dev <[email protected]<mailto:[email protected]>>, openflowplugin-dev <[email protected]<mailto:[email protected]>> Subject: Re: [openflowplugin-dev] [L2switch-dev] Flow ID in operational Message-ID: <CAHce=87rosnnwliecazieotqmjpn4a8wrguwduvmidwcvqv...@mail.gmail.com<mailto:CAHce=87rosnnwliecazieotqmjpn4a8wrguwduvmidwcvqv...@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" Yes. On Fri, Apr 15, 2016 at 3:29 PM, Anil Vishnoi <[email protected]<mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]>> > wrote: > >> In-line. >> >> On Fri, Apr 15, 2016 at 2:27 PM, Anil Vishnoi >> <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> >>>>> https://lists.opendaylight.org/mailman/listinfo/l2switch-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> openflowplugin-dev mailing list >>>> [email protected]<mailto:[email protected]> >>>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >>>> >>>> >>> >>> >>> -- >>> Thanks >>> Anil >>> >> >> > > > -- > Thanks > Anil >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
