The idea is to implement the intelligence in networking devices that are not forwarding. Have the switch handle forwarding while some remote device programs its tables via openflow. It's a logical extension to what IEEE and MEF have been working towards with the TE protocols(PBB-TE, MPLS-TE).
The general idea being that a centralized computer handles logical path creation through the network while the hardware just forwards packets. It obviates the need for static configuration of logical overlay paths by using whatever intelligence is programmed into the openflow controller. It also means you can do really neat stuff like distributed loadbalancing.
My question is how well does it handle convergence? Is this openflow controller just going to fall over at the first link that decides to flap 100 times a second?
If this is a problem or not depends on what you mean.
If a port for some strange reason goes up and down 100 times a sec then this will cause 100 "port status" messages to be sent to the controller. This might be a problem, but the controller should be able to handle this, it's still a small amount of traffic and should not require that much processing. There is also some distributed controllers, for example Onix. If you talk about convergence of the network topology i general then it depend largely on the controllers implementation.
What happens if the connection between the controller and packet forwarder is lost? Would the switch revert back to inserting its own hardware entries without the help from the controller software?
I have no experience with Openflow. I have some experience with PBB-TE and MPLS provisioning systems and this is always my first question. What happens when these controllers are down from the perspective of the switch? Distributing the controller is better but even that might become unreachable.
The concept is great and I hope this gains more traction. But I'm going to remain doubtful until I see more demos with people pulling links and more real world implementations.
Disclaimer: My day job is as a Test Engineer for a switch manufacturer. So I just see flaws in things.
Comments
The idea is to implement the intelligence in networking devices that are not forwarding. Have the switch handle forwarding while some remote device programs its tables via openflow. It's a logical extension to what IEEE and MEF have been working towards with the TE protocols(PBB-TE, MPLS-TE).
The general idea being that a centralized computer handles logical path creation through the network while the hardware just forwards packets. It obviates the need for static configuration of logical overlay paths by using whatever intelligence is programmed into the openflow controller. It also means you can do really neat stuff like distributed loadbalancing.
My question is how well does it handle convergence? Is this openflow controller just going to fall over at the first link that decides to flap 100 times a second?
If this is a problem or not depends on what you mean. If a port for some strange reason goes up and down 100 times a sec then this will cause 100 "port status" messages to be sent to the controller. This might be a problem, but the controller should be able to handle this, it's still a small amount of traffic and should not require that much processing. There is also some distributed controllers, for example Onix. If you talk about convergence of the network topology i general then it depend largely on the controllers implementation.
What happens if the connection between the controller and packet forwarder is lost? Would the switch revert back to inserting its own hardware entries without the help from the controller software?
I have no experience with Openflow. I have some experience with PBB-TE and MPLS provisioning systems and this is always my first question. What happens when these controllers are down from the perspective of the switch? Distributing the controller is better but even that might become unreachable.
The concept is great and I hope this gains more traction. But I'm going to remain doubtful until I see more demos with people pulling links and more real world implementations.
Disclaimer: My day job is as a Test Engineer for a switch manufacturer. So I just see flaws in things.