| Internet-Draft | BGP TED | March 2026 |
| Kompella & Zhang | Expires 3 September 2026 | [Page] |
In some networking situations, most commonly in Data Centers, no IGP protocol is run. The preferred option is to run BGP to exchange reachability information. If it is also desirable to run Traffic Engineering, a Traffic Engineering Database is needed; this information is typically exchanged via IGP TE extensions. This memo proposes elements of BGP procedure to carry this information when there is no IGP.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 September 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [I-D.kompella-rtgwg-mlnwsched]), 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 [RFC9085]); 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 [RFC5440].¶
This memo describes how BGP-LS can be used without a backing IGP.¶
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 [RFC4760]. 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 ([I-D.zzhang-idr-mpte-signaling]), which can benefit even more by the use of RRs.¶
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.¶
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.¶
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.¶
To be added.¶
To be added.¶