draft-ietf-bess-evpn-ip-aliasing-01.txt		draft-ietf-bess-evpn-ip-aliasing-02.txt
	Network Working Group A. Sajassi, Ed.		Network Working Group A. Sajassi, Ed.
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track J. Rabadan, Ed.		Intended status: Standards Track J. Rabadan, Ed.
	Expires: 5 September 2024 Nokia		Expires: 8 May 2025 Nokia
	S. Pasupula		S. Pasupula
	L. Krattiger		L. Krattiger
	Cisco Systems		Cisco Systems
	J. Drake		J. Drake
	Independent		Independent
	4 March 2024		4 November 2024
	EVPN Support for L3 Fast Convergence and Aliasing/Backup Path		EVPN Support for L3 Fast Convergence and Aliasing/Backup Path
	draft-ietf-bess-evpn-ip-aliasing-01		draft-ietf-bess-evpn-ip-aliasing-02
	Abstract		Abstract
	This document proposes an EVPN extension to allow several of its		This document proposes an EVPN extension to allow several of its
	multi-homing functions, fast convergence, and aliasing/backup path,		multi-homing functions, fast convergence, and aliasing/backup path,
	to be used in conjunction with inter-subnet forwarding. The		to be used in conjunction with inter-subnet forwarding. The
	extension is limited to All-Active and Single-Active redundancy		extension is limited to All-Active and Single-Active redundancy
	modes.		modes.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 5 September 2024.		This Internet-Draft will expire on 8 May 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	skipping to change at page 7, line 16 ¶		skipping to change at page 7, line 16 ¶
	CE1 would not be possible since only PE1 would advertise EVPN IP		CE1 would not be possible since only PE1 would advertise EVPN IP
	Prefix routes for CE1's prefixes. This document provides a solution		Prefix routes for CE1's prefixes. This document provides a solution
	so that PE3 considers PE2 as a next hop in the IP ECMP list for CE1's		so that PE3 considers PE2 as a next hop in the IP ECMP list for CE1's
	prefixes, even if PE2 did not advertise the IP Prefix routes for		prefixes, even if PE2 did not advertise the IP Prefix routes for
	those prefixes in the first place. The solution uses an ESI in the		those prefixes in the first place. The solution uses an ESI in the
	IP Prefix routes advertised from PE1 so that, when imported by PE2,		IP Prefix routes advertised from PE1 so that, when imported by PE2,
	PE2 installs the route as local, since PE2 is also attached to the		PE2 installs the route as local, since PE2 is also attached to the
	Ethernet Segment identified by the ESI.		Ethernet Segment identified by the ESI.
	Note that Figure 3 shows a scenario with only one BGP session between		Note that Figure 3 shows a scenario with only one BGP session between
	the CE and the PEs in the Layer 3 Ethernet Segment, so that the		the CE and the PEs in the Layer-3 Ethernet Segment, so that the
	description of the procedures can be simplified. However, the		description of the procedures can be simplified. However, the
	scenario is expected to be deployed with N BGP sessions between the		scenario is expected to be deployed with N BGP sessions between the
	CE and M PEs in the Ethernet Segment, with M being greater than N,		CE and M PEs in the Ethernet Segment, with M being greater than N,
	and N being at least 2. In that way, a failure on a PE terminating		and N being at least 2. In that way, a failure on a PE terminating
	one of the PE-CE BGP sessions is still protected and the packet loss		one of the PE-CE BGP sessions is still protected and the packet loss
	kept to a minimum number.		kept to a minimum number.
			Additionally, Figure 3 shows how CE1 can connect to PE1 and PE2 using
			Layer-3 links via IRB interfaces and their associated BDs. However,
			the procedures described here are also applicable if CE’s Layer-3
			links are connected to non-IRB Layer-3 interfaces within the PEs' IP-
			VRF. In other words, CE1’s Layer-3 links may directly connect to
			non-IRB Layer-3 interfaces in PE1/PE2 IP-VRFs. Using IRB interfaces
			and BDs on the PEs allows multiple CE links to be aggregated into a
			single BD, enabling a single Layer-3 interface on the IP-VRF instead
			of requiring individual Layer-3 interfaces for each CE.
	1.3.2. IP Aliasing in a Centralized Routing Model		1.3.2. IP Aliasing in a Centralized Routing Model
	Figure 4 illustrates a model in which multiple CEs establish an eBGP		Figure 4 illustrates a model in which multiple CEs establish an eBGP
	PE-CE session with a Centralized PE.		PE-CE session with a Centralized PE.
	+-------------------------------+		+-------------------------------+
	| PE1 EVPN |		| PE1 EVPN |
	+----------+ |		+----------+ |
	| +------+| |		| +------+| |
	| |IP-VRF|| |		| |IP-VRF|| |
	skipping to change at page 10, line 11 ¶		skipping to change at page 10, line 11 ¶
	* EVI: An EVPN instance spanning the Provider Edge (PE) devices		* EVI: An EVPN instance spanning the Provider Edge (PE) devices
	participating in that EVPN.		participating in that EVPN.
	* EVPN IP route: An EVPN IP Prefix route or an EVPN MAC/IP		* EVPN IP route: An EVPN IP Prefix route or an EVPN MAC/IP
	Advertisement route.		Advertisement route.
	* IP-VRF: A VPN Routing and Forwarding table for IP routes on an		* IP-VRF: A VPN Routing and Forwarding table for IP routes on an
	NVE/PE. The IP routes could be populated by any routing protocol,		NVE/PE. The IP routes could be populated by any routing protocol,
	E.g., EVPN, IP-VPN and BGP PE-CE IP address families. An IP-VRF		E.g., EVPN, IP-VPN and BGP PE-CE IP address families. An IP-VRF
	is also an instantiation of a layer 3 VPN in an NVE/PE.		is also an instantiation of a Layer-3 VPN in an NVE/PE.
	* IRB: Integrated Routing and Bridging		* IRB: Integrated Routing and Bridging
	* IRB Interface: Integrated Bridging and Routing Interface. A		* IRB Interface: Integrated Bridging and Routing Interface. A
	virtual interface that connects the Bridge Table and the IP-VRF on		virtual interface that connects the Bridge Table and the IP-VRF on
	an NVE.		an NVE.
	* LACP: Link Aggregation Control Protocol.		* LACP: Link Aggregation Control Protocol.
	* MAC-VRF: A Virtual Routing and Forwarding table for Media Access		* MAC-VRF: A Virtual Routing and Forwarding table for Media Access
	skipping to change at page 11, line 5 ¶		skipping to change at page 11, line 5 ¶
	specified in [I-D.ietf-bess-evpn-virtual-eth-segment].		specified in [I-D.ietf-bess-evpn-virtual-eth-segment].
	The third use case in Section 1 requires an extension to the way		The third use case in Section 1 requires an extension to the way
	Ethernet Segments are defined and associated. In this case, the		Ethernet Segments are defined and associated. In this case, the
	Ethernet Segment is a Layer-3 construct characterized as follows:		Ethernet Segment is a Layer-3 construct characterized as follows:
	1. The ES is defined as a set of Layer-3 links to the multi-homed CE		1. The ES is defined as a set of Layer-3 links to the multi-homed CE
	and its state MUST be linked to the layer-3 reachability from		and its state MUST be linked to the layer-3 reachability from
	each multi-homed PE to the CE's IP address via a non-EVPN route		each multi-homed PE to the CE's IP address via a non-EVPN route
	in the PE's IP-VRF. A non-EVPN route in this context refers to a		in the PE's IP-VRF. A non-EVPN route in this context refers to a
	route in the IP-VRF's route table that is learned via a layer 3		route in the IP-VRF's route table that is learned via a Layer-3
	routing protocol and not from an EVPN IP Prefix route or an EVPN		routing protocol and not from an EVPN IP Prefix route or an EVPN
	MAC/IP Advertisement route.		MAC/IP Advertisement route.
	2. The ESI SHOULD be of type 4 [RFC7432] and set to the router ID of		2. The ESI SHOULD be of type 4 [RFC7432] and set to the router ID of
	the multi-homed CE.		the multi-homed CE.
	3. All-active or single-active multi-homing redundancy modes are		3. All-active or single-active multi-homing redundancy modes are
	supported, however, the redundancy mode only affects the		supported, however, the redundancy mode only affects the
	procedures in Section 3.		procedures in Section 3.
	skipping to change at page 20, line 39 ¶		skipping to change at page 20, line 39 ¶
	<https://www.rfc-editor.org/info/rfc9135>.		<https://www.rfc-editor.org/info/rfc9135>.
	[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and		[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
	A. Sajassi, "IP Prefix Advertisement in Ethernet VPN		A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
	(EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,		(EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
	<https://www.rfc-editor.org/info/rfc9136>.		<https://www.rfc-editor.org/info/rfc9136>.
	[I-D.ietf-bess-rfc7432bis]		[I-D.ietf-bess-rfc7432bis]
	Sajassi, A., Burdet, L. A., Drake, J., and J. Rabadan,		Sajassi, A., Burdet, L. A., Drake, J., and J. Rabadan,
	"BGP MPLS-Based Ethernet VPN", Work in Progress, Internet-		"BGP MPLS-Based Ethernet VPN", Work in Progress, Internet-
	Draft, draft-ietf-bess-rfc7432bis-08, 13 February 2024,		Draft, draft-ietf-bess-rfc7432bis-10, 24 July 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-bess-		<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
	rfc7432bis-08>.		rfc7432bis-10>.
	[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,		[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
	B., Zhuang, S., and J. Rabadan, "BGP Overlay Services		B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
	Based on Segment Routing over IPv6 (SRv6)", RFC 9252,		Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
	DOI 10.17487/RFC9252, July 2022,		DOI 10.17487/RFC9252, July 2022,
	<https://www.rfc-editor.org/info/rfc9252>.		<https://www.rfc-editor.org/info/rfc9252>.
	12.2. Informative References		12.2. Informative References
	[I-D.ietf-bess-evpn-virtual-eth-segment]		[I-D.ietf-bess-evpn-virtual-eth-segment]
	skipping to change at page 21, line 17 ¶		skipping to change at page 21, line 17 ¶
	Rabadan, "EVPN Virtual Ethernet Segment", Work in		Rabadan, "EVPN Virtual Ethernet Segment", Work in
	Progress, Internet-Draft, draft-ietf-bess-evpn-virtual-		Progress, Internet-Draft, draft-ietf-bess-evpn-virtual-
	eth-segment-15, 28 February 2024,		eth-segment-15, 28 February 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-bess-		<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
	evpn-virtual-eth-segment-15>.		evpn-virtual-eth-segment-15>.
	[I-D.ietf-bess-evpn-unequal-lb]		[I-D.ietf-bess-evpn-unequal-lb]
	Malhotra, N., Sajassi, A., Rabadan, J., Drake, J.,		Malhotra, N., Sajassi, A., Rabadan, J., Drake, J.,
	Lingala, A. R., and S. Thoria, "Weighted Multi-Path		Lingala, A. R., and S. Thoria, "Weighted Multi-Path
	Procedures for EVPN Multi-Homing", Work in Progress,		Procedures for EVPN Multi-Homing", Work in Progress,
	Internet-Draft, draft-ietf-bess-evpn-unequal-lb-21, 7		Internet-Draft, draft-ietf-bess-evpn-unequal-lb-23, 21
	December 2023, <https://datatracker.ietf.org/doc/html/		October 2024, <https://datatracker.ietf.org/doc/html/
	draft-ietf-bess-evpn-unequal-lb-21>.		draft-ietf-bess-evpn-unequal-lb-23>.
	[I-D.ietf-bess-bgp-srv6-args]		[I-D.ietf-bess-bgp-srv6-args]
	Talaulikar, K., Raza, S., Rabadan, J., and W. Lin, "SRv6		Talaulikar, K., Raza, S. K., Rabadan, J., and W. Lin,
	Argument Signaling for BGP Services", Work in Progress,		"SRv6 Argument Signaling for BGP Services", Work in
	Internet-Draft, draft-ietf-bess-bgp-srv6-args-00, 24		Progress, Internet-Draft, draft-ietf-bess-bgp-srv6-args-
	October 2023, <https://datatracker.ietf.org/doc/html/		01, 19 March 2024, <https://datatracker.ietf.org/doc/html/
	draft-ietf-bess-bgp-srv6-args-00>.		draft-ietf-bess-bgp-srv6-args-01>.
	Authors' Addresses		Authors' Addresses
	A. Sajassi (editor)		A. Sajassi (editor)
	Cisco Systems		Cisco Systems
	Email: sajassi@cisco.com		Email: sajassi@cisco.com
	J. Rabadan (editor)		J. Rabadan (editor)
	Nokia		Nokia
	520 Almanor Avenue		520 Almanor Avenue
End of changes. 12 change blocks.
	17 lines changed or deleted		27 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/