Worth Reading: Who Moved My Control Plane?

Jordan Martin published a nice summary of what I’ve been preaching for years: centralized control plane doesn’t work (well) while controller-based network orchestration makes perfect sense.

While I totally agree with what he wrote he got the hype angle wrong:

One of the more popular misconceptions about SDN is that this new model of networking moves the control plane from a device to a controller.

Unfortunately that’s exactly the definition of SDN we’ve been hearing from the likes of ONF for years. As of today (April 26th 2017) ONF still has that same stupidity on the very top of their SDN definition page, so it’s not a popular misconception but parroting of an overhyped and over-marketed academic concept that should never have escaped into the wild.

Recent posts in the same categories

9 comments:

  1. tron 27 April 2017 12:37
    Hmm, he says:
    If we removed the control plane from the device, the controller would be responsible for directly programming FIBs, managing TCAM, etc…
    I'm not convinced that "control plane" needs to "directly program". If that's needed, then obviously it can not be centralized.

    But would you argue that OSPF is control plane ? Or that it is OSPF who decides the routes ? Then if OSPF runs in a controller, then the control plane (or part of it) is centralized.
    Black ? White ? Most are grey...
    Replies
    1. Unknown 27 April 2017 14:26
      OSPF is definitely control-plane IMO. But every device runs its own instance of OSPF and they are completely autonomous. Yes, they share state data through LSAs but the actual decision is based on the individual OSPF's instance of the world and the forwarding plane programming in the ASIC is done by the local OSPF instance ( oversimplistic, but you get the point). OSPF decides the routes (RIB) but how those routes (RIB) get translated into the selected route (FIB) and actually transferred into the ASIC forwarding tables is the question here.

      That is REALLY hard to centralize, which I think is the point. Not grey at all.
    2. Jordan Martin 27 April 2017 15:10
      Chris nailed the point exactly. OSPF or any other routing protocol is definitely part of the control plane, but runs as many independent instances that share information. SDN implementations should be no different. But rather than utilizing propagation methodologies for the dissemination of topology information, localized control planes receive their topology information from a centralized controller.
    3. tron 28 April 2017 13:39
      IMHO, you are being too assertive.
      In NSX, OSPF runs in one VM and it's "output" its pushed to the hypervisors that participate in DR.
      That VM is not a "controller" but it is neither running in each device. Grey for me.
  2. Bela 27 April 2017 15:58
    Telco networks always used the SDN model. Remember PDH, SDH, ATM PVC, etc. Lot of applications still require this architecture. SDN can do it for IP Networks in a vendor independent way. Vendor dependent solutions has been around for decades. If SDN is vendor dependent then it is just marketing trick for new clothes. If it is open sourced and interoperable, then it makes some sense for some networks.
    And of course the hybrid SDN architecture is the useful one. Some parts of the control plane should stay together with the data plane. Only the some selected functions should be implemented by an SDN controller.

    SDN is not equivalent with OpenFlow. For me a combination of SIP with MEGACO2 is a true SDN.
    Actually, ITU defined it for all kind of networking, not just voice and video. Most people are not aware and do not use it. But it is a nice solution in theory... :-)
  3. Unknown 27 April 2017 17:47
    I think many folks get this part wrong but Openflow can be used as a generic protocol for control plane to talk to a data plane. As a matter of fact many Juniper / CISCO systems have a single control plane (or dual for HA ) with multiple line cards (data plane). The control plane uses proprietary protocol to talk to the line cards. These implementations easily scales for many line cards. Openflow can be used here instead of proprietary protocols giving us a new way of operating devices. But yes this requires huge engineering effort to make sure control planes and data planes are well synchronized. Will anybody benefit if such things are really available someday ? May be we will have lower TCO and flexibility in choosing devices.
    Replies
    1. Unknown 27 April 2017 18:14
      In such a scenario we can have one control plane controlling one device or multiple devices. Of course there has to be an automation (or SDN ) layer on top of such a control plane to manage and simplify things.

  4. Anonymous 03 May 2017 15:37
    So if my "controller" is running an expect script that SSHs into 100 different boxes to add a /32 static route for a specific destination, I'm actually doing "SDN" because my "SDN" controller ( my script ) did the control plane "orchestration" for the 100 devices. If I do the same thing manually, it is not "SDN" ?
    Replies
    1. Unknown 04 May 2017 05:39
      I think with SDN we should be able to have a API level and seamless abstraction layer which is more or less vendor independent way of provisioning things. CLI scripting is error prone & cumbersome which in my definitiin would not qualify as SDN implementation.

      As a sidenote I would also like my SDN to lower OPEX/CAPEX and ease of introducing newer features to my network with min churn
Add comment
Home
Sidebar