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
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
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
Hello,
I would like to ask you if there is a document that help me to understand
l2_multi code.
Best regards,
Amer
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
