Great initiative Anil. I agree that it should be up to applications to ensure uniqueness of the cookie. This is something we can take it up in Genius project which was designed to solve these kind of problems. It will take care of uniqueness for applications using Genius while rest can use Genius code as a reference.
Regards, Vishal. From: [email protected] [mailto:[email protected]] On Behalf Of Anil Vishnoi Sent: 04 January 2017 08:22 To: [email protected] Subject: [openflowplugin-dev] Using cookie as a flow-id 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. 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. let me know your thoughts ? If committers think this proposal make sense i can open an enhancement bug and prioritize it. -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
