Hi Murphy, Unfortunately this is not the case. The specification explicitly says that the switch is free to arbitrarily reorder messages. The controller must use a barrier to ensure ordering (similar to memory barriers in programming). I guess originally - up to OF 1.0 - this was not a big issue as there was only a single table, and flow_mods rarely depended on each other. Since OF 1.1, with multiple tables and groups you actually have to do a group_mod - barrier - flow_mod - barrier - flow_mod - barrier - ... sequence to make sure everything is OK. The problem with that is that barrier is global, i.e. if you have independent applications, they'll end up blocking each others' execution on the switch due to the barriers. (I had a proposal for positive acknowledgements, and there was another one for scoping barriers; unfortunately neither got accepted yet.)
Regarding the issue, I think this is indeed a race condition (I guess by the time NOX completes the handshake, and notifies the apps of the new switch, the delete all flow_mod is most probably done on the switch). Regards, Zoltan. > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Murphy McCauley > Sent: Friday, May 25, 2012 12:54 PM > To: Mabry Tyson > Cc: NOX developers mailing list > Subject: Re: [nox-dev] Possible bug in nox-classic nox.cc > > On May 25, 2012, at 3:23 AM, Mabry Tyson wrote: > > > I happened to notice this potential bug. I don't know > whether there is something else that might avoid this. And, > again, I saw this in Nox Classic. Maybe Nox/Pox does things > differently, or maybe they have the same issue: > > > > nox.cc tells the switch to delete all the rules on > registration of a switch. Shouldn't a barrier message be > sent immediately after that? It would seem that otherwise a > rule added after this might wind up getting deleted. > > Without having thought about this much, this doesn't seem > like it could be an issue. Deleting flows and adding flows > are both done with flow_mods. The problem you describe would > only seem to be possible if flow_mods were reordered relative > to other flow_mods. If flow_mods were reordered, it seems as > if the only way you could ever get predictable behavior doing > anything at all would be to always send a barrier after every > flow_mod, which seems unreasonable. Thus, it seems to me > that any switch where this is true is simply broken. > > No? > > -- Murphy > > (Incidentally, there's a tracker on github for bug reports -- > https://github.com/noxrepo/nox-classic/issues)
