Sounds good . Br,shuva
On Thu, Jan 5, 2017 at 9:37 PM, Anil Vishnoi <[email protected]> wrote: > Well that's true for flow installation as well, multiple application can > install similar flow and end up breaking themself because they don't see > the flow in data store on the same location. So if you have multiple > application in the deployment, you need to make sure that they use same > cookie management system. > > On Thu, Jan 5, 2017 at 7:52 AM, Shuva Kar <[email protected]> > wrote: > >> Got it Anil. >> >> But given the condition of multiple applications co-existence would not >> having 2 different sources of cookie management, a recipe for more >> disasters, since in such cases the cookies can collide. >> >> >> >> Br,shuva >> >> On Thu, Jan 5, 2017 at 1:26 PM, Anil Vishnoi <[email protected]> >> wrote: >> >>> contract is simple, whatever way user configures the flow, they should >>> use unique cookie value. To make sure the uniqueness either application can >>> use it's own cookie management or they can use the application provided by >>> the plugin or any other way. >>> >>> On Wed, Jan 4, 2017 at 10:55 PM, Shuva Kar <[email protected] >>> > wrote: >>> >>>> Sounds good Anil. But if the flow provisioned through the rpc uses an >>>> already existing cookie value, do we throw up while collecting stats saying >>>> that the cookie is duplicate or do we use Alien-id in that case? >>>> >>>> >>>> Br,shuva >>>> >>>> On Wed, Jan 4, 2017 at 11:52 PM, Anil Vishnoi <[email protected]> >>>> wrote: >>>> >>>>> I think we should use cookie based comparison only for the flows >>>>> installed through the data store. So as far as flow is added/deleted >>>>> through data store it's easy to maintain the cache. I think cookie_mask >>>>> based deletion is something that you can't do through data store, so we >>>>> won't get into the situation where we will have to maintain the cache >>>>> based >>>>> on cookie_mask. For the flow that is installed through rpc, we should >>>>> directly augment the flow statistics to operational data store using the >>>>> cookie value. That's the current implementation as well but it uses alien >>>>> id, but augmenting it using the cookie value will help application to >>>>> write >>>>> deterministic logic, because they will know where the operational data of >>>>> the flow will be written. Also we won't have to maintain any cache as well >>>>> for rpc. >>>>> >>>>> On Wed, Jan 4, 2017 at 9:33 AM, Shuva Kar < >>>>> [email protected]> wrote: >>>>> >>>>>> Missed the list, >>>>>> >>>>>> Br,shuva >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: Shuva Kar <[email protected]> >>>>>> Date: Wed, Jan 4, 2017 at 11:00 PM >>>>>> Subject: Re: [openflowplugin-dev] Using cookie as a flow-id >>>>>> To: Anil Vishnoi <[email protected]> >>>>>> >>>>>> >>>>>> But we still need to update the cache maintained for the CRS(Cookie >>>>>> Reservation System) to do the comparison in case of flow deletes and >>>>>> modifications, wont that mess the mappings with a cookie_mask, or do for >>>>>> the simplistic approach assme the cookie mask is 0 and proceed for all >>>>>> the >>>>>> cookies assigned from/by the CRS ? >>>>>> >>>>>> Br,shuva >>>>>> >>>>>> On Wed, Jan 4, 2017 at 2:52 PM, Anil Vishnoi <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Muthu, >>>>>>> >>>>>>> cookie_mask has no significance when it comes to flow add operation, >>>>>>> it's only used for wildcard matching for flow modification/deletion >>>>>>> operations. So as per my understanding of the spec, if you install flow >>>>>>> with cookie=1234 with mask=ff00 and fetch the stats from the switch it >>>>>>> should return the cookie=1234 and mask=ff00, rather then cookie=1200 ans >>>>>>> mask=ff00. So from uniqueness perspective we just have to look at the >>>>>>> cookie value only. Here are few snippets from the spec >>>>>>> >>>>>>> uint64_t cookie_mask; /* Mask used to restrict the cookie bits >>>>>>> that must match when the >>>>>>> command is >>>>>>> OFPFC_MODIFY* or OFPFC_DELETE*. >>>>>>> A value of 0 indicates no >>>>>>> restriction. */ >>>>>>> >>>>>>> >>>>>>> If the cookie_mask field is non-zero, it is used with the cookie >>>>>>> field to restrict flow matching while modifying or deleting flow >>>>>>> entries. *This >>>>>>> field is ignored by OFPFC_ADD messages.* The cookie_mask field’s >>>>>>> behavior is explained in Section 6.4. >>>>>>> >>>>>>> So i think from plugin and stats collection perspective, just >>>>>>> matching based on the cookie value is enough. >>>>>>> >>>>>>> >>>>>>> On Tue, Jan 3, 2017 at 8:39 PM, Muthukumaran K < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi Anil, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I was checking how the uniqueness of cookie would be influenced by >>>>>>>> cookie_mask. Also the rules of comparison in presence and absence of >>>>>>>> cookie_mask. >>>>>>>> >>>>>>>> Again, cookie_mask is something which applications could decide and >>>>>>>> specify while requesting cookie / cookie range reservation. If >>>>>>>> cookie_mask >>>>>>>> is ‘0’ then entire cookie field would be used for comparison while >>>>>>>> comparing cookie from stats to that of config flow. If cookie field is >>>>>>>> non-zero then comparison would follow the rule stated in section 6.4 >>>>>>>> of OF >>>>>>>> 1.3.1 spec. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Some aspects on cardinality especially in presence of non-zero >>>>>>>> cookie_mask which we may have to bolt on to >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> App : Cookie-Range è 1:1 >>>>>>>> >>>>>>>> Cookie-Range : Cookie_mask è 1:1 OR 1:Many >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> App : Cookie è 1:1 >>>>>>>> >>>>>>>> Cookie : Cookie-mask è 1:1 OR 1:Many >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Contract between application and cookie-reservation service (of >>>>>>>> OFPlugin) would vary based on cardinality of cookie-mask wrt cookie or >>>>>>>> cookie-range. Unless applications use cookie-mask very extensively, >>>>>>>> simple >>>>>>>> 1:1 mapping could be less bug-prone >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Am I overlooking something grossly or being paranoid ? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Muthu >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *From:* [email protected] [mailto: >>>>>>>> [email protected]] *On Behalf Of *Anil >>>>>>>> Vishnoi >>>>>>>> *Sent:* Wednesday, January 04, 2017 9:13 AM >>>>>>>> *To:* Luis Gomez <[email protected]> >>>>>>>> *Cc:* [email protected] >>>>>>>> *Subject:* Re: [openflowplugin-dev] Using cookie as a flow-id >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jan 3, 2017 at 7:28 PM, Luis Gomez <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Jan 3, 2017, at 6:52 PM, Anil Vishnoi <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This thread is about the proposal I discussed during the >>>>>>>> openflowplugin meeting two weeks ago. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Currently statistics collection use custom comparator to compare >>>>>>>> the flows that it fetches from the switch with the config flows. The >>>>>>>> main >>>>>>>> reason for that is because openflow flow definition don't have any >>>>>>>> unique >>>>>>>> id, like group and meters, so we have to compare the flows based on >>>>>>>> all the >>>>>>>> match tuples of the flow. This custom comparator is a can of worms, >>>>>>>> because >>>>>>>> of the two reasons >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> (1) It tries to normalize the data coming from switch and compare >>>>>>>> with config data store. It's costly and buggy. >>>>>>>> >>>>>>>> (2) Currently flow comparison fails if flows are same on the >>>>>>>> standard match tuple, but differs only by the extensions match tuple. >>>>>>>> Also >>>>>>>> in my opinion we can't afford to use custom comparator till the level >>>>>>>> of >>>>>>>> extension match, as it will increase the matching complexity, hamper >>>>>>>> performance and possibly introduce more bugs. Also it will increase >>>>>>>> complexity for writing pluggable vendor specific extensions. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> So i want to put the following proposal on the table for the >>>>>>>> discussion to resolve this longstanding issue. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Provide a config knob to user (e.g >>>>>>>> enable-cookie-based-comparison=true). >>>>>>>> when this flag is enabled, plugin will not use the custom comparators >>>>>>>> to >>>>>>>> match the switch and config flows, but will only use cookie value to >>>>>>>> match. >>>>>>>> By default it should be false, so it's going to be business as usual >>>>>>>> for >>>>>>>> the dependent project. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Pros: It will resolve (1) and (2) and we will reduce lot of flow >>>>>>>> matching related bugs from our list. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Cons: I won't say cons, but implementing this solution require to >>>>>>>> resolve one other problem-- who will make sure the uniqueness of the >>>>>>>> cookie? I think as a plugin, we should provide a simple contract that >>>>>>>> application should be responsible for using the unique cookie, plugin >>>>>>>> can >>>>>>>> probably write an error message to the operational data store if >>>>>>>> application uses the used cookie value. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Now this actually pushes the problem to the application level and >>>>>>>> in my opinion it should be solved at the application level. Cookie >>>>>>>> management is kind of resource management problem and there are >>>>>>>> multiple >>>>>>>> way it can be done. At a plugin level we can write an application that >>>>>>>> can >>>>>>>> provide a vanilla implementation of cookie reservation (assign >>>>>>>> individual >>>>>>>> cookie, cookie range etc) for the application to use, but if >>>>>>>> application >>>>>>>> want to use it's own implementation, they are free to do that as well. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I think your suggestion makes sense and it is probably enough work >>>>>>>> for this release, in future we could have an application in ofplugin or >>>>>>>> another project to proper handle and distribute cookies among >>>>>>>> applications. >>>>>>>> >>>>>>>> I think adding this flag is not a much of work, but writing the >>>>>>>> cookie management application is a bit of work. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Note: We will still have alien-id in the operational data store, >>>>>>>> but those will only be present when user will use RPC for flow >>>>>>>> installation, because in this scenario flow is not present in the >>>>>>>> config >>>>>>>> data store, which i believe is a clear contract compared to the >>>>>>>> existing >>>>>>>> one.As an enhancement we can use cookie value itself as a alien-id so >>>>>>>> it's >>>>>>>> going to be easy for application to look for the respective flow in >>>>>>>> operational data store. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Interesting idea, so you mean the plugin in >>>>>>>> "cookie-based-comparison" mode (i.e. all cookies are unique) will >>>>>>>> lookup >>>>>>>> received cookies in the config DS and: 1) in case of match, it will set >>>>>>>> oper flow-ID= config flow-ID, 2) if no match, it will set oper >>>>>>>> flow-ID=cookie. >>>>>>>> >>>>>>>> Yes, but minor correction, in case of (1), it won't look in config >>>>>>>> data store, it will internally maintain the cache, so we will avoid DS >>>>>>>> read >>>>>>>> operation. Also using cookie-id=flow-id to store the flow will be >>>>>>>> helpful >>>>>>>> for applications to find the flow in operational data store. They can >>>>>>>> even >>>>>>>> register a listener directly on the path, because they will exactly >>>>>>>> know >>>>>>>> the path of the flow (node/table/cookie-id). I think that will make >>>>>>>> application logic more simple. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> let me know your thoughts ? If committers think this proposal make >>>>>>>> sense i can open an enhancement bug and prioritize it. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Anil >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Anil >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thanks >>>>>>> Anil >>>>>>> >>>>>>> _______________________________________________ >>>>>>> openflowplugin-dev mailing list >>>>>>> [email protected] >>>>>>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> openflowplugin-dev mailing list >>>>>> [email protected] >>>>>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks >>>>> Anil >>>>> >>>> >>>> >>> >>> >>> -- >>> Thanks >>> Anil >>> >> >> > > > -- > Thanks > Anil >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
