]> Huawei

Beiqing Road Beijing shengcheng@huawei.com

Huawei

Beiqing Road Beijing China shihang9@huawei.com

Huawei

China jie.dong@huawei.com

routing LSVR SDWAN This document introduces the usage of BGP-LS-SPF protocol in multi-segment SD-WAN scenarios. It allows SD-WAN tunnels to be published as logical links, which can cross the internet, MPLS networks, and various operator network. The BGP-LS-SPF protocol can construct an overlay network topology for logical links and physical links across these heterogeneous networks, and calculate the reachability routes of overlay network nodes based on this topology. Discussion Venues Discussion of this document takes place on the Link State Vector Routing Working Group mailing list (lsvr@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction As pointed out in , enterprises are migrating their workloads to cloud service. The enterprise branch interconnection and enterprise site to cloud DC connection may cross heterogeneous network such as operator networks, enterprise-owned backbone networks or direct connection lines. For large enterprises to access the cloud service and interconnect their branches, a PoP GWs network can be built to provide multi-cloud, multi-tenant, and multi-branch interconnection. Depending on the geographical distribution of the enterprise branches, the PoP GWs network may be a cross-regional or even a global network. The PoP GW can be connected to the operator network or the enterprise-owned backbone network. The PoP GWs devices can also be directly connected through dedicated lines. According to , SD-WAN tunnels can be established between two GWs devices connected to the operator network, MPLS VPN network, or internet network through the WAN ports of the two PoP GWs devices. All GWs are under the control of one BGP instance. defines the mechanism for SD-WAN edges to discover each other's properties via BGP update through RR. This allows the interconnection between enterprise branches and multi-cloud to pass through multiple SD-WAN tunnels or direct connection lines, as shown in . This draft provides a way to use the BGP-LS-SPF protocol to collect the identification of PoP GW device node and the topology of SD-WAN tunnel and direct connection lines. In this way, each PoP GW device can learn the PoP GWs network topology, and calculate the route to any other PoP GW.

Terminology This specification reuses terms defined in including BGP-LS-SPF Node NLRI, BGP-LS-SPF Link NLRI, Dijkstra Algorithm.

• PoP GW: Point of Presence Gateway
• SD-WAN: Software Defined Wide Area Network. In this document, "SD-WAN" refers to policy-driven transporting IP packets over multiple different underlay networks to get better WAN bandwidth management, visibility and control.
• RR: Route Reflector
• Cloud DC: Off-Premise Data Centers that usually host applications and workload owned by different organizations or tenants.

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.

Usage of BGP-LS-SPF in Multi-segment SD-WAN

PoP GWs network

As shown in , GW1, GW2, GW5 are connected to the same internet/ISP network. The GW2 and GW3 are connected through direct dedicated links. GW5 and GW4 are connected by MPLS VPN. BGP-SD-WAN neighbors are established between GWs through RR. BGP-LS-SPF neighbors are established between each GW and RR. SD-WAN tunnel links are established between GWs through BGP-SD-WAN neighbors reflecting SD-WAN routes(see ), as shown in the SD-WAN Tunnel between GW1 and GW2 with WAN port IP addresses of 10.1.1.1 and 20.1.1.1, respectively. GW nodes reflect the SD-WAN tunnel topology information to all GWs, including dedicated line-connected GWs, through BGP-LS-SPF neighbors with RR. GW2-GW3-GW4 are connected through dedicated lines. BGP-LS-SPF neighbors are established between GWs through dedicated lines, and also between GWs and RR. The BGP-LS-SPF neighbors between dedicated lines are used to discover the topology information of the dedicated lines, such as the direct link with port IP addresses of 30.1.1.1 and 40.1.1.1 between GW3 and GW4 shown in the figure. The dedicated line topology information is reflected to all GWs, including SD-WAN tunnel-connected GWs, through BGP-LS-SPF neighbors with RR. BGP-LS-SPF can be used in two scenarios in Multi-segment SD-WAN: 1. TE. When TE is used, SLA of all SD-WAN tunnels will be collected to calculate shortest path. The protocol ID of BGP-LS is BGP. The BGP-LS-SPF LINK NLRI is used to carry the two endpoint IP address of the SD-WAN tunnel or dedicated lines. The BGP-LS-SPF NODE NLRI is used to carry PoP GW device node identification. 2. BE. When BE is used, only reachability of a SD-WAN site is collected. An SD-WAN site may contains multiple GWs. There is no need to collect the SLA of every SD-WAN tunnels between two sites. In this case, a new BGP-LS Protocol-ID is used and new Node Descriptor sub-tlv is defined to carry the site ID. In both scenarios, BGP-LS-SPF LINK NLRI and NODE NLRI are advertised to other GWs through the RR. In this way, all GW learns the topology of whole PoP GWs network and can calculate the next hop to any other GW using Dijkstra Algorithm.

Extensions to BGP-LS

SDWAN Protocol ID This document specifies the advertisement of SDWAN topology information via BGP-LS-SPF Link NLRI type and Node NLRI type, which requires use of a new BGP-LS Protocol-ID (value 10). The use of a new Protocol-ID allows separation and differentiation between the BGP-LS NLRIs carrying SDWAN topology information from the BGP-LS NLRIs carrying other link-state information defined in .

Node Descriptor Sub-tlv This document introduces a new Node Descriptor Sub-TLV to carry the SDWAN Site ID to identify an SDWAN site. A site may contains multiple GWs. This field has the same meaning of SD-WAN-Color in , representing a group of tunnels terminated at SD-WAN GWs co-located at the site.

Node Descriptor Sub-TLV Format

Link-Type TLV The link could be Overlay link (Such as Internet, MPLS, LTE etc.,) and Underlay/Physical link (Such as Dedicated line, Direct link etc.,). Different customer may require different types of link. For example, FinTech customer has very high security requirement and would like to exclude Internet and LTE, only use MPLS or Dedicated line; some customer only wants to use the Dedicated line/Direct link to get the highest quality path; some customer prefers to use LTE only as backup link to save the cost. The calculation of these customized SD-WAN path needs to include or exclude one or more specific link types, therefore, when SD-WAN link information is advertised through BGP-LS-SPF Link NLRI, the SD-WAN link type needs to be explicitly indicated. In this document, a new BGP-LS-SPF Attribute TLV of the BGP-LS-SPF Link NLRI is added to identify a SD-WAN link type, called Link-Type TLV. The format of the Link-Type TLV is defined as follows:

Link-Type TLV Format

where: Type: TBA Length: Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets. The value MUST be 1. Link-Type:

• 0: Reserved
• 1: Physical/Dedicated Line/Direct link
• 2: Internet
• 3: MPLS
• 4: LTE

This BGP-LS-SPF Attribute TLV of the BGP-LS-SPF Link NLRI is defined to indicate the Link-Type of the SD-WAN link.

Security Considerations This document does not introduce any new security considerations.

IANA Considerations

BGP-LS Protocol-IDs IANA maintains a registry called "BGP-LS Protocol-IDs" in the "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry group. This document requests IANA to allocate the following Protocol-ID codepoint:

Protocol ID	NLRI information source protocol	Reference
10	SDWAN	this document

BGP-LS TLVs IANA maintains a registry called "BGP-LS NLRI and Attribute TLVs" in the "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry group. This document requests IANA to allocate the following TLV codepoint:

TLV Code Point	Description	Reference
TBD	SDWAN Node Descriptors	this document
TBD	Link-Type	this document

References Normative References Futurewei Cisco Independet Bell Canada This document explores the complexities involved in managing large scale Software Defined WAN (SD-WAN) overlay networks, along with various SD-WAN scenarios. Its objective is to illustrate how the BGP-based control plane can effectively manage large-scale SD-WAN overlay networks with minimal manual intervention. Futurewei Huawei Oracle Arrcus Arista The document describes the BGP mechanisms for SD-WAN edge node property discovery. These mechanisms include a new tunnel type and subTLVs for the BGP Tunnel-Encapsulation Attribute (RFC9012) and set of NLRI (network layer reachability information) for Software-Defined Wide-Area Network (SD-WAN) underlay information. In the context of this document, BGP Route Reflector (RR) is the component of the SD-WAN Controller that receives the BGP UPDATE from SD-WAN edges and in turns propagates the information to the intended peers that are authorized to communicate via the SD-WAN overlay network. 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. 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. Informative References Futurewei Malis Consulting Orange Verizon Microsoft This document describes a set of network-related problems enterprises face at the time of writing this document (2025) when interconnecting their branch offices with dynamic workloads in third-party data centers (DCs) (a.k.a. Cloud DCs). These problems are mainly from enterprises with conventional VPN services that want to leverage those networks (instead of altogether abandoning them). This document also describes various mitigation practices and actions to soften the issues induced by these problems. 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.

Acknowledgements The authors would like to thank Donglei Pang for his contribution to the document.

Contributors Shunwan Zhuang Huawei Email: zhuangshunwan@huawei.com