The Many Paths to SDN

I did a major overhaul of my RIPE 65 SDN presentation prior to MENOG 12 meeting, including a more comprehensive overview of SDN-related technologies sorted by the networking device plane they operate on.

Many paths to SDN

Many paths to SDN

NETCONF, OF-Config (a YANG data model used to configure OpenFlow devices through NETCONF) and XMPP (chat protocol creatively used by Arista EOS) operate at the management plane – they can change network device configuration or monitor its state.

IRS and PCEP (a protocol used to create MPLS-TE tunnels from a central controller) operate on the control plane (parallel to traditional routing protocols), as do numerous BGP-based tools, from well-known Remote Triggered Black Holes to Flowspec (PBR through BGP used by creative network operators like CloudFlare) and BGP-LS (export of link state topology and MPLS-TE data through BGP).

OpenFlow, MPLS-TP and ForCES work on the data plane – they can modify the forwarding behavior of a controlled device or intercept/inject packets.

Have I missed a relevant protocol/technology? Please write a comment!


  1. Good read Ivan, I have been wondering whether OF-Config get lumped into OF-Switch at some point. Fact that no one really talks about it makes me think vendors have a reason for ignoring it. OVSDB is a slick management plane proto worthy of the list.

    Really liked that IXP slide deck. I think thats a solid use case. Listened to Feamster talk about one in ATL that they are looking for participants in an IETF86 recording.

    I had never even heard of that CloudFlare setup, that pretty neat/brave, bravo. Just checked YouTube and still no sign of your presentation video, bah.


  2. Looks interesting... will the video be published ?
    1. This is the reply I got when asking about the availability of conference videos: "Sorry but this this time we provided streaming only without recording, next we will add recording feature into streaming enshalah."
    2. oh, what a pity :(
      Thank you for trying anyway !
  3. Hi Ivan,

    Your blog was pointed to me by a friend.
    First - thanks for at least mentioning ForCES.
    If you were to talk to the ONF folks - we dont exist.

    You did miss some things about ForCES.
    ForCES is/can be used for south/north and config AND
    despite the myth of it being an artifact of history,
    it is deployed.
    Here's a little intro:

    jamal (ForCES co-chair)
  4. hi Ivan,
    You could now add eAPI from Arista which is a JSON-RPC representation of the CLI as another method that doesn't require you to have a PhD in understanding the schema used by something.

    e.g. from python these 5 lines would tell you the interface status of every interface:
    ..from jsonrpclib import Server
    ..switch = Server( "https://username:passw0rd@myswitch/eapi/v1" )
    ..interfaces = switch.runCli( cmds=[ “show interfaces” ] )
    ..for name, interface in interfaces.items():
    ....print “Interface”, name, “is”, interface[ “lineProtocol” ]
    1. Hi Lincoln!

      I'm well aware of eAPI and I love its simplicity (I was talking about it on the update webinar two days ago), but I explicitly decided not to mention vendor-specific mechanisms (no need to tell me how no two NETCONFs are alike :D )

      Thanks for the feedback!
  5. Besides routers, SDN can and is also applied to (virtual) switches. Your picture could be enhanced to show L2 related state. Moreover, some SDN solutions provide virtual overlays, creating many independent instances of control and data plane state
Add comment