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
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
