]> Huawei

Beiqing Road Beijing shengcheng@huawei.com

Huawei

Beiqing Road Beijing China shihang9@huawei.com

Futurewei

linda.dunbar@futurewei.com

Routing Inter-Domain Routing Multi-segment SD-WAN The document describes the control plane enhancement for multi-segment SD-WAN to exchange the corresponding GW information between edges. Discussion Venues Discussion of this document takes place on the Inter-Domain Routing Working Group mailing list (idr@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction describes the enterprises utilizing Cloud Providers’ backbone to interconnect their branch offices. As shown in Figure 1, CPE-1 and CPE-2 are connected to their respective Cloud Gateways (GW) in different regions. CPE-1 and CPE-2 maintain the pairwise IPsec SAs. The IPsec encrypted traffic from CPE-1 to CPE-2 is encapsulated by the GENEVE header , with the outer destination address being the GW1. specifies a set of sub-TLVs to carry the information of the GWs of the destination branches, e.g., GW3 for CPE-2 and other attributes. To accomplish that, CPE-1 needs to know their peers' corresponding GW addresses. This document proposes a BGP extension based on for a CPE to advertise its directly connected GW address to other CPEs.

Multi-segment SD-WAN

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. The following acronyms and terms are used in this document:

• Cloud DC: Off-Premises Data Center, managed by 3rd party, that hosts applications, services, and workload for different organizations or tenants.
• CPE: Customer (Edge) Premises Equipment.
• OnPrem: On Premises data centers and branch offices.
• RR Route Reflector.
• SD-WAN: Software Defined Wide Area Network. In this document, “SD-WAN” refers to a policy-driven transporting of IP packets over multiple underlay networks for better WAN bandwidth management, visibility, and control.
• VPN Virtual Private Network.

Extension to SD-WAN Underlay UPDATE for Corresponding GWs The Client Routes Update is the same as described in .

Corresponding GW Sub-TLV The Corresponding GW Sub-TLV, within the SD-WAN-Hybrid Tunnel TLV (code point 25), carries the corresponding GW address(es) with which the SD-WAN edge is associated. The following is the structure of the Corresponding GW Sub-TLV:

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

IANA Considerations TBD.

Normative References Microsoft Futurewei Arista Microsoft The document describes the methods to optimize the stitching of multiple SD-WAN segments on transit nodes across Cloud DCs. Network virtualization involves the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters. As a result of their role in tying together different elements of the system, the requirements on tunnels are influenced by all of these components. Therefore, flexibility is the most important aspect of a tunneling protocol if it is to keep pace with the evolution of technology. This document describes Geneve, an encapsulation protocol designed to recognize and accommodate these changing capabilities and needs. Futurewei Hickory Hill Consulting Arrcus Microsoft Verizon Arista The document describes the encoding of BGP UPDATE messages for the SD-WAN edge node property discovery. 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.