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
