--- 1/draft-ietf-idr-sdwan-edge-discovery-01.txt 2022-04-26 14:13:11.636818904 -0700 +++ 2/draft-ietf-idr-sdwan-edge-discovery-02.txt 2022-04-26 14:13:11.692820331 -0700 @@ -1,24 +1,24 @@ Network Working Group L. Dunbar Internet Draft Futurewei Intended status: Standard S. Hares -Expires: September 5, 2022 Hickory Hill Consulting +Expires: October 26, 2022 Hickory Hill Consulting R. Raszuk NTT Network Innovations K. Majumdar CommScope Gyan Mishra Verizon - March 5, 2022 + April 26, 2022 BGP UPDATE for SDWAN Edge Discovery - draft-ietf-idr-sdwan-edge-discovery-01 + draft-ietf-idr-sdwan-edge-discovery-02 Abstract The document describes the encoding of BGP UPDATE messages for the SDWAN edge node discovery. In the context of this document, BGP Route Reflector (RR) is the component of the SDWAN Controller that receives the BGP UPDATE from SDWAN edges and in turns propagates the information to the intended peers that are authorized to communicate via the SDWAN overlay @@ -37,25 +37,25 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - This Internet-Draft will expire on Dec 31, 2020. + This Internet-Draft will expire on Dec 25, 2022. Copyright Notice - Copyright (c) 2021 IETF Trust and the persons identified as the + Copyright (c) 2022 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 (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 @@ -98,22 +98,22 @@ 11.2. Tunnel Encapsulation Attribute Type.....................27 12. References...................................................28 12.1. Normative References....................................28 12.2. Informative References..................................28 13. Acknowledgments..............................................30 1. Introduction [SDWAN-BGP-USAGE] illustrates how BGP [RFC4271] is used as a control plane for a SDWAN network. SDWAN network refers to a policy-driven - network over multiple different underlay networks to get better WAN - bandwidth management, visibility, and control. + network over multiple heterogeneous underlay networks to get better + WAN bandwidth management, visibility, and control. The document describes BGP UPDATE messages for an SDWAN edge node to announce its properties to its RR which then propagates that information to the authorized peers. 2. Conventions used in this document 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 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all @@ -216,35 +216,34 @@ o By running routing protocol within each IPsec SA o If multiple IPsec SAs between two peer nodes are established to achieve load sharing, each IPsec tunnel needs to run its own routing protocol to exchange client routes attached to the edges. - Access List or Traffic Selector) o Permit Local-IP1, Remote-IP2 In a BGP-controlled SDWAN network over hybrid MPLS VPN and public internet underlay networks, all edge nodes and RRs are already - connected by private VPN paths. The RRs have the policies to manage - the authentication of all peer nodes. More importantly, when an edge - node needs to establish multiple IPsec tunnels to many edge nodes, - all the management information can be multiplexed into the secure - management tunnel between RR and the edge node. Therefore, the - amount of authentication in a BGP-Controlled SDWAN network can be - significantly reduced. + connected by private secure paths. The RRs have the policies to + manage the authentication of all peer nodes. More importantly, when + an edge node needs to establish multiple IPsec tunnels to many edge + nodes, all the management information can be multiplexed into the + secure management tunnel between RR and the edge node. Therefore, + the amount of authentication in a BGP-Controlled SDWAN network can + be significantly reduced. Client VPNs are configured via VRFs, just like the configuration of the existing MPLS VPN. The IPsec equivalent traffic selectors for local and remote routes are achieved by importing/exporting VPN Route Targets. The binding of client routes to IPsec SA is dictated by policies. As a result, the IPsec configuration for a BGP - controlled SDWAN (with mixed MPLS VPN) can be simplified as the - following: + controlled SDWAN (with mixed MPLS VPN) can be simplified: - The SDWAN controller has the authority to authenticate edges and peers. Remote Peer association is controlled by the SDWAN Controller (RR) - The IKEv2 proposals, including the IPsec Transform set, can be sent directly to peers or incorporated in a BGP UPDATE. - BGP UPDATE: Announces the client route reachability for all permitted parallel tunnels/paths. o There is no need to run multiple routing protocols in each IPsec tunnel. @@ -319,28 +318,28 @@ specifies the detailed hybrid WAN underlay tunnels terminated at the C-PE2: UPDATE U2: NLRI: SAFI = SDWAN-Hybrid (With Color RED encoded in the NLRI Site-Property field) Prefix: 2.2.2.2 Tunnel encapsulation Path Attribute [type=SDWAN-Hybrid] IPSec SA for 192.0.0.1 - Tunnel-End-Point Sub-TLV for 192.0.0.1 [Tunnel-encap] + Tunnel-End-Point Sub-TLV for 192.0.0.1 [RFC9012] IPsec-SA-ID sub-TLV [See the Section 6] Tunnel encapsulation Path Attribute [type=SDWAN-Hybrid] IPSec SA for Tunnel-End-Point Sub-TLV /* for 170.0.0.1 */ IPsec-SA-ID sub-TLV Tunnel Encap Attr MPLS-in-GRE [type=SDWAN-Hybrid] - Sub-TLV for MPLS-in-GRE [Section 3.2.6 of Tunnel-encap] + Sub-TLV for MPLS-in-GRE [Section 3.2.6 of RFC9012] Note: [RFC9012] Section 11 specifies that each Tunnel Encap Attribute can only have one Tunnel-End-Point sub-TLV. Therefore, two separate Tunnel Encap Attributes are needed to indicate that the client routes can be carried by either one. 3.4. Edge Node Discovery The basic scheme of SDWAN edge node discovery using BGP consists of the following: @@ -372,22 +371,22 @@ properties propagation among the RRs. For some environments where the communication to RR is highly secured, [RFC9016] IKE-less can be deployed to simplify IPsec SA establishment among edge nodes. 4. BGP UPDATE to Support SDWAN Segmentation 4.1. SDWAN Segmentation, SDWAN Virtual Topology and Client VPN In SDWAN deployment, "SDWAN Segmentation" is a frequently used term, - referring to partitioning a network to multiple sub-networks, just - as MPLS VPN does. "SDWAN Segmentation" is achieved by creating SDWAN + referring to partitioning a network into multiple sub-networks, just + like MPLS VPNs. "SDWAN Segmentation" is achieved by creating SDWAN virtual topologies and SDWAN VPNs. An SDWAN virtual topology consists of a set of edge nodes and the tunnels (a.k.a. underlay paths), including both IPsec tunnels and/or MPLS VPN tunnels, interconnecting those edge nodes. An SDWAN VPN is the same as a client VPN, which is configured in the same way as the VRFs on PEs of an MPLS VPN. One SDWAN client VPN can be mapped to multiple SD-WAN virtual topologies. SDWAN Controller governs the policies of mapping a client VPN to SDWAN virtual topologies. @@ -1111,30 +1110,30 @@ multipoint-vpn-dmvpn/index.html [DSVPN] Dynamic Smart VPN: http://forum.huawei.com/enterprise/en/thread-390771-1- 1.html [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, storage, distribution and enforcement of policies for network security", Nov 2007. - [Net2Cloud-Problem] L. Dunbar and A. Malis, "Seamless Interconnect - Underlay to Cloud Overlay Problem Statement", draft-dm- - net2cloud-problem-statement-02, June 2018 + [Net2Cloud-Problem] L. Dunbar and A. Malis, "Dynamic Networks to + Hybrid Cloud DCs Problem Statement", draft-ietf-rtgwg- + net2cloud-problem-statement-12, March 7, 2022. - [Net2Cloud-gap] L. Dunbar, A. Malis, and C. Jacquenet, "Gap Analysis - of Interconnecting Underlay with Cloud Overlay", draft-dm- - net2cloud-gap-analysis-02, work-in-progress, Aug 2018. + [Net2Cloud-gap] L. Dunbar, A. Malis, and C. Jacquenet, "Networks + Connecting to Hybrid Cloud DCs: Gap Analysis", draft-ietf- + rtgwg-net2cloud-gap-analysis-07, July, 2020. - [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation - Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 2018. + [RFC9012] K. Patel, et al "The BGP Tunnel Encapsulation Attribute", + RFC9012, April 2021. 13. Acknowledgments Acknowledgements to Wang Haibo, Hao Weiguo, and ShengCheng for implementation contribution; Many thanks to Yoav Nir, Graham Bartlett, Jim Guichard, John Scudder, and Donald Eastlake for their review and suggestions. This document was prepared using 2-Word-v2.0.template.dot.