I would like to put forth a "concise rant" here. The short story is that *no one should use flow-in event* and we should deprecate it.
I have several reasons for saying so. 1) The flow-in semantics is hard to reason about. We generate a flow-in using packet-in. And if a route cannot be found, the flow-in is flooded? The flooding is actually done to a packet and not a flow. 2) You do not have control over the packet in thereafter. Some two components can be handling the packet-in and flow-in, which refers to the same packets actually. 3) Flow-in really does not give you much anyway. If you want the header fields in flow-in, just use flow.hh. It parses those. So, ends my quibble about flow-in. Regards KK On 12 March 2010 13:56, Guanyao Huang <[email protected]> wrote: > I think some document of authenticator module is very necessary. > The newest version of authenticator module seems changed a lot, but > the code for routing module remains the same. > For example, why there are many events defined in host_event.hh, why > there are many entries, bindings defined in authenticator.hh. > Normally, given a mac address, or, IP address, what is the API used to > get its datapath? > Without such things, I feel easily get lost in the code. > I guess many people are developing their own module based on flow_in > event. It would be nice if they know how this flow_in event was > generated. > > On Fri, Mar 12, 2010 at 1:40 PM, Srini Seetharaman > <[email protected]> wrote: >> Just to add to Guanyao's observations: I wanted to mention that the >> host having two bindings is something we run across often in our >> Stanford setup. However, we notice it only when the topology is >> changed during runtime. >> >> Srini. >> > > _______________________________________________ > nox-dev mailing list > [email protected] > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > _______________________________________________ nox-dev mailing list [email protected] http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
