Add support for FlowRemoved messages in OpenFlow 0x01

[jnfoster]

No description provided.

[arjunguha]

nate, if you use 4.01, label overlaps won't be a problem. i think we should ditch 4.00.1 entirely (and stop trying to build it on travis)

[jnfoster]

So 4.01 allows overlapping record fields and type inference disambiguates. Older versions do not disambiguate.

In this case, flowMod and flowRemoved have overlapping fields (pattern, cookie, priority, etc.). I prefixed the flowRemoved versions with removed_. But it'd be nice to have a more systematic solution here.

[jnfoster]

What Arjun said. I'm happy saying we require OCaml 4.01.

[jnfoster]

I'd love to keep a close correspondence between our names and OpenFlow spec names.

[arjunguha]

OK. This is building cleanly now. I'm going to modify frenetic and ocaml-topology to also require 4.01.0. Is this ok?

[jnfoster]

SGTM.

-N

On Mon, Dec 23, 2013 at 10:57 AM, Arjun Guha notifications@github.comwrote:

OK. This is building cleanly now. I'm going to modify frenetic and
ocaml-topology to also require 4.01.0. Is this ok?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/52#issuecomment-31126398
.

[adferguson]

hey guys,

I was wondering if you would share your thoughts on how you see this being used? particularly how it will connect with Net(Core|KAT)

I was initially very excited to see this go in as it is very helpful for the NAT I was about to implement. :-) by setting an Idle Timeout on the translation rules, the controller will learn which port numbers have become available when the NAT'd flow is finished.

the complication when using a language with a higher level of abstraction than pure OpenFlow rules, is that the compiler might generate 2 or more OF rules from the "policy fragment" for which you want an Idle Timeout. hence, you really want the rules to expire after the last such OF rule has expired...

now, with NAT, this isn't actually an issue since it's a pure microflow play -- the switch shouldn't wind-up with multiple OF rules for the same NAT policy fragment. hence, for my needs, I'm simply going to slip it into the NetCore Action since I know only one OF rule will get that particular NAT action.

however, in the general case, you'd probably need the Net(Core|KAT) runtime, rather than the switch firmware, to implement the Idle Timeout, by regularly polling the counters on the 2+ compiled OF rules, right?

I suppose another nice use for Idle Timeout could be to have an Idle Timeout on the entire policy if you are doing consistent updates. there, as well, you might need to worry about these issues so much, but I'm just speculating.

anyway, just curious what your thoughts and plans are!

cheers,
Andrew

[jnfoster]

For the HeisenKAT team: another use for network registers?

[reitblatt]

Wouldn't this be better suited for a query? Do you really want to know when
a rule expires, or when you haven't seen a specific header in a specific
location in a while? The former is just one possible mechanism for
determining the latter.

On Wed, Dec 25, 2013 at 2:42 PM, Nate Foster notifications@github.comwrote:

For the HeisenKAT team: another use for network registers?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/52#issuecomment-31204284
.

[adferguson]

yup, exactly! it's just a mechanism for implementing that query with the two specific actions of "remove flow and notify controller". in the general case, you may be forced to implement this with a query and runtime support to preserve the semantics.

however, when you can implement this optimization, it is very important to do so since reading counters takes such a long time. without it, a switch with several hundred NAT flows would have an impractically long loop just for reading counters. :-/

hope this makes sense,
Andrew

On Dec 25, 2013, at 2:58 PM, Mark Reitblatt notifications@github.com wrote:

Wouldn't this be better suited for a query? Do you really want to know when
a rule expires, or when you haven't seen a specific header in a specific
location in a while? The former is just one possible mechanism for
determining the latter.

On Wed, Dec 25, 2013 at 2:42 PM, Nate Foster notifications@github.comwrote:

For the HeisenKAT team: another use for network registers?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/52#issuecomment-31204284
.

—
Reply to this email directly or view it on GitHub.