| Internet-Draft | BGP-SPF TE | July 2025 |
| Zhang & Dong | Expires 8 January 2026 | [Page] |
This documents propose to introduce the BGP Link-State (BGP-LS) extensions for Traffic Engineering(TE) to the BGP-LS-SPF SAFI.¶
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 8 January 2026.¶
Copyright (c) 2025 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.¶
[I-D.ietf-lsvr-bgp-spf] extends BGP for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP-LS-SPF leverages the mechanisms of both BGP protocol [RFC4271] and BGP-LS protocol extensions [RFC9552], with the extensions to BGP-LS attribute and new NLRI selection rules.¶
BGP-LS-SPF may be applied to network scenarios beyond data center(Such as WAN). In some network scenarios, traffic engineering is necessary to improve the resource utilization rate and load balancing. This document proposes to introduce the BGP Link-State (BGP-LS) extensions for Traffic Engineering(TE) to the BGP-LS-SPF SAFI, and discusses which TE extensions can be applied to BGP-LS-SPF SAFI.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Section 5.3.2 of [RFC9552] defines the Link Attributes TLV for BGP-LS, which includes the basic TE attributes TLV. Futhermore, [RFC8571] extends the link attribute TLVs for TE, and newly defines 7 TE link attribute TLVs. The TE link attribute TLVs that can be applied to BGP-LS-SPF are shown as follows:¶
| Type | Description | Reference |
|---|---|---|
| 1088 | Administrative group(color) | RFC 9552 |
| 1089 | Maximum link bandwidth | RFC 9552 |
| 1090 | Max.reservable link bandwidth | RFC 9552 |
| 1091 | Unreserved bandwidth | RFC 9552 |
| 1092 | TE Default Metric | RFC 9552 |
| 1093 | Link Protection Type | RFC 9552 |
| 1096 | Shared Risk Link Group | RFC 9552 |
| 1114 | Unidirectional Link Delay | RFC 9552 |
| 1115 | Min/Max Unidirectional Link Delay | RFC 9552 |
| 1116 | Unidirectional Delay Variation | RFC 9552 |
| 1117 | Unidirectional Link Loss | RFC 9552 |
| 1118 | Unidirectional Residual Bandwidth | RFC 9552 |
| 1119 | Unidirectional Available Bandwidth | RFC 9552 |
| 1120 | Unidirectional Utilized Bandwidth | RFC 9552 |
The administrative group sub-TLV contains a 4-octet bit mask assigned by the network administrator. The format of administrative group TLV of BGP-LS-SPF is consistent with that in BGP-LS. The format of it is shown as follow:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=1088 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bit mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
Bit mask: 32-bit length, each set bit corresponds to one administrative group assigned to the interface. The least significant bit is referred to as 'group 0',and the most significant bit is referred to as 'group 31'.¶
The maximum link bandwidth TLV describes the maximum bandwidth that can be used on this link in this direction This is useful for traffic engineering. The format of maximum link bandwidth TLV of BGP-LS-SPF is consistent with that in BGP-LS. The format of it is shown as follow:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=1089 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum link bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
Maximum link bandwidth: 32-bit length, it is encoded in 32 bits in IEEE floating point format. The units are bytes per second.¶
The max.reservable link bandwidth TLV describes the maximum amount of bandwidth that can be reserved in this direction on this link. For oversubscription purposes, this can be greater than the bandwidth of the link. The format of max.reservable link bandwidth TLV of BGP-LS-SPF is consistent with that in BGP-LS. The format of it is shown as follow:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=1090 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum reservable link bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
Maximum reservable link bandwidth: 32-bit length, it is encoded in 32 bits in IEEE floating point format. The units are bytes per second.¶
The unreserved bandwidth TLV describes the amount of bandwidth reservable in this direction on this link. For oversubscription purposes, this can be greater than the bandwidth of the link. The format of unreserved bandwidth TLV of BGP-LS-SPF is consistent with that in BGP-LS. The format of it is shown as follow:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=1091 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved bandwidth(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved bandwidth(1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved bandwidth(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved bandwidth(3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved bandwidth(4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved bandwidth(5) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved bandwidth(6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved bandwidth(7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
Unreserved bandwidth(0-8): 32-bit length for each, each is encoded in 32 bits in IEEE floating point format. The units are bytes per second. The values correspond to the bandwidth that can be reserved with a setup priority of 0 through 7, arranged in increasing order with priority 0 occurring at thestart of the TLV, and priority 7 at the end of the TLV.¶
For stability reasons, rapid changes in the values in this TLV SHOULD NOT cause rapid generation of BGP update messages.¶
The TE Default Metric TLV describes the Traffic Engineering metric for this link. This metric is administratively assigned and can be used to present a differently weighted topology to traffic engineering SPF calculations. The format of TE Default Metric TLV of BGP-LS-SPF is consistent with that in BGP-LS. The format of it is shown as follow:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=1091 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE default metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
TE default metric: 32-bit length metric value.¶
The link protection type TLV describes the protection capabilities of the link.¶
The format of Link Protection Type TLV of BGP-LS-SPF is consistent with that in BGP-LS. The format of it is shown as follow:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=1093 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Protection Cap | +-+-+-+-+-+-+-+-+
where:¶
Protection Cap: 8-bit length, indicates the protection capabilities of the link, for the detailed description, see Section 1.2 of [RFC5307].¶
This TLV describes the average link delay between two directly connected BGP-LS-SPF neighbors. The format of Unidirectional Link Delay TLV of BGP-LS-SPF is consistent with that in BGP-LS. The format of it is shown as follow:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=1114 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Reserved | Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
A bit: This field represents the Anomalous (A) bit. For detail, see Section 4.1 of [RFC8750].¶
Delay: 24-bit field indicates the average link delay over a configurable interval in microseconds, encoded as an integer value.¶
The Min/Max Unidirectional Link Delay TLV indicates the minimum and maximum delay values between two directly connected BGP-LS-SPF neighbors. The semantics and values of the fields in the TLV are the same as that described in [RFC8570] and [RFC7471].¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=1115 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| RESERVED | Min Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED | Max Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Unidirectional Delay Variation describes the average link delay variation between two directly connected BGP-LS-SPF neighbors. The semantics and values of the fields in the TLV are the same as that described in [RFC8570] and [RFC7471].¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=1116 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Delay Variation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV describes the loss (as a packet percentage) between two directly connected BGP-LS-SPF neighbors. The semantics and values of the fields in the TLV are the same as that described in [RFC8570] and [RFC7471].¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1117 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| RESERVED | Link Loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV advertises the residual bandwidth between two directly connected BGP-LS-SPF neighbors. The semantics and values of the fields in the TLV are the same as that described in [RFC8570] and [RFC7471].¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1118 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Residual Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV advertises the available bandwidth between two directly connected BGP-LS-SPF neighbors. The semantics and values of the fields in the TLV are the same as that described in [RFC8570] and [RFC7471].¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1119 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV advertises the bandwidth utilization between two directly connected BGP-LS-SPF neighbors. The semantics and values of the fields in the TLV are the same as that described in [RFC8570] and [RFC7471].¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1120 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Utilized Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document introduces no additional security vulnerabilities in addition to the ones as described in [RFC9552] and [RFC8571].¶
This document has no IANA actions.¶