One of my readers sent me this observation while reviewing my BGP-Based SDN Solutions webinar:

I am a bit surprised the SDN controller can actually be so lightweight.

Well, that's the benefit of augmenting an existing well-developed ecosystem instead of reinventing the wheel and reimplementing every single bit of functionality we had to develop to make networks work throughout the last 5 decades.

She continued:

It looks like an SDN controller is just a BGP Route Reflector running IBGP with all the nodes.

Whether you use a route reflector or not depends on the functionality you're trying to achieve and the risks you're willing to take.

If you use an SDN controller as a BGP RR then any failure in the SDN controller could bring down the whole network – not necessarily a good idea.

The SDN controller in Juniper Contrail is indeed acting like a BGP route reflector, although, admittedly, their SDN controller uses XMPP instead of BGP to exchange information with the hypervisors. Regardless of the protocol used, all topology information exchange goes through the controller which even modifies BGP next hops and MPLS labels to implement interesting functionality like service insertion.

Other implementations are more risk-averse. Their SDN controllers are BGP speakers that participate in the BGP routing but are not in the control-plane path between the edges of a BGP autonomous system. For example, the Border6 solution uses a BGP speaker that interacts with the existing network and uses more-specific prefixes to steer the traffic away from the path it would take based on BGP prefixes received from remote autonomous systems.

The solutions that use BGP FlowSpec to insert PBR rules or packet filters into network elements could use either approach: they could establish a BGP session with every network element in case they need to insert a different set of rules into every element (and attach no-advertise community to the BGP Flowspec rules), or they could use just a single BGP session (usually with a route reflector) and rely on the regular BGP information dissemination to distribute the FlowSpec rules across the whole network.

Finally, numerous network monitoring and traffic analysis solutions establish read-only BGP peering with either a route reflector (if they're interested in a single view of the network) or even every BGP router in the network (if they want to see different perspectives of the same network). Examples: traffic analysis tool used by Netflix or BGP-LS-based information gathering used by Juniper NorthStar controller.

More information

BGP-Based SDN Solutions webinar describes numerous BGP-based SDN solutions and open-source tools you could use to build another one.

PCEP and BGP-LS Deep Dive webinar covers the network topology extraction with BGP-LS. If you like the idea of using BGP-LS but don’t want to buy a commercial PCEP controller, read the blog post in which Diptanshu Singh describes how to use OpenDaylight to get topology information from IOS XR.

We also covered real-life BGP-based solutions in Software Gone Wild podcasts.