Thanks you Rob, I'm not totally out of my confusing stage but I think I'm on the right way.
So an intelligence is needed somewhere... Else in the controller that react to packet-in by sending packet-out and/or flow-mod... Else in an orchestrator tool that is aware of changes and pro actively push flows 2013/3/6 Rob Sherwood <rob.sherw...@bigswitch.com> > I think you may be confusing the time scales for "proactive" and > "reactive". Most people use them to mean "before or after the first > packet in a flow", but if you want to, for example, upon seeing an ARP > from host X, proactively install flow rules that match all possible > traffic to host X, then this is a fairly viable strategy. > Additionally, if your hosts are VMs and you're using an orchestration > system, you don't even necessarily have to wait for an ARP as the > orchestration system will tell you where the hosts are located, so in > this case, you're "reacting" to host moves in the orchestration > system. > > Hope this helps, > > - Rob > . > > On Wed, Mar 6, 2013 at 6:44 AM, Arnaud M <arnau...@gmail.com> wrote: > > Helle everyone, > > > > I was wondering which features could offers an openflow device managed > only > > with proactive flow.. It seems to be very limited if the device is not > > hybrid, am I right ? > > > > For example we can forget layer 2 switching without reactive flow (or > make > > it static..) > > > > Maybe the "only proactive flow management" could be useful in hybrid > device > > because if no flow is ok, we can go to normal process (that would assume > > switching and other stuff..) > > > > Any idea ? > > > > _______________________________________________ > > openflow-discuss mailing list > > openflow-discuss@lists.stanford.edu > > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > > >
_______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
