Border Gateway Protocol (BGP) began life where and when you would least expect it: Yakov Rekhter and Kurt Lougheed with help from Len Bosak designed and drew the BGP state diagram in January 1989 at IETF 12 over lunch. The first RFC was formalized in June of the same year.

For those of you who are not familiar with BGP, keep in mind that BGP is a network protocol which distributes network information over TCP using NLRI (Network Layer Reachability Information).

From the 2012s onwards, BGP has evolved significantly and became the most powerful network protocol and the one that made the next generation Software Defined Networks (SDN) move from a networkers dream to a reality. You have doubts? Wasn't the whole software revolution meant to abolish the reign of the network protocols?

In this short -and hopefully informative- read we will explore four key capabilities putting BGP at the center of the SDN revolution.

BGP as a per flow routing enabler

SDN’s promises include centralized network programming capabilities which allow modern networks to forward, filter and/or classify flows based on encoded policies. Thanks, to a new BGP NLRI defined in RFC 5575, encoded policies that match flows based on multiple criteria such as source and/or destination IP address, source and/or destination port, TCP flags or even DSCP values, can be pushed by an SDN controller using BGP.

An example of this would be a distributed denial-of-service (DDoS) attack mitigation technique. In fact, a DDoS detection application can be used with the new BGP NLRI called “BGP Flowspec” to automatically divert malicious flows to the scrubbing server over an SDN controller.

Simply put, BGP lends its horsepower to the centralized control paradigm of SDN, taking instructions from the controller and implementing them right into the routing. How powerful is that!

BGP as a WAN optimization lever

Somehow, the hype around SDN concentrated around its datacenter applications. However, its true benefits may lie in the WAN.

In fact, given the continuous traffic increase and revenue drops, one of the biggest service providers’ challenges is WAN optimization and orchestration. It requires service providers to be aware of granular details of their customers traffic profiles to make the right “Traffic Engineering” decisions. Therefore, “Traffic Engineering Database” and complete visibility to customers IGP domains are required.

To achieve this, the IETF defined the Path Computation Engine (PCE) standard in RFC 5440 for WAN paths computation and “Traffic Engineering” purposes. This new approach was implemented by the most of SD-WAN products in market among which I would like to mention the “NorthStar” Juniper SD-WAN controller.

Many studies have been conducted in recent years on network protocols that can be used to aggregate network topology information essential to the PCE computation. And guess what was the recommended industry standard? Good old BGP! The recommended industry standard is the newest BGP NLRI extension called BGP-LS or BGP-LinkState.

BGP as a management and visibility tool

Engineers and network operators wish to have access to the full routing information base of BGP nodes to monitor BGP peering session states, updates and routes. Traditionally this could only be realized through screen-scraping of known show commands outputs. Not exactly what you would call practical.

Again, BGP is lending a hand. BMP is a new BGP extension that allows a BGP-enabled device to send BGP session information to a monitoring station (BMP collector). Network administrators and engineers can already interact via OpenDayLight (ODL) and Network Control System (NCS) northbound interfaces to run various BMP diagnostics and analytics. Looking glass is also changing the way it works.

But what if BGP fails?

However, assuming a BGP session failure occurs, the BGP speaker will drop all the forwarding information learned over that session and all the magic will stop. This might be the worst-case scenario when using BGP as an SDN controller protocol. Existing SDN networks challenges include routing state persistence when network devices and SDN controller connections failures occur.

However, you can, again, rely on BGP to work its way around this one final hurdle. The IETF defined the BGP persistence feature to let a BGP-enabled device to be able to retain routing state learned over a session that has already terminated.

With SDN, the network engineer's job will evolve -and that's a good thing-, job roles and responsibilities will expand and change. However, we can still rely on the masterpiece of human thinking that is BGP, until the next gem comes around.

Zied TURKI & Nidhal TALEB