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

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/