Using BGP to Maintain and Update a Traffic Engineering Database

Introduction BGP is the protocol of choice to carry reachability information in some networks (such as Data Centers (DCs)). In such cases, no IGP is run (it would be nice to write down the rationale for this decision, which seems quite pervasive). If, however, Traffic Engineering (TE) is deemed useful in these same networks (consider ), simple reachability information is insufficient. What is needed is topology information, including node and link attributes, with which to compute TE paths or Directed Acyclic Graphs (DAGs). This information comprises the Traffic Engineering Database (TED). Fortunately, there is a way to carry the TED via BGP, namely, BGP Link State (BGP-LS ); however, this typically requires an IGP from which BGP-LS sources its information. BGP-LS is primarily used to propagate the TED to "listeners" such as PCE engines . This memo describes how BGP-LS can be used without a backing IGP.

Mode of Operation In DCs, BGP is typically as "external BGP", i.e., each device has a unique ASN, and has an eBGP session with each of its neighbors. This session has the aforementioned reachability information whereby each device can communicate with every other device. This same session can be used to carry BGP-LS using the magic of Multiprotocol BGP . Every device in the network would thus obtain the node and link attributes of all devices, and thus can build up the TED. However, there is some chance that the information carried in MP-BGP can cause one or more sessions to go down. As the sessions also carry reachability information, this could cause one or more devices to lose connectivity with others. This in turn could lead to packets being dropped (or looped) and DC workloads being delayed or aborted. To avoid overloading the eBGP reachability sessions with TED information, one can have a parallel eBGP session for the TED. More efficiently, one can have an iBGP session between each device and a small number of Route Reflectors (RRs) (for redundancy). This avoids doubling the number of BGP sessions and alleviates the burden of propagating TED information from all the devices -- this task is limited to the RRs. Such iBGP sessions can also be used for signaling TE DAGs (), which can benefit even more by the use of RRs.

Theory of Operation

Generating Topology/TE Information Each device that wants to contribute to the TED must be configured to advertise its own node and link attributes. Typically, such configuration is sent via an IGP, but in this case, this information is sent via BGP over each of its sessions. The BGP-LS AFI/SAFI is used to carry the device's TE information.

Propagating the TED In the case eBGP sessions are used, in addition to generating its own TE information, each device is responsible for propagating the TE information it receives from its neighbors. If iBGP session with a set of RRs is the mode of operation, then this is not necessary.

Using the TED Note that "regular" SPF is not the objective here. Rather, some set of devices are configured with TE constraints that define the requirements of the TE tunnels. Having received all the BGP-LS updates, these nodes will (eventually) have the full TED, and can proceed to compute TE DAGs that meet the requirements.