rfc9786v1.txt		rfc9786.txt
	skipping to change at line 22 ¶		skipping to change at line 22 ¶
	EVPN Port-Active Redundancy Mode		EVPN Port-Active Redundancy Mode
	Abstract		Abstract
	The Multi-Chassis Link Aggregation (MC-LAG) group technology enables		The Multi-Chassis Link Aggregation (MC-LAG) group technology enables
	establishing a logical link-aggregation connection with a redundant		establishing a logical link-aggregation connection with a redundant
	group of independent nodes. The objective of MC-LAG is to enhance		group of independent nodes. The objective of MC-LAG is to enhance
	both network availability and bandwidth utilization through various		both network availability and bandwidth utilization through various
	modes of traffic load balancing. RFC 7432 defines an EVPN-based MC-		modes of traffic load balancing. RFC 7432 defines an EVPN-based MC-
	LAG with Single-Active and All-Active multi-homing redundancy modes.		LAG with Single-Active and All-Active multihoming redundancy modes.
	This document builds on the existing redundancy mechanisms supported		This document builds on the existing redundancy mechanisms supported
	by EVPN and introduces a new active/standby redundancy mode, called		by EVPN and introduces a new active/standby redundancy mode, called
	'Port-Active'.		'Port-Active'.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	skipping to change at line 87 ¶		skipping to change at line 87 ¶
	8.1. Normative References		8.1. Normative References
	8.2. Informative References		8.2. Informative References
	Acknowledgements		Acknowledgements
	Contributors		Contributors
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	EVPN [RFC7432] defines the All-Active and Single-Active redundancy		EVPN [RFC7432] defines the All-Active and Single-Active redundancy
	modes. All-Active redundancy provides per-flow load balancing for		modes. All-Active redundancy provides per-flow load balancing for
	multi-homing, while Single-Active redundancy ensures service carving		multihoming, while Single-Active redundancy ensures service carving
	where only one of the Provider Edge (PE) devices in a redundancy		where only one of the Provider Edge (PE) devices in a redundancy
	relationship is active per service.		relationship is active per service.
	Although these two multi-homing scenarios are widely utilized in data		Although these two multihoming scenarios are widely utilized in data
	center and service provider access networks, there are cases where		center and service provider access networks, there are cases where
	active/standby multi-homing at the interface level is beneficial and		active/standby multihoming at the interface level is beneficial and
	necessary. The primary consideration for this new mode of load		necessary. The primary consideration for this new mode of load
	balancing is the determinism of traffic forwarding through a specific		balancing is the determinism of traffic forwarding through a specific
	interface rather than statistical per-flow load balancing across		interface rather than statistical per-flow load balancing across
	multiple PEs providing multi-homing. This determinism is essential		multiple PEs providing multihoming. This determinism is essential
	for certain QoS features to function correctly. Additionally, this		for certain QoS features to function correctly. Additionally, this
	mode ensures fast convergence during failure and recovery, which is		mode ensures fast convergence during failure and recovery, which is
	expected by customers.		expected by customers.
	This document defines the Port-Active redundancy mode as a new type		This document defines the Port-Active redundancy mode as a new type
	of multi-homing in EVPN and details how this mode operates and is		of multihoming in EVPN and details how this mode operates and is
	supported via EVPN.		supported via EVPN.
	1.1. Requirements Language		1.1. Requirements Language
	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
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	1.2. Multi-Chassis Link Aggregation (MC-LAG)		1.2. Multi-Chassis Link Aggregation (MC-LAG)
	When a Customer Equipment (CE) device is multi-homed to a set of PE		When a Customer Equipment (CE) device is multihomed to a set of PE
	nodes using the Link Aggregation Control Protocol (LACP)		nodes using the Link Aggregation Control Protocol (LACP)
	[IEEE_802.1AX_2014], the PEs must function as a single LACP entity		[IEEE_802.1AX_2014], the PEs must function as a single LACP entity
	for the Ethernet links to form and operate as a Link Aggregation		for the Ethernet links to form and operate as a Link Aggregation
	Group (LAG). To achieve this, the PEs connected to the same multi-		Group (LAG). To achieve this, the PEs connected to the same
	homed CE must synchronize LACP configuration and operational data		multihomed CE must synchronize LACP configuration and operational
	among them. Historically, the Inter-Chassis Communication Protocol		data among them. Historically, the Inter-Chassis Communication
	(ICCP) [RFC7275] has been used for this synchronization. EVPN, as		Protocol (ICCP) [RFC7275] has been used for this synchronization.
	described in [RFC7432], covers the scenario where a CE is multi-homed		EVPN, as described in [RFC7432], covers the scenario where a CE is
	to multiple PE nodes, using a LAG to simplify the procedure		multihomed to multiple PE nodes, using a LAG to simplify the
	significantly. However, this simplification comes with certain		procedure significantly. However, this simplification comes with
	assumptions:		certain assumptions:
	* A CE device connected to EVPN multi-homing PEs MUST have a single		* A CE device connected to EVPN multihoming PEs MUST have a single
	LAG with all its links connected to the EVPN multi-homing PEs in a		LAG with all its links connected to the EVPN multihoming PEs in a
	redundancy group.		redundancy group.
	* Identical LACP parameters MUST be configured on peering PEs,		* Identical LACP parameters MUST be configured on peering PEs,
	including the system ID, port priority, and port key.		including the system ID, port priority, and port key.
	This document presumes proper LAG operation as specified in		This document presumes proper LAG operation as specified in
	[RFC7432]. Issues resulting from deviations in the aforementioned		[RFC7432]. Issues resulting from deviations in the aforementioned
	assumptions, LAG misconfiguration, and miswiring detection across		assumptions, LAG misconfiguration, and miswiring detection across
	peering PEs are considered outside the scope of this document.		peering PEs are considered outside the scope of this document.
	skipping to change at line 161 ¶		skipping to change at line 161 ¶
	I1 I2		I1 I2
	\ /		\ /
	\ /		\ /
	\ /		\ /
	+---+		+---+
	|CE1|		|CE1|
	+---+		+---+
	Figure 1: MC-LAG Topology		Figure 1: MC-LAG Topology
	Figure 1 shows an MC-LAG multi-homing topology where PE1 and PE2 are		Figure 1 shows an MC-LAG multihoming topology where PE1 and PE2 are
	part of the same redundancy group providing multi-homing to CE1 via		part of the same redundancy group providing multihoming to CE1 via
	interfaces I1 and I2. Interfaces I1 and I2 are members of a LAG		interfaces I1 and I2. Interfaces I1 and I2 are members of a LAG
	running LACP. The core, shown as IP or MPLS enabled, provides a wide		running LACP. The core, shown as IP or MPLS enabled, provides a wide
	range of L2 and L3 services. MC-LAG multi-homing functionality is		range of L2 and L3 services. MC-LAG multihoming functionality is
	decoupled from those services in the core, and it focuses on		decoupled from those services in the core, and it focuses on
	providing multi-homing to the CE. In Port-Active redundancy mode,		providing multihoming to the CE. In Port-Active redundancy mode,
	only one of the two interfaces, I1 or I2, would be in forwarding, and		only one of the two interfaces, I1 or I2, would be in forwarding, and
	the other interface would be in standby. This also implies that all		the other interface would be in standby. This also implies that all
	services on the active interface operate in active mode and all		services on the active interface operate in active mode and all
	services on the standby interface operate in standby mode.		services on the standby interface operate in standby mode.
	2. Port-Active Redundancy Mode		2. Port-Active Redundancy Mode
	2.1. Overall Advantages		2.1. Overall Advantages
	The use of Port-Active redundancy in EVPN networks provides the		The use of Port-Active redundancy in EVPN networks provides the
	skipping to change at line 230 ¶		skipping to change at line 230 ¶
	b. The Ethernet Segment (ES) MUST be configured in Port-Active		b. The Ethernet Segment (ES) MUST be configured in Port-Active
	redundancy mode on peering PEs for the specified access		redundancy mode on peering PEs for the specified access
	interface.		interface.
	c. When ESI is configured on an L3 interface, the ES route (Route		c. When ESI is configured on an L3 interface, the ES route (Route
	Type-4) can be the only route exchanged by PEs in the redundancy		Type-4) can be the only route exchanged by PEs in the redundancy
	group.		group.
	d. PEs in the redundancy group leverage the DF election defined in		d. PEs in the redundancy group leverage the DF election defined in
	[RFC8584] to determine which PE keeps the port in active mode and		[RFC8584] to determine which PE keeps the port in active mode and
	which one(s) keep it in standby mode. Although the DF election		which PE(s) keeps it in standby mode. Although the DF election
	defined in [RFC8584] is per [ES, Ethernet Tag] granularity, the		defined in [RFC8584] is per [ES, Ethernet Tag] granularity, the
	DF election is performed per [ES] in Port-Active redundancy mode.		DF election is performed per [ES] in Port-Active redundancy mode.
	The details of this algorithm are described in Section 3.		The details of this algorithm are described in Section 3.
	e. The DF router MUST keep the corresponding access interface in an		e. The DF router MUST keep the corresponding access interface in an
	up and forwarding active state for that ES.		up and forwarding active state for that ES.
	f. Non-DF routers SHOULD implement a bidirectional blocking scheme		f. Non-DF routers SHOULD implement a bidirectional blocking scheme
	for all traffic comparable to the Single-Active blocking scheme		for all traffic comparable to the Single-Active redundancy mode
	described in [RFC7432], albeit across all VLANs.		described in [RFC7432], albeit across all VLANs.
	* Non-DF routers MAY bring and keep the peering access interface		* Non-DF routers MAY bring and keep the peering access interface
	attached to them in an operational down state.		attached to them in an operational down state.
	* If the interface is running the LACP protocol, the non-DF PE		* If the interface is running the LACP protocol, the non-DF PE
	MAY set the LACP state to Out of Sync (OOS) instead of setting		MAY set the LACP state to Out of Sync (OOS) instead of setting
	the interface to a down state. This approach allows for		the interface to a down state. This approach allows for
	better convergence during the transition from standby to		better convergence during the transition from standby to
	active mode.		active mode.
	skipping to change at line 261 ¶		skipping to change at line 261 ¶
	g. The primary/backup bits of the EVPN Layer 2 Attributes (L2-Attr)		g. The primary/backup bits of the EVPN Layer 2 Attributes (L2-Attr)
	Extended Community [RFC8214] SHOULD be used to achieve better		Extended Community [RFC8214] SHOULD be used to achieve better
	convergence, as described in Section 4.1.		convergence, as described in Section 4.1.
	3. Designated Forwarder Algorithm to Elect per Port-Active PE		3. Designated Forwarder Algorithm to Elect per Port-Active PE
	The ES routes operating in Port-Active redundancy mode are advertised		The ES routes operating in Port-Active redundancy mode are advertised
	with the new Port Mode Load-Balancing capability bit in the DF		with the new Port Mode Load-Balancing capability bit in the DF
	Election Extended Community as defined in [RFC8584]. Additionally,		Election Extended Community as defined in [RFC8584]. Additionally,
	the ES associated with the port utilizes the existing Single-Active		the ES associated with the port utilizes the existing Single-Active
	procedure and signals the Single-Active multi-homed site redundancy		procedure and signals the Single-Active multihomed site redundancy
	mode along with the Ethernet A-D per-ES route (refer to Section 7.5		mode along with the Ethernet A-D per-ES route (refer to Section 7.5
	of [RFC7432]). Finally, The ESI label-based split-horizon procedures		of [RFC7432]). Finally, The ESI label-based split-horizon procedures
	specified in Section 8.3 of [RFC7432] SHOULD be employed to prevent		specified in Section 8.3 of [RFC7432] SHOULD be employed to prevent
	transient echo packets when L2 circuits are involved.		transient echo packets when L2 circuits are involved.
	Various algorithms for DF election are detailed in Sections 3.2 to		Various algorithms for DF election are detailed in Sections 3.2 to
	3.5 for comprehensive understanding, although the choice of algorithm		3.5 for comprehensive understanding, although the choice of algorithm
	in this solution does not significantly impact complexity or		in this solution does not significantly impact complexity or
	performance compared to other redundancy modes.		performance compared to other redundancy modes.
	3.1. Capability Flag		3.1. Capability Flag
	[RFC8584] defines a DF Election Extended Community and a Bitmap (2		[RFC8584] defines a DF Election Extended Community and a bitmap (2
	octets) field to encode "DF Election Capabilities" to use with the DF		octets) field to encode "DF Election Capabilities" to use with the DF
	election algorithm in the DF algorithm field:		election algorithm in the DF algorithm field:
	Bit 0: D bit or 'Don't Preempt' bit, as described in [RFC9785].		Bit 0: D bit or 'Don't Preempt' bit, as described in [RFC9785].
	Bit 1: AC-Influenced DF (AC-DF) election, as described in		Bit 1: AC-Influenced DF (AC-DF) election, as described in
	[RFC8584].		[RFC8584].
			Bit 3: Time Synchronization, as described in [RFC9722].
	1 1 1 1 1 1		1 1 1 1 1 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|D|A| |P| |		|D|A| |T| |P| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Amended DF Election Capabilities in the DF Election		Figure 2: Amended DF Election Capabilities in the DF Election
	Extended Community		Extended Community
	This document defines the following value and extends the DF Election		This document defines the following value and extends the DF Election
	Capabilities bitmap field:		Capabilities bitmap field:
	Bit 5: Port Mode Designated Forwarder Election. This bit		Bit 5: Port Mode Designated Forwarder Election. This bit
	determines that the DF election algorithm SHOULD be		determines that the DF election algorithm SHOULD be
	skipping to change at line 329 ¶		skipping to change at line 331 ¶
	defined in [RFC8584], and it MAY be used and signaled. For Port-		defined in [RFC8584], and it MAY be used and signaled. For Port-
	Active, this is modified to operate at the granularity of <ES> rather		Active, this is modified to operate at the granularity of <ES> rather
	than per <ES, VLAN>.		than per <ES, VLAN>.
	Section 3.2 of [RFC8584] describes computing a 32-bit Cyclic		Section 3.2 of [RFC8584] describes computing a 32-bit Cyclic
	Redundancy Check (CRC) over the concatenation of Ethernet Tag (V) and		Redundancy Check (CRC) over the concatenation of Ethernet Tag (V) and
	ESI (Es). For Port-Active redundancy mode, the Ethernet Tag is		ESI (Es). For Port-Active redundancy mode, the Ethernet Tag is
	omitted from the CRC computation and all references to (V, Es) are		omitted from the CRC computation and all references to (V, Es) are
	replaced by (Es).		replaced by (Es).
	The algorithm to determine the DF Elected and Backup-DF Elected (BDF)		The algorithm used to determine the DF and Backup Designated
	at Section 3.2 of [RFC8584] is repeated and summarized below using		Forwarder (BDF) per Section 3.2 of [RFC8584] is repeated and
	only (Es) in the computation:		summarized below using only (Es) in the computation:
	1. DF(Es) = Si| Weight(Es, Si) >= Weight(Es, Sj), for all j. In the		1. DF(Es) = Si| Weight(Es, Si) >= Weight(Es, Sj), for all j. In the
	case of a tie, choose the PE whose IP address is numerically the		case of a tie, choose the PE whose IP address is numerically the
	least. Note that 0 <= i,j < number of PEs in the redundancy		least. Note that 0 <= i,j < number of PEs in the redundancy
	group.		group.
	2. BDF(Es) = Sk| Weight(Es, Si) >= Weight(Es, Sk), and Weight(Es,		2. BDF(Es) = Sk| Weight(Es, Si) >= Weight(Es, Sk), and Weight(Es,
	Sk) >= Weight(Es, Sj). In the case of a tie, choose the PE whose		Sk) >= Weight(Es, Sj). In the case of a tie, choose the PE whose
	IP address is numerically the least.		IP address is numerically the least.
	skipping to change at line 431 ¶		skipping to change at line 433 ¶
	Implementations that comply with [RFC7432] or [RFC8214] only (i.e.,		Implementations that comply with [RFC7432] or [RFC8214] only (i.e.,
	implementations that predate this specification) and that receive an		implementations that predate this specification) and that receive an
	L2-Attr Extended Community in Ethernet A-D per ES routes will ignore		L2-Attr Extended Community in Ethernet A-D per ES routes will ignore
	it and continue to use the default path resolution algorithms of the		it and continue to use the default path resolution algorithms of the
	two specifications above:		two specifications above:
	* The L2-Attr Extended Community in Ethernet A-D per ES route is		* The L2-Attr Extended Community in Ethernet A-D per ES route is
	ignored.		ignored.
	* The remote ESI label extended community [RFC7432] signals Single-		* The remote ESI Label Extended Community [RFC7432] signals the
	Active (Section 3).		Single-Active redundancy mode (Section 3).
	* The remote Media Access Control (MAC) and/or Ethernet A-D per EVI		* The remote Media Access Control (MAC) and/or Ethernet A-D per EVI
	routes are unchanged; the P and B bits in the L2-Attr Extended		routes are unchanged; the P and B bits in the L2-Attr Extended
	Community in Ethernet A-D per EVI routes are used.		Community in Ethernet A-D per EVI routes are used.
	5. Applicability		5. Applicability
	A prevalent deployment scenario involves providing L2 or L3 services		A prevalent deployment scenario involves providing L2 or L3 services
	on PE devices that offer multi-homing capabilities. The services may		on PE devices that offer multihoming capabilities. The services may
	include any L2 EVPN solutions such as EVPN Virtual Private Wire		include any L2 EVPN solutions such as EVPN Virtual Private Wire
	Service (VPWS) or standard EVPN as defined in [RFC7432].		Service (VPWS) or standard EVPN as defined in [RFC7432].
	Additionally, L3 services may be provided within a VPN context, as		Additionally, L3 services may be provided within a VPN context, as
	specified in [RFC4364], or within a global routing context. When a		specified in [RFC4364], or within a global routing context. When a
	PE provides first-hop routing, EVPN IRB may also be deployed on the		PE provides first-hop routing, EVPN IRB may also be deployed on the
	PEs. The mechanism outlined in this document applies to PEs		PEs. The mechanism outlined in this document applies to PEs
	providing L2 and/or L3 services where active/standby redundancy at		providing L2 and/or L3 services where active/standby redundancy at
	the interface level is required.		the interface level is required.
	An alternative solution to the one described in this document is MC-		An alternative solution to the one described in this document is MC-
	skipping to change at line 486 ¶		skipping to change at line 488 ¶
	applicable to this document.		applicable to this document.
	Introducing a new capability necessitates unanimity among PEs.		Introducing a new capability necessitates unanimity among PEs.
	Without consensus on the new DF election procedures and Port Mode,		Without consensus on the new DF election procedures and Port Mode,
	the DF election algorithm defaults to the procedures outlined in		the DF election algorithm defaults to the procedures outlined in
	[RFC8584] and [RFC7432].This fallback behavior could be exploited by		[RFC8584] and [RFC7432].This fallback behavior could be exploited by
	an attacker who modifies the configuration of one PE within the ES.		an attacker who modifies the configuration of one PE within the ES.
	Such manipulation could force all PEs in the ES to revert to the		Such manipulation could force all PEs in the ES to revert to the
	default DF election algorithm and capabilities. In this scenario,		default DF election algorithm and capabilities. In this scenario,
	the PEs may be subject to unfair load balancing, service disruption,		the PEs may be subject to unfair load balancing, service disruption,
	and potential issues such as black-holing or duplicate traffic, as		and potential issues such as traffic loss or duplicate traffic, as
	mentioned in the security sections of those documents.		mentioned in the security sections of those documents.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[IEEE_802.1AX_2014]		[IEEE_802.1AX_2014]
	IEEE, "IEEE Standard for Local and metropolitan area		IEEE, "IEEE Standard for Local and metropolitan area
	networks -- Link Aggregation", IEEE 802-1ax-2014,		networks -- Link Aggregation", IEEE 802-1ax-2014,
	DOI 10.1109/IEEESTD.2014.7055197, 5 March 2015,		DOI 10.1109/IEEESTD.2014.7055197, 5 March 2015,
	skipping to change at line 524 ¶		skipping to change at line 526 ¶
	Rabadan, "Virtual Private Wire Service Support in Ethernet		Rabadan, "Virtual Private Wire Service Support in Ethernet
	VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,		VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
	<https://www.rfc-editor.org/info/rfc8214>.		<https://www.rfc-editor.org/info/rfc8214>.
	[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,		[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
	J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet		J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
	VPN Designated Forwarder Election Extensibility",		VPN Designated Forwarder Election Extensibility",
	RFC 8584, DOI 10.17487/RFC8584, April 2019,		RFC 8584, DOI 10.17487/RFC8584, April 2019,
	<https://www.rfc-editor.org/info/rfc8584>.		<https://www.rfc-editor.org/info/rfc8584>.
			[RFC9722] Brissette, P., Sajassi, A., Burdet, LA., Ed., Drake, J.,
			and J. Rabadan, "Fast Recovery for EVPN Designated
			Forwarder Election", RFC RFC9722, May 2025,
			<https://www.rfc-editor.org/info/rfc9722>.
	[RFC9785] Rabadan, J., Ed., Sathappan, S., Lin, W., Drake, J., and		[RFC9785] Rabadan, J., Ed., Sathappan, S., Lin, W., Drake, J., and
	A. Sajassi, "Preference-Based EVPN Designated Forwarder		A. Sajassi, "Preference-Based EVPN Designated Forwarder
	(DF) Election", RFC RFC9785, DOI 10.17487/RFC9785, May		(DF) Election", RFC RFC9785, DOI 10.17487/RFC9785, May
	2025, <https://www.rfc-editor.org/info/rfc9785>.		2025, <https://www.rfc-editor.org/info/rfc9785>.
	8.2. Informative References		8.2. Informative References
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February		Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
	2006, <https://www.rfc-editor.org/info/rfc4364>.		2006, <https://www.rfc-editor.org/info/rfc4364>.
End of changes. 23 change blocks.
	33 lines changed or deleted		40 lines changed or added
This html diff was produced by rfcdiff 1.48.