Yes - Shuva. That's what I meant by the same format - same format for the new design as was the case for older design.
On Friday, April 15, 2016, Shuva Jyoti Kar <[email protected]> wrote: > 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] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > > To: Anil Vishnoi <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > > Cc: OpenDayLight-L2switch-Dev <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>>, > > openflowplugin-dev < > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');> > > > > Subject: Re: [openflowplugin-dev] [L2switch-dev] Flow ID in > > operational > > Message-ID: > > < > CAHce=87rosnnwliecazieotqmjpn4a8wrguwduvmidwcvqv...@mail.gmail.com > <javascript:_e(%7B%7D,'cvml','cahce%5cx3d87rosnnwliecazieotqmjpn4a8wrguwduvmidwcvqv...@mail.gmail.com');> > > > > Content-Type: text/plain; charset="utf-8" > > > > Yes. > > > > On Fri, Apr 15, 2016 at 3:29 PM, Anil Vishnoi <[email protected] > <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > > > wrote: > > > > > >> In-line. > > >> > > >> On Fri, Apr 15, 2016 at 2:27 PM, Anil Vishnoi <[email protected] > <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[email protected]');> > > >>>>> https://lists.opendaylight.org/mailman/listinfo/l2switch-dev > > >>>>> > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> openflowplugin-dev mailing list > > >>>> [email protected] > <javascript:_e(%7B%7D,'cvml','[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
