We assume that we're going to want to know paths from many sources to many
destinations, that establishing paths is far more common than topology changes,
and that we want to minimize the path setup time. With these assumptions, it
seems like a reasonable thing to do is to precompute all paths
Mr Murphy, is there any explanation why l2_multi use Floyd-Warshall
algorithm, instead of Dijkstra or any other shortest path algorithm?
thanks
On Thu, Dec 19, 2013 at 2:09 AM, Murphy McCauley
wrote:
> The barrier sort of serves as a confirmation message. When you send a
> switch a flow-mod, y
The barrier sort of serves as a confirmation message. When you send a switch a
flow-mod, you ordinarily have no way of knowing when or if it has taken effect
since there's no positive acknowledgement. We don't even know if it's valid.
The switch might send an error, but we have no idea *when*
Hello,
Very helpful explanation,
I would like to ask you about the barrier command and its replay. What is the
benefit from using it in l2_multi. Also, what is the benefit from clearing
flow-table contents, while receiving a LinkEvent.
Best regards,
Amer
On ١٦/١٢/٢٠١٣, at ٩:٢٦ ص, Murphy McCa
There isn't. In short, it's like this:
The discovery component raises LinkEvents when links change.
l2_multi keeps an "adjacency" map. The value of adjacency[sw1][sw2] is the
port which connects sw1 to sw2. This is updated by the l2_multi class, which
watches LinkEvents. LinkEvents also cau
Hello,
I would like to ask you if there is a document that help me to understand
l2_multi code.
Best regards,
Amer
