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
