OpenFlow 1.0 IP addr wildcards

[adferguson]

support for the IP address wildcards in OpenFlow 1.0's NW_SRC and NW_DST match fields.

our fork of NetCore uses this to support masking those fields in a match using a new "WildcardPartial" type. with this, we are able to implement a Layer 3 (IP) router.

thanks!
Andrew

[adferguson]

travis CI build failed due to tests. will investigate.

[jnfoster]

Sweet. VInt abuse is starting to get super ugly. Int32m...

-N

On Thu, Dec 19, 2013 at 7:25 PM, Andrew Ferguson
notifications@github.comwrote:

travis CI build failed due to tests. will investigate.

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

[adferguson]

agreed. it was a somewhat dirty move in the interest of efficiency :-/ ... my reasoning:

1. OF 1.0 only supports shifted masks for the 32 bit IP source and IP dest.
2. this doesn't break anything which uses the SDN.mli abstraction layer (most important)
3. didn't know what your plans were for supporting the flexibility of OXM through the abstraction layer

the "right" thing is probably going to require breaking the SDN.mli abstraction layer, so instead of:

type fieldVal = VInt.t

you might have something like:

type fieldVal = 
  ExactMatch of VInt.t
  ShiftMaskedMatch of VInt.t match
  BitMaskedMatch of VInt.t match

but that's going to cause a lot of code to break. (plus, you can't set a masked value in the action side; they only make sense in the match) so ... the overloading/abuse of VInt might make sense in the end. :-/

(note that OF 1.0 masking is based on shifting bits [page 21 of spec], while OXM is based on toggling bits on & off [sections A.2.3.4 and A.2.3.5 in the 1.3.1 spec] ... since you can sometimes convert between the two, providing both abstractions makes some sense, at least.)

[jnfoster]

:-(

[reitblatt]

We can back it out; I don't think anyone else is using it yet. @adferguson would you mind carrying the patch for a bit until we have a more general solution worked out?

[adferguson]

if that's what you all prefer, then go ahead.

how long should I expect to wait for a more general solution? I ask because the more extra commits I'm carrying in my fork, the harder it is for me to contribute upstream.

thank you.

[jnfoster]

This is probably a good time to ask: what would it take to get you on
NetKAT? I've been worried about the divergence for a while...

-N

On Thu, Jan 2, 2014 at 12:59 AM, Andrew Ferguson
notifications@github.comwrote:

if that's what you all prefer, then go ahead.

how long should I expect to wait for a more general solution? I ask
because the more extra commits I'm carrying in my fork, the harder it is
for me to contribute upstream.

thank you.

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

[adferguson]

hi Nate,

great question. let me summarize my thinking:

• at a theoretical level, NetKAT should help us support more topologically-focused policies (ie, those policies which do not fit the "one big switch" abstraction: WAN load balancing, circuit provisioning, tight management of the number of switch hops to bound latency, cache placement and redirection, etc.), correct? when we move our focus to those, I can see a migration to NetKAT as being natural for us.
• at an engineering level, implementing the improvements I've pushed for in the various issues I've filed (whether Async-derived or otherwise) would definitely give us an incentive to move to NetKAT. :-)
• at a features level, I think getting Packet In done properly in the NetKAT controller is the main blocker. beyond that, these are the improvements I've made to our NetCore fork:
  • injective header modifications as long as you don't parallel compose them
  • matching masked IP addresses
  • delta updates
  • the ability to leave packets buffered while performing other work (e.g., performing ARP resolution)
  • fixed elimination of shadowed rules
  • handling FlowRemoved events
  • elimination of superfluous controller <-> switch traffic
  • enhanced internal data structures to pass metadata to and through the compiler -- this enables rules with Idle Timeout, is used to track how FlowLog fragments are transformed into OpenFlow rules (useful for debugging), and will further improve how we do delta updates.
• finally, at a timing level, it will almost certainly be after the SIGCOMM deadline unless you see the Async improvements & PacketIn support coming right away. I'm currently in Sydney but will have a chat with Tim about it when I return on the 9th.

anyway, I can easily send your group examples of our generated NetCore policies if that would be helpful.

Andrew