[OpenFlow] Summary of some current OpenFlow Related Articles

1. http://blog.ioshints.info/2011/11/openflow-enterprise-use-cases.html
This article discusses enterprise use cases in OpenFlow

• There are four functions you can easily implement with OpenFlow (Tony Bourke wrote about them in more details)
• packet filters – flow classifier followed by a drop or normal action
• policy based routing – flow classifier followed by outgoing interface and/or VLAN tag push
• static routes – flow classifiers using only destination IP prefix
• NAT – some OpenFlow switches might support source/destination IP address/port rewrites.

• It suggests that security could be the killer app as the following URL: 
• http://www.rationalsurvivability.com/blog/2011/10/the-killer-app-for-openflow-and-sdn-security/

2. http://routerjockey.com/2011/11/02/nec-and-programmableflow-switching/
This article writer give some information and comments about NEC programmableflow because he joined NEC presenting at Networking Tech Field Day 2


3. http://blog.ioshints.info/2011/11/openflow-deployment-models.html#of_native
This article provides four different models for OpenFlow deployment have already emerged:

• Native OpenFlow
• The controller performs all control-plane functions, including running control-plane protocols with the outside world. 
• This model has at least two serious drawbacks even if we ignore the load placed on the controller by periodic control-plane protocols:
• The switches need IP connectivity to the controller for the OpenFlow control session. 
• Fast control loops like BFD are hard to implement with a central controller, more so if you want to have very fast response time.
• NEC seems to be using this model quite successfully (although they probably have a few extensions), but already encountered inherent limitations: a single controller can control up to ~50 switches, ~600000 end points (VMs or Physical Nodes), and rerouting around failed links takes around 200 msec (depending on the network size). For more details, watch their Networking Tech Field Day presentation.
• Native OpenFlow with extensions
• A switch controlled entirely by the OpenFlow controller could perform some of the low-level control-plane functions independently.
• Using OpenFlow extensions or functionality implemented locally on the switch, you destroy the mirage of the “OpenFlow networking nirvana”-- smart open-source programmable controllers control dumb low-cost switches, busting the “networking = mainframes” model and bringing the Linux-like golden age to every network.
• Ships in the night
• Switches have traditional control plane; OpenFlow controller manages only certain ports or VLANs on trunked links. The local control plane (or linecards) can perform the tedious periodic tasks like running LACP, LLDP and BFD, passing only the link status to the OpenFlow controller.
• Integrated OpenFlow
•  OpenFlow classifiers and forwarding entries are integrated with the traditional control plane. For example, Juniper’s OpenFlow implementation inserts compatible flow entries (those that contain only destination IP address matching) as ephemeral static routes into RIB (Routing Information Base)
•  From my perspective, this approach makes most sense: don’t rip-and-replace the existing network with a totally new control plane, but augment the existing well-known mechanisms with functionality that’s currently hard (or impossible) to implement.