Network Working Group L. Dunbar Internet Draft Futurewei Intended status: Informational A. Sajassi Expires: June 9, 2025 Cisco J. Drake Independet B. Najem Bell Canada S. Hares December 9, 2024 BGP Usage for SD-WAN Overlay Networks draft-ietf-bess-bgp-sdwan-usage-24 Abstract 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. Status of this Memo 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." Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. xxx, et al. [Page 1] Internet-Draft BGP Usage for SD-WAN December 9, 2024 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................4 3. SD-WAN Scenarios and Their Requirements........................6 3.1. Requirements..............................................6 3.1.1. Supporting SD-WAN Segmentation.......................6 3.1.2. Client Service Requirement...........................6 3.1.3. SD-WAN Traffic Segmentation..........................7 3.1.4. Zero Touch Provisioning..............................8 3.1.5. Constrained Propagation of SD-WAN Edge Properties....9 3.2. Scenario #1: Homogeneous Encrypted SD-WAN................10 3.3. Scenario #2: Differential Encrypted SD-WAN...............11 3.4. Scenario #3: Private VPN PE based SD-WAN.................12 4. Provisioning Model............................................13 4.1. Client Service Provisioning Model........................13 4.2. Policy Configuration.....................................14 4.3. IPsec Related Parameters Provisioning....................14 5. BGP Controlled SD-WAN.........................................15 5.1. Why BGP as Control Plane for SD-WAN?.....................15 5.2. BGP Walk Through for Homogeneous Encrypted SD-WAN........16 5.3. BGP Walk Through for Differential Encrypted SD-WAN.......18 5.4. BGP Walk Through for Flow-Based Segmentation.............19 5.5. Benefit of Separate Client Update and Underlay Update....21 6. SD-WAN Forwarding Model.......................................21 6.1. Forwarding Model for Homogeneous Encrypted SD-WAN........21 6.1.1. Network and Service Startup Procedures..............21 6.1.2. Packet Walk-Through.................................22 6.2. Forwarding Model for Hybrid Underlay SD-WAN..............23 6.2.1. Network and Service Startup Procedures..............23 6.2.2. Packet Walk-Through.................................23 6.3. Forwarding Model for PE based SD-WAN.....................24 6.3.1. Network and Service Startup Procedures..............24 6.3.2. Packet Walk-Through.................................24 7. Manageability Considerations..................................25 8. Security Considerations.......................................26 Dunbar, et al. [Page 2] Internet-Draft BGP Usage for SD-WAN December 9, 2024 9. IANA Considerations...........................................27 10. References...................................................27 10.1. Normative References....................................27 10.2. Informative References..................................29 11. Acknowledgments..............................................29 1. Introduction Software Defined Wide Area Network (SD-WAN), as described in [MEF70.1] and [MEF70.2], provides overlay connectivity services that optimize the transport of IP packets across one or more underlay networks by identifying traffic types and applying policies to determine forwarding behavior. Key characteristics of SD-WAN networks include: - Transport Augmentation: an SD-WAN path can utilize different types of underlay networks, including private networks (with or without encryption) and public networks (requiring encryption). - Direct Internet Breakout: Traffic from remote branch offices can directly access the internet, avoiding backhauling to corporate headquarters for centralized policy control. - Policy-Based Traffic Steering: Traffic can be directed over specific overlay paths based on predefined conditions, such as matching one or multiple fields in the IP header, rather than solely relying on destination IP addresses [RFC9522]. For IPv6 [RFC8200], attributes like the Flow Label, source address, specific extension header fields, or a combination of these can be used. Additional details are available in Tables 7 and 8 of [MEF70.1]. - Performance-Based Forwarding: Traffic can be steered based on performance metrics (e.g., packet delay, loss, jitter), selecting the underlay path that meets or exceeds policy requirements. This document outlines SD-WAN use cases and addresses the complexities of managing large-scale SD-WAN overlay networks, as described in [Net2Cloud-Problem]. It demonstrates how a BGP-based control plane can efficiently manage these networks with minimal manual intervention. Dunbar, et al. [Page 3] Internet-Draft BGP Usage for SD-WAN December 9, 2024 It's important to distinguish the BGP instance as the control plane for SD-WAN overlay from the BGP instances governing the underlay networks. The document assumes a secure communication channel between the SD-WAN controller and SD-WAN edges for BGP control plane interactions. The need for an RFC documenting SD-WAN use cases lies in ensuring standardization and interoperability. While BGP and IPsec are well-established technologies, their application to SD-WAN introduces challenges such as scalability, traffic segmentation, and multi-homing. This document consolidates best practices and defines guidelines to enable consistent implementations across diverse networks, optimizing existing protocols for SD-WAN scenarios rather than proposing new ones. 2. Conventions used in this document Cloud DC: Third party data centers that host applications and workloads owned by different organizations or tenants. Controller: Used interchangeably with SD-WAN controller to manage SD-WAN overlay networks in this document. In the specific context of BGP-controlled SD-WAN, the controller functions as an integral component of the BGP Route Reflector. Client prefix: In this document, client prefix means IP prefix attached to a client port of an SD-WAN edge. CPE: Customer Premise Equipment C-PE: For SD-WAN network expanded from an existing VPN, the term C-PE refers to the PE (or CPE) of the existing VPN that has added WAN ports to other networks. Homogeneous Encrypted SD-WAN: An SD-WAN network in which all traffic to/from the SD-WAN edges are carried by IPsec tunnels regardless of underlay networks. I.e., the client traffic is carried by IPsec tunnel even over MPLS private networks. Dunbar, et al. [Page 4] Internet-Draft BGP Usage for SD-WAN December 9, 2024 MP-NLRI: In this document, the term "MP-NLRI" serves as a concise reference for "MP_REACH_NLRI". NSP: Network Service Provider. PE: Provider Edge SD-WAN Edge Node: An edge node, which can be physical or virtual, maps the attached clients' traffic to the wide area network (WAN) overlay tunnels. SD-WAN: An overlay connectivity service that optimizes the transport of IP packets over one or more Underlay connectivity services by recognizing applications and determining forwarding behavior by applying policies to them. [MEF-70.1]. SD-WAN IPsec SA: IPsec Security Association between two WAN ports of the SD-WAN edge nodes or between two SD-WAN edge nodes. SD-WAN over Hybrid Underlay Networks: SD-WAN over Hybrid Underlay Networks typically have edge nodes utilizing bandwidth resources from different types of underlay networks, some being private networks and others being public Internet. WAN Port: A Port or Interface facing a Network Service Provider (NSP), with an address allocated by the NSP. C-PE: SD-WAN Edge node, which can be Customer Premises Equipment (CPE) for customer-managed SD-WAN, or Provider Edge (PE) for provider-managed SD-WAN services. Private VPN: refers to a VPN that is supported wholly by a single network service provider without using any elements of the public Internet and without any traffic passing out of the immediate control of that service provider. ZTP: Zero Touch Provisioning Dunbar, et al. [Page 5] Internet-Draft BGP Usage for SD-WAN December 9, 2024 3. SD-WAN Scenarios and Their Requirements This section outlines the core requirements for SD-WAN overlay networks and introduces various SD-WAN scenarios. These scenarios serve as examples that are further explored in subsequent sections to showcase how BGP control plane is used for SD-WAN. 3.1. Requirements 3.1.1. Supporting SD-WAN Segmentation "SD-WAN Segmentation" refers to policy-driven network partitioning, a common approach in SD-WAN deployment. An SD-WAN segment is essentially a virtual private network (SD-WAN VPN) consisting of a set of edge nodes interconnected by tunnels, such as IPsec tunnels and/or MPLS VPN tunnels. This document assumes that SD-WAN VPN configuration on PE devices will, as with MPLS VPN [RFC4364] [RFC4659], make use of VRFs [RFC4364] [RFC4659]. Notably, a single SD-WAN VPN can be mapped to one or multiple virtual topologies governed by the SD-WAN controller's policies. When BGP is used for SD-WAN, the Client Prefix UPDATE is the same as MPLS VPN. The Route Target in the BGP Extended Community [RFC4360] can differentiate the routes belonging to different SD- WAN VPNs. As SD-WAN is an overlay network arching over multiple types of networks, MPLS L2VPN[RFC4761] [RFC4762]/L3VPN[RFC4364] [RFC4659] or pure L2 underlay can continue using the VPN ID (Virtual Private Network Identifier), VN-ID (Virtual Network Identifier), or VLAN (Virtual LAN) in the data plane to differentiate packets belonging to different SD-WAN VPNs. For packets transported through an IPsec tunnel, additional encapsulation, such as GRE [RFC2784] or VxLAN [RFC7348], is needed to embed the SD-WAN VPN identifier inside the IPsec ESP header. 3.1.2. Client Service Requirement The client service requirements describe the SD-WAN edge's ports, also known as SD-WAN client interfaces, which connect the client network to the SD-WAN service. Dunbar, et al. [Page 6] Internet-Draft BGP Usage for SD-WAN December 9, 2024 The SD-WAN client interface should support IPv4 & IPv6 address prefixes as well as Ethernet in accordance with the [IEEE802.3] standard. In [MEF 70.1], the "SD-WAN client interface" is called SD-WAN UNI (User Network Interface). Section 11 of [MEF 70.1] defines a comprehensive set of attributes for the SD-WAN UNI, detailing the expected behavior and requirements to enable seamless connectivity to the client network. The client service at the SD-WAN edge must support the SD-WAN UNI service attributes outlined in Section 11 of [MEF 70.1]. 3.1.3. SD-WAN Traffic Segmentation SD-WAN Traffic Segmentation allows traffic to be separated based on business priorities, security requirements, and operational needs. This ensures that different user groups or services can operate within distinct topologies or follow tailored policies to meet specific business and security objectives. For example, in a retail environment, traffic from point-of-sales (PoS) systems may require a different topology that is separate from other traffic. The PoS traffic is routed exclusively to the payment processing entity at a central hub site, while other types of traffic can be routed among all branches or remote sites. In the figure below, traffic from the PoS system follows a tree topology (denoted as "----" in the figure below), whereas other traffic can follow a multipoint-to-multipoint topology (denoted as "==="). +--------+ Payment traffic |Payment | +------+----+-+gateway +------+----+-----+ / / | +----+---+ | \ \ / / | | | \ \ +-+--+ +-+--+ +-+--+ | +-+--+ +-+--+ +-+--+ |Site| |Site| |Site| | |Site| |Site| |Site| | 1 | | 2 | | 3 | | |4 | | 5 | | 6 | +--+-+ +--+-+ +--|-+ | +--|-+ +--|-+ +--|-+ | | | | | | | ==+=======+=======+====+======+=======+=======+=== Multi-point connection for non-payment traffic Dunbar, et al. [Page 7] Internet-Draft BGP Usage for SD-WAN December 9, 2024 Another example is an enterprise that wants to isolate traffic by departments, ensuring each department having its own unique topology and policies. For instance, the HR department may need to access specific systems or resources that are not accessible by the engineering department. Similarly, contractors may have limited access to the enterprise resources. 3.1.4. Zero Touch Provisioning SD-WAN Zero-Touch Provisioning (ZTP) is a network automation approach that enables the automatic provisioning and configuration of SD-WAN devices, such as routers and switches, at remote locations without requiring manual intervention. ZTP allows devices to be shipped with factory default settings; upon connection to the network, they automatically retrieve their configurations. ZTP for a remote SD-WAN edge usually includes the following steps: - The SD-WAN edge's customer information and unique device identifier (e.g., serial number, MAC address, or factory- assigned ID) are registered with the SD-WAN Central Controller. - Upon power-up, the SD-WAN edge can establish the transport layer secure connection [BCP195] to its controller, whose URL (or IP address) and credential for connection request can be preconfigured on the edge device by the manufacture, external USB drive or secure Email given to the installer. The external USB method involves providing the installer with a pre- configured USB flash drive containing the necessary configuration files and settings for the SD-WAN device. The secure Email approach entails sending a secure email containing the configuration details for the SD-WAN device. - The SD-WAN Controller authenticates the ZTP request from the remote SD-WAN edge with its configurations. Once the authentication is successful, it can designate a local network controller near the SD-WAN edge to pass down the initial configurations via the secure channel. The local network controller manages and monitors the communication policies for traffic to/from the edge node. Dunbar, et al. [Page 8] Internet-Draft BGP Usage for SD-WAN December 9, 2024 3.1.5. Constrained Propagation of SD-WAN Edge Properties For an SD-WAN Edge to establish an IPsec tunnel to another edge and exchange the attached client prefixes, both edges need to know each other's network properties, such as the IP addresses of the WAN ports, the edges' loopback addresses, the attached client prefixes, the supported encryption methods, etc. In many cases, an SD-WAN edge node is authorized to communicate with only a subset of other edge nodes. To maintain security and privacy, the property of an SD-WAN edge node must not be propagated to unauthorized peers. However, when a remote SD-WAN edge node powers up, it may lack the policies to determine which peers are authorized to communicate. Therefore, SD-WAN deployment needs to have a central point to distribute the properties of an SD-WAN edge node to its authorized peers. BGP is well suited for this purpose. A Route-Reflector (RR) [RFC4456], integrated into the SD-WAN controller, has the policy governing the communication among peers. The RR ensures that BGP UPDATE from an edge only is propagated to the edges within the same SD-WAN VPN. An SD-WAN edge must establish a secure connection to its designated RR upon power-up. The BGP UPDATE messages must be sent over the secure channel to the RR. +---+ Authorized Peers G1 |RR | Authorized Peer G2 +======+====+=+ +======+====+=====+ / / | +---+ | \ \ / / | | \ \ +-+--+ +-+--+ +-+--+ +-+--+ +-+--+ +-+--+ |C-PE| |C-PE| |C-PE| |C-PE| |C-PE| |C-PE| | 1 | | 2 | | 3 | |4 | | 5 | | 6 | +----+ +----+ +----+ +----+ +----+ +----+ Tenant 1 Tenant 2 Figure 1: Authorized Peer Groups managed by RR Dunbar, et al. [Page 9] Internet-Draft BGP Usage for SD-WAN December 9, 2024 Tenant separation is achieved by the SD-WAN VPN identifiers represented in the control plane and data plane, respectively. 3.2. Scenario #1: Homogeneous Encrypted SD-WAN Homogeneous Encrypted SD-WAN refers to an SD-WAN network where edge nodes encrypt all client traffic destined to other edge nodes, regardless of whether the underlay is private or public. Typical use cases for Homogeneous Encryption: - A small branch office connecting to its headquarters via the Internet. All traffic to and from this small branch office must be encrypted, usually achieved by IPsec Tunnels [RFC6071]. - A retail store in a shopping mall may need to securely connect to its services hosted in one or more Cloud DCs via the Internet. A common method involves establishing IPsec SAs with the Cloud DC gateway to securely transport sensitive data to/from the store. The granularity of the IPsec SAs for Homogeneous Encryption can be per site, per subnet, per tenant, or per address. Once the IPsec SA is established for a specific subnet/tenant/site, all traffic to/from the subnet/tenant/site is encrypted. +---+ +--------------|RR |------------+ / Untrusted +-+-+ \ / \ / \ +----+ +---------+ +------+ +----+ | CN3|--| P1-----+ -------------+------ P1 |--| CN3| +----+ | C-PE1 P2-----+ | | C-PE2| +----+ +----+ | P3-----+ Wide +------ P2 | +----+ | CN2|--| | | area +------ P3 |--| CN1| +-+--+ +---------+ | network | +------+ +-+--+ \ | | / \ +---------+ | all packets | +------+ / +--| P1-----+ encrypted +------ P1 |-+ | C-PE3 P2-----+ by | | C-PE4| +----+ | P3-----+ IPsec SAs +------ P2 | +----+ | CN1|--| P4-----+--------------+ | |--| CN2| +----+ +---------+ +------+ +----+ CN: Client Networks, which is same as Tenant Networks used by NVo3 Dunbar, et al. [Page 10] Internet-Draft BGP Usage for SD-WAN December 9, 2024 Figure 2: Homogeneous Encrypted SD-WAN A Homogeneous Encrypted SD-WAN shares certain similarities with traditional IPsec VPN. However, unlike IPsec VPNs, which are typically deployed in a point-to-point fashion among a limited number of nodes, SD-WAN networks can comprise a large number of edge nodes, all centrally managed by a controller responsible for configurations and policies across the network. Existing private VPNs (e.g., MPLS based) can use Homogeneous Encrypted SD-WAN to extend over the public network to remote sites to which the VPN operator does not own or lease infrastructural connectivity. 3.3. Scenario #2: Differential Encrypted SD-WAN Differential Encrypted SD-WAN refers to an SD-WAN network that utilizes hybrid underlays, combining private VPNs and the public Internet. In this model, traffic traversing the private VPN is forwarded natively without encryption, while traffic over the public Internet is encrypted for security. This approach balances performance and security. Since IPsec encryption requires significant processing power and traffic over the public Internet typically lacks the premium SLA (Service Level Agreement) provided by private VPNs-especially over long distances-current practice is to forward traffic over private VPNs without encryption, leveraging the inherent reliability and security of the private network. Meanwhile, encryption is applied only to traffic routed over the public Internet to ensure data confidentiality.. One C-PE might have the Internet-facing WAN ports managed by different NSPs with the WAN ports' addresses assigned by the corresponding NSPs. Clients may define specific policies to govern how traffic flows across the network, such as: 1) Certain flows can only be forwarded over private VPNs. 2) Certain flows can be forwarded over either private VPNs or the public Internet. When forwarded over the public Internet, the packets are encrypted. 3) Some flows, especially Internet-bound browsing ones, can be handed off to the Internet without further encryption. For example, consider a flow traversing multiple segments, A<->B, B<->C, C<->D, has Policy 2) above. This flow can cross different underlays in different segments, such as over Private underlay between A<->B without encryption or over the public Internet between B<->C protected by an IPsec SA. Dunbar, et al. [Page 11] Internet-Draft BGP Usage for SD-WAN December 9, 2024 In the figure below, C-PE1 has two different types of interfaces: A1 to the Internet, and A2 & A3 to a private VPN. The WAN ports' addresses can be allocated by the service providers or dynamically assigned (e.g., by DHCP). +---+ +--------------|RR |----------+ / +-+-+ \ / \ / \ +----+ +---------+ packets encrypted over +------+ +----+ | CN3|--| A1-----+ Untrusted +------ B1 |--| CN1| +----+ | C-PE1 A2-\ | C-PE2| +----+ +----+ | A3--+--+ +---+---B2 | +----+ | CN2|--| | |PE+--------------+PE |---B3 |--| CN3| +----+ +---------+ +--+ trusted +---+ +------+ +----+ | WAN | +----+ +---------+ +--+ packets +---+ +------+ +----+ | CN1|--| C1--|PE| go natively |PE |-- D1 |--| CN1| +----+ | C-PE3 C2--+--+ without encry+---+ | C-PE4| +----+ | | +--------------+ | | | | | | +----+ | | without encrypt over | | +----+ | CN2|--| C3--+---- Untrusted --+------D2 |--| CN2| +----+ +---------+ +------+ +----+ CN: Client Network Figure 3: SD-WAN with Hybrid Underlays Services may not be congruent, i.e., the packets from A-> B may traverse one underlay network, and the packets from B -> A may go over a different underlay. 3.4. Scenario #3: Private VPN PE based SD-WAN Private VPN PE-Based SD-WAN refers to extending an existing VPN (e.g., EVPN [RFC7432] or IPVPN) by adding additional ports that face the public Internet to address increased bandwidth requirements between Provider Edge (PE) devices. This approach allows VPN service providers to augment their networks without immediately committing to building or leasing new infrastructure. Key Characteristics of Private VPN PE-Based SD-WAN: Dunbar, et al. [Page 12] Internet-Draft BGP Usage for SD-WAN December 9, 2024 - For MPLS-based VPN, traffic between PEs uses MPLS encapsulation within IPsec tunnels egressing the Internet WAN ports, such as MPLS-in-IP or GRE-in-IPsec. - The BGP RR remains connected to the PEs via the same trusted network as the original VPN, ensuring consistency in routing policies and security. The main use case for Private VPN PE-Based SD-WAN is Temporary Bandwidth Expansion. +======>|PE2| // +---+ // ^ // || VPN // VPN v |PE1| <====> |RR| <=> |PE3| +-+-+ +--+ +-+-+ | | +--- Public Internet -- + Offload Figure 4: Additional Internet paths added to the VPN For Ethernet-based client traffic, Private VPN PE based SD-WAN should support VLAN-based service interfaces (EVPN Instances), VLAN bundle service interfaces, or VLAN-Aware bundling service interfaces. EVPN service requirement as described in Section 3.1 of [RFC8388] are applicable to the SD-WAN Ethernet-based Client services. For IP-based client interfaces, L3VPN service requirements are applicable. 4. Provisioning Model 4.1. Client Service Provisioning Model Client service provisioning in an SD-WAN network can leverage approaches similar to those used for MPLS VRFs (Virtual Routing and Forwarding) [RFC4364][RFC4659]. A client VPN can establish the communication policy by specifying the BGP Route Targets to be imported and exported. Alternatively, conventional Match and Dunbar, et al. [Page 13] Internet-Draft BGP Usage for SD-WAN December 9, 2024 Action ACLs (Access Control List) can be employed to specify the routes that are allowed or denied for a given client VPN. In scenarios where an SD-WAN edge node is dedicated to a single client with a single virtual network, all prefixes attached to the client port(s) on the edge node can be grouped into a single VRF. The RR can manage the policies for import/export policies for that VRF. 4.2. Policy Configuration Policy configuration is a key characteristic of an SD-WAN service, enabling packets to be forwarded over multiple types of underlays based on predefined rules. Policies determines which underlay paths are allowed to carry specific flows, as outlined in Section 8 of [MEF70.1]. A flow is a collection of packets between the same source and destination pair that are subject to the same forwarding and policy decisions at the ingress SD-WAN edge node and are identified by the settings of one or more fields in the packet headers. For example, client-prefix-x can only be mapped to a MPLS topology, ensuring traffic alignment with business or security requirements. 4.3. IPsec Related Parameters Provisioning IPsec-related parameter provision in an SD-WAN network involves the negotiation and distribution of cryptographic parameters required to establish IPsec tunnels among them. To streamline the configuration process, SD-WAN edge nodes can retrieve those parameters directly from the SD-WAN controller, reducing manual intervention and ensuring consistency. In a BGP-controlled SD-WAN, BGP UPDATE messages can be extended to propagate the IPsec-related attributes for each node. This approach allows peers to exchange and select mutually supported cryptographic parameters directly over a secure channel between edge and its BGP RR, simplifying the IPsec tunnel establishment process and reduces reliance on the traditional IPsec IKEv2 [RFC7296]. Dunbar, et al. [Page 14] Internet-Draft BGP Usage for SD-WAN December 9, 2024 5. BGP Controlled SD-WAN 5.1. Why BGP as Control Plane for SD-WAN? In small SD-WAN networks with a modest number of nodes, traditional approaches such as the hub-and-spoke model, employing Next Hop Resolution Protocol (NHRP)[RFC2332] or a centralized hub managing edge nodes, including the mapping of local and public addresses along with tunnel identifiers, has proven effective. However, for larger SD-WAN networks, with more than 100 nodes and encompassing diverse underlays, the conventional approach becomes increasing complex, error-prone, and difficult to manage. BGP offers a robust alternative as the control plane for large SD- WAN networks, providing several key advantages: - Simplified peer authentication process: With a secure management channel established between each edge node and its RR, the RR can perform peer authentication on behalf of the edge node. The RR has policies on peer communication and the built-in capability to constrain the propagation of the BGP UPDATE messages to the authorized edge nodes only. - Scalable IPsec tunnel management In networks with multiple IPsec tunnels between edge nodes, BGP simplifies tunnel management by using BGP Tunnel Attribute Update to associate multiple IPsec tunnels with the client prefixes. Unlike traditional IPsec VPN where IPsec tunnels between two edge nodes are treated as independent parallel links requiring duplicated control plane messages for load sharing. - Simplified traffic selection configurations Configuring IPsec tunnel traffic selectors or admission control is greatly simplified with BGP. By leveraging Route Targets to represent SD-WAN VPNs, administrators can specify import/export policies for traffic selectors directly in the BGP control plane. Dunbar, et al. [Page 15] Internet-Draft BGP Usage for SD-WAN December 9, 2024 5.2. BGP Walk Through for Homogeneous Encrypted SD-WAN In a BGP-controlled Homogeneous Encrypted SD-WAN, a C-PE can advertise its attached client prefixes and the properties of the IPsec SA in a single BGP UPDATE message. For example, in the figure below, the BGP UPDATE message from C- PE2 to RR can have the client prefixes encoded in the MP-NLRI Path Attribute and the IPsec Tunnel associated information encoded in the Tunnel-Encapsulation [RFC9012] Attributes. +---------|RR |----------+ / Untrusted+---+ \ / \ / \ +---------+ +---------+ --+ |-----------------------| |-192.0.2.4/30 | | | C-PE2 |- VLAN = 15 | C-PE1 | +-|192.0.2.2| --|192.0.2.1| | | |-192.0.2.8/30 +---------+ | +---------+ | | | +---------+ | --| |---------------------+ | | | C-PE3 | --|192.0.2.3| +---------+ Figure 5: Homogeneous Encrypted SD-WAN Alternatively, C-PE2 can use two separate BGP UPDATE messages: - Update 1 for advertising the attached client prefixes. - Update 2 for advertising the underlay properties of the IPsec tunnel. This dual-update approach offers flexibility and efficiency, especially for managing IPsec tunnels at edge nodes or WAN ports. Since IPsec tunnels often have attributes (e.g., nonce values) that change at different intervals compared to client prefix updates, separating the advertisements reduces the size of BGP UPDATE messages. Additionally, multiple client prefixes can share a single IPsec SA tunnel, further optimizing the process. Dunbar, et al. [Page 16] Internet-Draft BGP Usage for SD-WAN December 9, 2024 When using two separate BGP UPDATE messages, as described by Section 4 and 8 of [RFC9012], UPDATE 1 advertises client prefixes with the next-hop set to the C-PE2 loopback address. UPDATE 2 advertises the SD-WAN underlay path with the Tunnel Encapsulation Attribute, detailing the IPsec SA attributes. In this model, the next-hop in UPDATE 1 is recursively resolved to the IPsec SA tunnel type advertised by UPDATE 2. Traffic for the client prefixes is forwarded according to the path determined by UPDATE 1, with encapsulation and underlay attributes specified in UPDATE 2. For example, for packets to reach client addresses attached to C- PE2 (e.g., prefix 192.0.2.4/30), the following steps occur: - UPDATE 1 advertises the client prefixes (192.0.2.4/30), without a Tunnel Encapsulation attribute. However, it may include the Encapsulation Extended Community, with an optional Color Extended Community. The address of the next-hop of UPDATE 1 is router C-PE2. - UPDATE 2 advertises the SD-WAN underlay path, including the Tunnel Encapsulation attribute to describe the IPsec SA detailed attributes. UPDATE 1 (client prefix advertisement): - MP-NLRI Path Attribute: 192.0.2.4/30 192.0.2.8/30 - Nexthop: 192.0.2.2 (C-PE2) - Encapsulation Extended Community: TYPE = SDWAN-Hybrid Note: The IPsec Tunnel Type specified in RFC 5566 is obsolete. To indicate that the prefixes 192.0.2.4/30 and 192.0.2.8/30 are carried using a hybrid of IPsec underlay paths, a new tunnel type, such as one designed for SDWAN-Hybrid environments, is required. The specific definition and mechanism of such a tunnel type are expected to be addressed in future specifications. UPDATE 2 (Underlay tunnel advertisement): - MP-NLRI Path Attribute: 192.0.2.2 (C-PE2) Dunbar, et al. [Page 17] Internet-Draft BGP Usage for SD-WAN December 9, 2024 - Tunnel Encapsulation Path Attributes for IPsec SA detailed attributes, including the WAN address to be used as the IP address of the IPsec encrypted packets. If different client prefixes attached to C-PE2 need to be reached by separate underlay IPsec tunnels, the Color Extended Community [RFC9012] can be used to associate the prefixes with the tunnels. See Section 8 of [RFC9012]. In cases where C-PE2 does not have a policy on the authorized peers for the specific client prefixes, the RR must enforce the policies. The RR ensures that BGP UDPATE for the client prefixes are propagated only to other authorized edge nodes. 5.3. BGP Walk Through for Differential Encrypted SD-WAN In this scenario, client prefixes may have distinct forwarding requirements based on business or network policies. Some client prefixes can be forwarded over any tunnels terminating at the edge node. Some client prefixes must be forwarded over specific tunnels (such as only MPLS VPN). To achieve this, an edge node can use the Color Extended Community (Section 4 & 8 of [RFC9012]) in its BGP UPDATE message to associate the client prefixes with the specific tunnels. For example, in Figure 5 above, Route 192.0.2.4/30 can be transported over either MPLS or IPsec and Route 192.0.2.8/30 is restricted to MPLS only. To achieve this, C-PE2 can use the following UPDATE messages: UPDATE #1a for advertising client prefix 192.0.2.4/30: - MP-NLRI Path Attribute: 192.0.2.4/30 Nexthop: 192.0.2.2 (C-PE2) - Encapsulation Extended Community: TYPE = SDWAN-Hybrid - Color Extended Community: RED UPDATE #1b for advertising client prefix 192.0.2.8/30: - MP-NLRI Path Attribute: 192.0.2.8/30 Nexthop: 192.0.2.2 (C-PE2) - Encapsulation Extended Community: TYPE = MPLS [RFC8365] Dunbar, et al. [Page 18] Internet-Draft BGP Usage for SD-WAN December 9, 2024 UPDATE #2: for advertise-ing the underlay IPsec tunnel terminated at the node: - MP-NLRI Path Attribute: 192.0.2.2 (C-PE2) - Tunnel Encapsulation Path Attributes: TYPE=SD-WAN-Hybrid Including the information about the WAN ports for receiving IPsec encrypted packets, the IPsec properties, etc. - Color Extended Community: RED 5.4. BGP Walk Through for Flow-Based Segmentation In a flow-based segmentation scenario, as described in 3.1.3, a service flow is identified by specific fields in the packets' IP header. Flow-based Segmentation can be achieved by constraining the propagation of BGP UPDATE messages to nodes that meet the criteria of the service flow . For example, to ensure that the Payment Application in branch locations only communicates with the Payment Gateway as depicted in Figure 6, the following BGP UPDATE messages can be advertised: BGP UPDATE #1a from C-PE2 to RR for the P2P topology that is only propagated to Payment GW node: - MP-NLRI Path Attribute: - 192.0.2.9/30 - Nexthop: 192.0.2.2 - Encapsulation extended community: TYPE = SDWAN-Hybrid - Color Extended Community: BLUE BGP UPDATE #1b from C-PE2 to RR is propagated to C-PE1 & C-PE3 for other prefixes that can be reached by C-PE1 and C-PE3: - MP-NLRI Path Attribute: - 192.0.2.4/30 - 192.0.2.8/30 - Nexthop:192.0.2.2 - Encapsulation extended community: TYPE =SDWAN-Hybrid - Color Extended Community: RED Dunbar, et al. [Page 19] Internet-Draft BGP Usage for SD-WAN December 9, 2024 BGP UPDATE #2a for advertising the underlay IPsec Tunnel Path attributes terminated at C-PE2 192.0.2.2 that are propagated to C-PE1 & C-PE3. - MP-NLRI Path Attribute: 192.0.2.2 (C-PE2) - Tunnel Encapsulation Path Attributes: TYPE=IPsec (for all IPsec SAs) - Color Extended Community: RED UPDATE #2b for advertising the IPsec SA to the Payment GW that is only propagated to Payment GW: - MP-NLRI Path Attribute: 192.0.2.2 (C-PE2) - Tunnel Encapsulation Path Attributes: TYPE=IPsec (for the IPsec SA to Payment GW). - Color Extended Community: Blue |Payment| +------->| GW |<----+ / +-------+ \ / Blue Tunnel \ /for Payment App:192.0.2.9/30\ / \ +------/--+ +----\----+ --|-----+ | | +---| 192.0.2.9/30 | | Red Tunnels | | --| C-PE1 |------------------------| |-192.0.2.4/30 |192.0.2.1| | C-PE2 | --| |------------------------|192.0.2.2|-192.0.2.8/30 | ------+ +| |- VLAN=25; / | |192.0.2.10/30 +---------+ / +---------+ --| |--------------------+ | C-PE3 | / |192.0.2.3| / --| |-----------------+ +---------+ Figure 6: Flow Based SD-WAN Segmentation Dunbar, et al. [Page 20] Internet-Draft BGP Usage for SD-WAN December 9, 2024 5.5. Benefit of Separate Client Update and Underlay Update By leveraging Recursive Next Hop Resolution as described in Section 8 of [RFC9012], the route UPDATE messages for client prefixes are significantly streamlined. This approach allows any changes to the attributes of underlay network tunnels-such as IPsec key refreshes-to be advertised independently of client prefix updates. This separation is particularly advantageous when the underlay paths are IPsec tunnels, which require periodic message exchanges for pairwise re-keying. Decoupling client updates from underlay updates ensures that changes in tunnel attributes, like IPsec re- keying, do not impact or delay the propagation of client prefix updates. 6. SD-WAN Forwarding Model This section describes how client traffic is forwarded in a BGP Controlled SD-WAN for the use cases described in Section 3. The forwarding procedures described in Section 6 of [RFC8388] are applicable for the SD-WAN client traffic. Similar to the BGP-based VPN/EVPN client prefixes UPDATE message, Route Targets can be used to distinguish routes from different clients. 6.1. Forwarding Model for Homogeneous Encrypted SD-WAN 6.1.1. Network and Service Startup Procedures In the Homogeneous Encrypted SD-WAN Scenario, two SAs must be present to secure bidirectional traffic between two C-PE nodes (or two client ports, or two prefixes) because one IPsec security association (SA) only protects data in one direction. For example, in the full mesh scenario in Figure 2 of Section 3.2, where client CN2 is attached to C-PE1, C-PE3, and C-PE4, six uni- directional IPsec SAs must be established: C-PE1 <-> C-PE3; C-PE1 <-> C-PE4; C-PE3 <-> C-PE4. SD-WAN services to clients can be IP-based or Ethernet-based. For IP-based services, an SD-WAN edge can learn client prefixes from the client-facing ports via OSPF, RIP, BGP, or static configuration. For Layer-2 services, the EVPN parameters, such as the ESI (Ethernet Segment Identifier), EVI (Ethernet Virtual Instance), and CE-VID (Customer Edge Virtual Instance Identifier) to EVI mapping, can be configured as described in [RFC8388]. Dunbar, et al. [Page 21] Internet-Draft BGP Usage for SD-WAN December 9, 2024 Instead of running IGP within each IPsec tunnel, as in traditional IPsec VPN, a BGP RR can propagate the client prefix UPDATE messages to its authorized peers. The controller manages the association of client routes with individual IPsec SAs, eliminating the need for manual configuration of IPsec tunnel endpoints and client prefix policies on each edge node. 6.1.2. Packet Walk-Through For unicast packets forwarding: An IPsec SA terminated at a C-PE node can have multiple client prefixes multiplexed in the IPsec SA (or tunnel). Packets to/from the client prefixes are encapsulated in an inner tunnel, such as GRE or VxLAN. Different client traffic can be differentiated by a unique value in the inner encapsulation key or ID field. The GRE or VxLAN tunnel is encapsulated by an outer IP header whose destination & source addresses are the C-PE nodes loopback addresses and most likely has the Protocol-code = ESP (50). C-PE Node-based IPsec tunnel is inherently protected when the C- PE has multiple WAN ports to different underlay paths. As shown in Figure 2, when one of the underlay paths fails, the IPsec traffic can be forwarded to or received from a different physical port. When a C-PE receives an IPsec encrypted packet from its WAN ports, it decrypts the packet and forwards the inner packet to the client port based on the inner packet's destination address. For multicast packets forwarding: IPsec was created to be a security protocol between two and only two devices, so multicast service using IPsec is problematic. An IPsec peer encrypts a packet so that only one other IPsec peer can successfully perform the de-encryption. A straightforward way to forward a multicast packet for the Homogeneous Encrypted SD-WAN is to encapsulate the multicast packet in separate unicast IPsec SA tunnels. More optimized forwarding multicast packets for the Homogeneous Encrypted SD-WAN is out of the scope of this document. Dunbar, et al. [Page 22] Internet-Draft BGP Usage for SD-WAN December 9, 2024 6.2. Forwarding Model for Hybrid Underlay SD-WAN In this scenario, as shown in Figure 3 of Section 3.3, traffic forwarded over the trusted VPN paths can be native (i.e., unencrypted). The traffic forwarded over untrusted networks need to be protected by IPsec SA. 6.2.1. Network and Service Startup Procedures Infrastructure setup: The proper MPLS infrastructure must be configured among the edge nodes, i.e., the C-PE1/C-PE2/C-PE3/C-PE4 of Figure 3. The IPsec SA between wAN ports or nodes must be set up as well. IPsec SA related attributes on edge nodes can be distributed by BGP UPDATE messages as described in Section 5. There could be policies governing how flows can be forwarded, as specified by [MEF70.1]. For example, "Private-only" indicates that the flows can only traverse the MPLS VPN underlay paths. 6.2.2. Packet Walk-Through Unicast packets forwarding: When C-PE-a in Figure 7 receives a packet from a client port, the forwarding decision depends on the flow's routing policy. If a packet belonging to a flow that must be forwarded over the MPLS VPN, the forwarding processing is the same as the MPLS VPN. Otherwise, C-PE-a can select the least cost path, including the previously established MPLS paths and IPsec Tunnels, to forward the packet. Packets forwarded over the trusted MPLS VPN do not require additional encryption, while those sent over untrusted networks must be encrypted by IPsec SA. For a c-PE with multiple WAN ports provided by different NSPs, separate IPsec SAs can be established for the WAN ports. In this case, the C-PE have multiple IPsec tunnels in addition to the MPLS path to choose from to forward the packets from the client ports. If the IPsec SA is chosen, the packet is encapsulated by the IPsec header and encrypted by the IPsec SA before forwarding it to the WAN. Packets received over MPLS paths are processed as in standard MPLS VPNs. For packets encrypted with IPsec received from WAN ports, the C-PE decrypts and decapsulates the inner payload before forwarding it according to the local forwarding table. To protect against potential attacks, traffic received through Dunbar, et al. [Page 23] Internet-Draft BGP Usage for SD-WAN December 9, 2024 Internet-facing WAN ports must undergo anti-DDoS mechanisms, which are beyond the scope of this document. Additionally, the control plane must avoid learning routes from Internet-facing WAN ports to ensure network integrity. +--------------|RR |----------+ / +-+-+ \ / \ / \ +----+ +---------+ packets encrypted over +---------+ +----+ | CN3|--| A1-----+ Untrusted +----- B1 |--| CN1| +----+ | C-PE-a A2-----+ +------B2 C-PE-b | +----+ |192.0.2.1| |192.0.2.2| +----+ | A3 |PE+--------------+PE |--B3 |--| CN3| +----+ +---------+ +--+ trusted +---+ +---------+ +----+ | VPN | +-----------+ Figure 7: Over hybrid SD-WAN Multicast packets forwarding: For multicast traffic, MPLS multicast [RFC6513, RFC6514, or RFC7988] can be utilized to forward multicast traffic across the network. If IPsec tunnels are used for multicast traffic, the packet must be encapsulated and encrypted separately for each destination, creating multiple unicast IPsec tunnels to deliver the multicast packet to all intended recipients. 6.3. Forwarding Model for PE based SD-WAN 6.3.1. Network and Service Startup Procedures In this scenario, all PEs have secure interfaces facing the clients and facing the MPLS backbone. Some PEs have additional interfaces to the untrusted public Internet which are for offloading low priority traffic when the MPLS paths get congested. The PEs are already connected to their RRs, and the configurations for the clients and policies are already established. 6.3.2. Packet Walk-Through When offloading MPLS packets to the Internet path, each MPLS packet is encapsulated by an outer IP header as MPLS-in-IP or MPLS-in-GRE [RFC4023]. The outer IP address can be an interface address or the PE's loopback address. Dunbar, et al. [Page 24] Internet-Draft BGP Usage for SD-WAN December 9, 2024 When IPsec Tunnel mode is used to protect an MPLS-in-IP packet, the entire MPLS-in-IP packet is placed after the IPsec tunnel header. In IPsec transport mode, the MPLS-in-IP packet's IP header becomes the outer IP header of the IPsec packet, followed by an IPsec header, and then followed by the MPLS label stack. The IPsec header must set the payload type to MPLS by using the IP protocol number specified in section 3 of [RFC4023]. For the MPLS-in-GRE packets protected by IPsec Transport Mode, the GRE header follows the IPsec header. The IPsec SA's endpoints should not be the client-facing interface addresses unless the traffic to/from those clients always goes through the IPsec SA even when the MPLS backbone has enough capacity to transport the traffic. When the PEs' Internet-facing ports are behind the NAT [RFC3715], additional measures are necessary to support NAT traversal. In this Case, an outer UDP field is added to the encrypted payload [RFC3948]. Three specific ports and protocols must remain open on the PEs: UDP port 4500 (used for NAT traversal), UDP port 500 (used for IKE), and IP protocol 50 (ESP). The IPsec IKE (Internet Key Exchange) sessions between PEs navigate NAT environment using the mechanisms outlined in [RFC3947]. When a packet is received from a client port, it is initially processed according to the MPLS VPN forwarding rules. If the MPLS backbone path to the destination is congested, the packet is encapsulated as an MPLS-in-IP packet and encrypted using the IPsec tunnel to the target PE. Conversely, when a packet is received from an Internet-facing WAN port, it is decrypted, and the inner MPLS payload is extracted and forwarded to the MPLS VPN engine for further processing. Same as Scenario #2, the additional anti-DDoS mechanism must be enabled to prevent potential attacks from the Internet-facing port. Control Plane should not learn routes from the Internet- facing WAN ports. 7. Manageability Considerations A BGP-controlled SD-WAN utilizes the BGP RR to facilitate the routes and underlay properties distribution among the authorized edge nodes. With RR having the preconfigured policies about the authorized peers, the peer-wise authentications of the IPsec IKE (Internet Key Exchange) are significantly simplified. Dunbar, et al. [Page 25] Internet-Draft BGP Usage for SD-WAN December 9, 2024 8. Security Considerations In a BGP-controlled SD-WAN network where the BGP RR serves as the SD-WAN controller, there are unique security advantages over traditional peer-to-peer IPsec tunnel networks. The centralized control model facilitated by the BGP RR allows for more consistent security management. The RR can ensure that BGP Update messages from each node are only distributed to authorized peers based on preconfigured policies. This approach reduces the potential attack surface compared to networks where peer nodes establish direct, decentralized tunnels that may lack uniform security oversight. This centralized policy enforcement can lead to a relaxation of certain security measures that are typically necessary in more distributed architectures. In the BGP-controlled setup, because the RR dictates and controls the routing information exchange, it inherently limits the opportunity for unauthorized access and routing leaks between nodes. Furthermore, secure channels between the RR and SD-WAN edge nodes, while critical, are safeguarded by fewer, more focused security protocols, concentrating the security efforts on securing the RR itself rather than on each individual tunnel. Additionally, the use of IPsec tunnels over the public Internet, while potentially exposing the network to risks associated with public network exposure, is mitigated by the RR's governance. The RR's role in managing these connections enhances overall security by ensuring consistent application of encryption and access policies across the network. This central governance model simplifies the security architecture, allowing for more efficient monitoring and quicker response to threats, thereby reducing the complexity and potentially the cost of network security management compared to a peer-to-peer model. However, adding an Internet-facing WAN port to a C-PE can introduce the following security risks: 1) Potential DDoS attacks from the Internet-facing ports. 2) Potential risk of malicious traffic being injected via the Internet-facing WAN ports. 3) For the Differential Encrypted SD-WAN deployment model, there is a risk of unauthorized traffic injected into the Internet- facing WAN ports being leaked to the L2/L3 VPN networks. Dunbar, et al. [Page 26] Internet-Draft BGP Usage for SD-WAN December 9, 2024 Therefore, the additional anti-DDoS mechanism must be enabled on all Internet-facing ports to prevent potential attacks from those ports. Control Plane should not learn any routes from the Internet-facing WAN ports. In SD-WAN deployments where no secure management channel exists between the SD-WAN controller and the SD-WAN edges, TLS or IPsec can be established to bridge the gap. BGP is a TCP-based protocol that can be easily aligned with TLS-based security. 9. IANA Considerations No Action is needed. 10. References 10.1. Normative References [BCP195] Consists of RFC8996 and RFC9325. [RFC2332] J. Luciani, et al, "NBMA Next Hop Resolution Protocol (NHRP)", RFC2332, April 1998. [RFC2784] D. Farinacci, et al, "Generic Routing Encapsulation (GRE)" RFC2784, March 2000. [RFC3715] B. Aboba, W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", March 2004. [RFC3947] T. Kivinen, et al, "Negotiation of NAT Traversal in the IKE", Jan. 2005. [RFC3948] A. Huttunen, et al, "UDP Encapsulation of IPsec ESP Packets", Jan 2005. [RFC4023] T. Worster, Y. Rekhter, E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", March 2005. [RFC4360] S. Sangli, et al, "BGP Extended Communities Attribute", RFC4360, Feb. 2006. Dunbar, et al. [Page 27] Internet-Draft BGP Usage for SD-WAN December 9, 2024 [RFC4364] E. Rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private networks (VPNs)", Feb 2006. [RFC4456] T. Bates, E. Chen, R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", April 2006. [RFC4659] J. De clercq, et al, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC4659, Sept 2006. [RFC4761] K. Kompella and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC4761, Jan. 2007. [RFC4762] M. Lasserre and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC4762, Jan. 2007. [RFC6071] S. Frankel, S. Krishan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", Feb 2011. [RFC7296] C. Kaufman, et al, "Internet Key Exchange Protocol Version 2 (IKEv2)", Oct 2014. [RFC7348] M. Mahalingam, et al, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC7348, Aug 2014. [RFC7432] A. Sajassi, et al, "BGP MPLS-Based Ethernet VPN", RFC7432, Feb 2015. [RFC8200] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification". July 2017. [RFC8365] A. Sajassi, et al, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", March 2018. [RFC8388] J. Rabadan, et al, "Usage and Applicability of BGP MPLS- Based Ethernet VPN", RFC8388, May 2018. Dunbar, et al. [Page 28] Internet-Draft BGP Usage for SD-WAN December 9, 2024 [RFC9012] K.Patel, et al "The BGP Tunnel Encapsulation Attribute", RFC9012, April 2021. [RFC9522] A. Farrel, "Overview and Principles of Internet Traffic Engineering", RFC9522, Jan. 2024. 10.2. Informative References [Net2Cloud-Problem] L. Dunbar and A. Malis, "Dynamic Networks to Hybrid Cloud DCs: Problems and Mitigation Practices", draft-ietf-rtgwg-net2cloud-problem-statement-41, July. 2024. [IEEE802.3] "IEEE Standard for Ethernet" by The Institute of Electrical and Electronics Engineers (IEEE) 802.3. [MEF70.1] SD-WAN Service Attributes and Service Framework, https://www.mef.net/resources/mef-70-1-sd-wan-service- attributes-and-service-framework/. Nov 2021. [MEF70.2] "SD-WAN Service Attributes and Service Framework" by MEF, https://www.mef.net/resources/mef-70-2-sd-wan- service-attributes-and-service-framework/. Oct 2023. 11. Acknowledgments Acknowledgements to Gunter van de Velde, Andrew Alston, Adrian Farrel, Jim Guichard, Joel Halpern, John Scudder, Darren Dukes, Andy Malis, Donald Eastlake, Stephen Farrell, and Victo Sheng for their review and contributions. This document was prepared using 2-Word-v2.0.template.dot. Dunbar, et al. [Page 29] Internet-Draft BGP Usage for SD-WAN December 9, 2024 Authors' Addresses Linda Dunbar Futurewei Email: ldunbar@futurewei.com Ali Sajassi Cisco Email: sajassi@cisco.com John Drake Independent Email: je_drake@yahoo.com Basil Najem Bell Canada Email: basil.najem@bell.ca Sue Hares Email: shares@ndzh.com Contributor's Addresses David Carrel Graphiant Email: carrel@graphiant.com Ayan Banerjee Cisco Email: ayabaner@cisco.com Dunbar, et al. [Page 30]