]> Huawei Technologies

No. 156 Beiqing Road Beijing China zhangli344@huawei.com

Huawei Technologies

No. 156 Beiqing Road Beijing China jie.dong@huawei.com

Routing LSVR working group Internet-Draft This documents propose to introduce the BGP Link-State (BGP-LS) extensions for Traffic Engineering (TE) to the BGP-LS-SPF SAFI.

Introduction 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 and BGP-LS protocol extensions , 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.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Link Attribute TLVs for TE Metric Extensions defines the Link Attributes TLV for BGP-LS, which includes the basic TE attributes TLV. Furthermore, 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: BGP-LS link attribute TLVs for TE metric extensions

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

Administrative group(color) 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:

Format of administrative group TLV

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’.

Maximum Link Bandwidth 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:

Format of maximum link bandwidth TLV

where: Maximum link bandwidth: 32-bit length, it is encoded in 32 bits in IEEE floating point format. The units are bytes per second.

Max.reservable link bandwidth 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:

Format of Max.reservable link bandwidth TLV

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.

Unreserved bandwidth 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:

Format of unreserved bandwidth TLV

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 the start 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.

TE Default Metric 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:

Format of TE Default Metric TLV

where: TE default metric: 32-bit length metric value.

Link Protection Type 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:

Format of Link Protection Type TLV

where: Protection Cap: 8-bit length, indicates the protection capabilities of the link, for the detailed description, see .

Shared Risk Link Group The Shared Risk Link Group (SRLG) TLV carries the Shared Risk Link Group information. The format of Shared Risk Link Group TLV of BGP-LS-SPF is consistent with that in BGP-LS. The format of it is shown as follow:

Format of Shared Risk Link Group TLV

where: Shared Risk Link Group Value: variable, consisting of a (variable) list of SRLG values, where each element in the list has 4 octets length.

Unidirectional Link Delay 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:

Format of Unidirectional Link Delay TLV

where: A bit: This field represents the Anomalous (A) bit. For detail, see . Delay: 24-bit field indicates the average link delay over a configurable interval in microseconds, encoded as an integer value.

Min/Max Unidirectional Link Delay 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 and .

Format of Min/Max Unidirectional Link Delay TLV

Unidirectional Delay Variation 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 and .

Format of Unidirectional Delay Variation TLV

Unidirectional Link Loss 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 and .

Format of Unidirectional Link Loss TLV

Unidirectional Residual Bandwidth 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 and .

Format of Unidirectional Residual Bandwidth TLV

Unidirectional Available 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 and .

Format of Unidirectional Residual Bandwidth TLV

Unidirectional Utilized 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 and .

Format of Unidirectional Utilized Bandwidth TLV

Security Considerations This document introduces no additional security vulnerabilities in addition to the ones as described in and .

IANA Considerations This document has no IANA actions.

Acknowledgements

References Normative References Arrcus, Inc. LabN Consulting, LLC LinkedIn Nokia Many Massively Scaled Data Centers (MSDCs) have converged on simplified L3 (Layer 3) routing. Furthermore, requirements for operational simplicity has led many of these MSDCs to converge on BGP as their single routing protocol for both their fabric routing and their Data Center Interconnect (DCI) routing. This document describes extensions to BGP to use BGP Link-State distribution and the Shortest Path First (SPF) algorithm. In doing this, it allows BGP to be efficiently used as both the underlay protocol and the overlay protocol in MSDCs. This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in the IS-IS and OSPF protocols. This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK] Encapsulating Security Payload (ESP) sends an initialization vector (IV) in each packet. The size of the IV depends on the applied transform and is usually 8 or 16 octets for the transforms defined at the time this document was written. When used with IPsec, some algorithms, such as AES-GCM, AES-CCM, and ChaCha20-Poly1305, take the IV to generate a nonce that is used as an input parameter for encrypting and decrypting. This IV must be unique but can be predictable. As a result, the value provided in the ESP Sequence Number (SN) can be used instead to generate the nonce. This avoids sending the IV itself and saves 8 octets per packet in the case of AES-GCM, AES-CCM, and ChaCha20-Poly1305. This document describes how to do this. In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance. Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. This document obsoletes RFC 7810. In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection. This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document.