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/