xBGP: making BGP truly extensible

BGP is one of the most important Internet routing protocols. In addition to its role to disseminate interdomain routes, BGP is also used inside ISP networks to support various value-added services including Virtual Private Networks. Large cloud provides have also started to use BGP as an intradomain routing protocol in large datacenters.

A BGP implementation is often considered as a blackbox that interacts through different means:

  • it exchanges BGP messages over BGP sessions by sending them on TCP connections
  • it pushes the best
  • it interacts with the intradom routing protocols (e.g. OSPF or IS-IS) to extract the path and the cost to reach the BGP nexthops
  • it exposes various metrics using the BGP MIB
  • it can be configured using a proprietary Command Line Internet or protocols such as NETCONF

Such a BGP implementation is depicted in the figure below.

BGP implementation

BGP was designed more than thirty years ago. Since the first publication of BGP-4, various extensions have been discussed and approved within the IDR IETF Working Group. These extensions have proposed significant changes to the protocol. The figure below depicts the number of MUST/SHOULD RFC2119 found in all the BGP standards-track RFCs produced by the IDR working group during the last two decades.

Evolution of the BGP protocol

Despite the importance of these protocol extensions, BGP implementations have not been designed with extensibility in mind. In The case for pluginized routing protocols, we proposed a different model to organise one BGP implementation, i.e. FRRouting. To enable network operators to develop their own extension to the BGP protocol, we have added to FRRouting a modified eBPF Virtual Machine that allows to execute operator supplied bytecode at various points in the FRRouting code to implement extensions to both OSPF and BGP. The figure below shows our modified architecture.

Pluginized FRRouting

This modified BGP implementation contains an eBPF virtual machine that executes plugins that are supplied by the network operators. This approach allows to extend one particular implementation. In a forthcoming paper, we demonstrate how a similar idea can be made more generic and applied to different implementations so that a network operator can write plugins which can be executed on different implementations. This makes BGP implementations truly programmable.

Recent Posts

2021 ANRP award for xBGP

less than 1 minute read

Every year, the Internet Research Task Force awards the Applied Networking Research Prize (ANRP) to recognise the best recent results in applied networking, ...

A first xBGP plugin

5 minute read

An xBGP compliant implementation such as our forks of BIRD and FRRouting supports a simple API that enables network operators and researchers to extend it. T...

xBGP presented at IETF109

less than 1 minute read

Olivier Bonaventure presented xBGP on November 19th, 2020 to the TCPM working group at IETF109

xBGP presented at Hotnets’20

less than 1 minute read

Thomas Wirtgen presented xBGP on November 4th, 2020 at HotNets 2020: Nineteenth ACM Workshop on Hot Topics in Networks. The full paper is available from the ...

Source code for xBGP prototypes

less than 1 minute read

The source code for our xBGP prototype is available on github. It is divided in several repositories:

An abstract workflow for BGP implementations

2 minute read

The first step to allow BGP implementations to be programmed is to have a clear understanding of how the BGP protocol operates and how it processes and sends...