I might be wrong, but from my understanding there is nothing in
OpenFlow that dictates reliable execution of commands received.
btw; I can't resist and comment this by saying that unreliable (silently
dropped) control plane operations of OF complicate development of any
controller quite a bit. To this date, I haven't heard a valid reason why the
protocol semantics should be such for any of the OF messages. No, overload
conditions are not such a reason.
I absolutely agree, this needs to be fixed in the OpenFlow specification.
Else, it is near impossible to build scalable controllers who maintain
consistent state. The only caveats to consider would be for packet ins (we can
maintain the best effort delivery model for datagram forwarding) and
potentially flow expirations due to inactivity timers.
Packet-ins definitely belong to the data plane and can be reliable but flow expirations are definitely a part of control plane operations which should be reliable.
We're rehashing a very old discussion point here. Certainly flows
treated has hard state should be reliable. It isn't clear to me that
soft state necessarily should be. Often there is no trigger for L2
entry timeouts in hardware for example. In any case, it's a fairly
minor point and one I don't feel particularly strong about.
_______________________________________________
nox-dev mailing list
[email protected]
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
