rfc9136v3.txt		rfc9136.txt
	skipping to change at line 443 ¶		skipping to change at line 443 ¶
	The following sections describe how EVPN is extended with a route		The following sections describe how EVPN is extended with a route
	type for the advertisement of IP prefixes and how this route is used		type for the advertisement of IP prefixes and how this route is used
	to address the inter-subnet connectivity requirements existing in the		to address the inter-subnet connectivity requirements existing in the
	DC.		DC.
	3. The BGP EVPN IP Prefix Route		3. The BGP EVPN IP Prefix Route
	The BGP EVPN NLRI as defined in [RFC7432] is shown below:		The BGP EVPN NLRI as defined in [RFC7432] is shown below:
	+--------------------------------+		+-----------------------------------+
	| Route Type (1 octet) |		| Route Type (1 octet) |
	+--------------------------------+		+-----------------------------------+
	| Length (1 octet) |		| Length (1 octet) |
	+--------------------------------+		+-----------------------------------+
	| Route Type specific (variable) |		| Route Type specific (variable) |
	+--------------------------------+		+-----------------------------------+
	Table 1: BGP EVPN NLRI		Figure 2: BGP EVPN NLRI
	This document defines an additional route type (RT-5) in the IANA		This document defines an additional route type (RT-5) in the IANA
	"EVPN Route Types" registry [EVPNRouteTypes] to be used for the		"EVPN Route Types" registry [EVPNRouteTypes] to be used for the
	advertisement of EVPN routes using IP prefixes:		advertisement of EVPN routes using IP prefixes:
	Value: 5		Value: 5
	Description: IP Prefix		Description: IP Prefix
	According to Section 5.4 of [RFC7606], a node that doesn't recognize		According to Section 5.4 of [RFC7606], a node that doesn't recognize
	the route type 5 (RT-5) will ignore it. Therefore, an NVE following		the route type 5 (RT-5) will ignore it. Therefore, an NVE following
	skipping to change at line 476 ¶		skipping to change at line 476 ¶
	RT-5 for the proper inter-subnet forwarding operation of the tenant.		RT-5 for the proper inter-subnet forwarding operation of the tenant.
	The detailed encoding of this route and associated procedures are		The detailed encoding of this route and associated procedures are
	described in the following sections.		described in the following sections.
	3.1. IP Prefix Route Encoding		3.1. IP Prefix Route Encoding
	An IP Prefix route type for IPv4 has the Length field set to 34 and		An IP Prefix route type for IPv4 has the Length field set to 34 and
	consists of the following fields:		consists of the following fields:
	+-----------------------------------------+		+---------------------------------------+
	| RD (8 octets) |		| RD (8 octets) |
	+-----------------------------------------+		+---------------------------------------+
	| Ethernet Segment Identifier (10 octets) |		|Ethernet Segment Identifier (10 octets)|
	+-----------------------------------------+		+---------------------------------------+
	| Ethernet Tag ID (4 octets) |		| Ethernet Tag ID (4 octets) |
	+-----------------------------------------+		+---------------------------------------+
	| IP Prefix Length (1 octet, 0 to 32) |		| IP Prefix Length (1 octet, 0 to 32) |
	+-----------------------------------------+		+---------------------------------------+
	| IP Prefix (4 octets) |		| IP Prefix (4 octets) |
	+-----------------------------------------+		+---------------------------------------+
	| GW IP Address (4 octets) |		| GW IP Address (4 octets) |
	+-----------------------------------------+		+---------------------------------------+
	| MPLS Label (3 octets) |		| MPLS Label (3 octets) |
	+-----------------------------------------+		+---------------------------------------+
	Table 2: EVPN IP Prefix Route NLRI for IPv4		Figure 3: EVPN IP Prefix Route NLRI for IPv4
	An IP Prefix route type for IPv6 has the Length field set to 58 and		An IP Prefix route type for IPv6 has the Length field set to 58 and
	consists of the following fields:		consists of the following fields:
	+-----------------------------------------+		+---------------------------------------+
	| RD (8 octets) |		| RD (8 octets) |
	+-----------------------------------------+		+---------------------------------------+
	| Ethernet Segment Identifier (10 octets) |		|Ethernet Segment Identifier (10 octets)|
	+-----------------------------------------+		+---------------------------------------+
	| Ethernet Tag ID (4 octets) |		| Ethernet Tag ID (4 octets) |
	+-----------------------------------------+		+---------------------------------------+
	| IP Prefix Length (1 octet, 0 to 128) |		| IP Prefix Length (1 octet, 0 to 128) |
	+-----------------------------------------+		+---------------------------------------+
	| IP Prefix (16 octets) |		| IP Prefix (16 octets) |
	+-----------------------------------------+		+---------------------------------------+
	| GW IP Address (16 octets) |		| GW IP Address (16 octets) |
	+-----------------------------------------+		+---------------------------------------+
	| MPLS Label (3 octets) |		| MPLS Label (3 octets) |
	+-----------------------------------------+		+---------------------------------------+
	Table 3: EVPN IP Prefix Route NLRI for IPv6		Figure 4: EVPN IP Prefix Route NLRI for IPv6
	Where:		Where:
	* The Length field of the BGP EVPN NLRI for an EVPN IP Prefix route		* The Length field of the BGP EVPN NLRI for an EVPN IP Prefix route
	MUST be either 34 (if IPv4 addresses are carried) or 58 (if IPv6		MUST be either 34 (if IPv4 addresses are carried) or 58 (if IPv6
	addresses are carried). The IP prefix and gateway IP address MUST		addresses are carried). The IP prefix and gateway IP address MUST
	be from the same IP address family.		be from the same IP address family.
	* The Route Distinguisher (RD) and Ethernet Tag ID MUST be used as		* The Route Distinguisher (RD) and Ethernet Tag ID MUST be used as
	defined in [RFC7432] and [RFC8365]. In particular, the RD is		defined in [RFC7432] and [RFC8365]. In particular, the RD is
	skipping to change at line 644 ¶		skipping to change at line 644 ¶
	Router's MAC Extended Community is ignored if present.		Router's MAC Extended Community is ignored if present.
	* A route where ESI, GW IP, MAC, and Label are all zero at the same		* A route where ESI, GW IP, MAC, and Label are all zero at the same
	time SHOULD be treat as withdraw.		time SHOULD be treat as withdraw.
	The indirection provided by the Overlay Index and its recursive		The indirection provided by the Overlay Index and its recursive
	lookup resolution is required to achieve fast convergence in case of		lookup resolution is required to achieve fast convergence in case of
	a failure of the object represented by the Overlay Index (see the		a failure of the object represented by the Overlay Index (see the
	example described in Section 2.2).		example described in Section 2.2).
	Table 4 shows the different RT-5 field combinations allowed by this		Table 1 shows the different RT-5 field combinations allowed by this
	specification and what Overlay Index must be used by the receiving		specification and what Overlay Index must be used by the receiving
	NVE/PE in each case. Cases where there is no Overlay Index are		NVE/PE in each case. Cases where there is no Overlay Index are
	indicated as "None" in Table 4. If there is no Overlay Index, the		indicated as "None" in Table 1. If there is no Overlay Index, the
	receiving NVE/PE will not perform any recursive resolution, and the		receiving NVE/PE will not perform any recursive resolution, and the
	actual next hop is given by the RT-5's BGP next hop.		actual next hop is given by the RT-5's BGP next hop.
	+==========+==========+==========+============+===============+		+==========+==========+==========+============+===============+
	| ESI | GW IP | MAC* | Label | Overlay Index |		| ESI | GW IP | MAC* | Label | Overlay Index |
	+==========+==========+==========+============+===============+		+==========+==========+==========+============+===============+
	| Non-Zero | Zero | Zero | Don't Care | ESI |		| Non-Zero | Zero | Zero | Don't Care | ESI |
	+----------+----------+----------+------------+---------------+		+----------+----------+----------+------------+---------------+
	| Non-Zero | Zero | Non-Zero | Don't Care | ESI |		| Non-Zero | Zero | Non-Zero | Don't Care | ESI |
	+----------+----------+----------+------------+---------------+		+----------+----------+----------+------------+---------------+
	| Zero | Non-Zero | Zero | Don't Care | GW IP |		| Zero | Non-Zero | Zero | Don't Care | GW IP |
	+----------+----------+----------+------------+---------------+		+----------+----------+----------+------------+---------------+
	| Zero | Zero | Non-Zero | Zero | MAC |		| Zero | Zero | Non-Zero | Zero | MAC |
	+----------+----------+----------+------------+---------------+		+----------+----------+----------+------------+---------------+
	| Zero | Zero | Non-Zero | Non-Zero | MAC or None** |		| Zero | Zero | Non-Zero | Non-Zero | MAC or None** |
	+----------+----------+----------+------------+---------------+		+----------+----------+----------+------------+---------------+
	| Zero | Zero | Zero | Non-Zero | None*** |		| Zero | Zero | Zero | Non-Zero | None*** |
	+----------+----------+----------+------------+---------------+		+----------+----------+----------+------------+---------------+
	Table 4: RT-5 Fields and Indicated Overlay Index		Table 1: RT-5 Fields and Indicated Overlay Index
	Table Notes:		Table Notes:
	* MAC with "Zero" value means no EVPN Router's MAC Extended		* MAC with "Zero" value means no EVPN Router's MAC Extended
	Community is present along with the RT-5. "Non-Zero" indicates		Community is present along with the RT-5. "Non-Zero" indicates
	that the extended community is present and carries a valid MAC		that the extended community is present and carries a valid MAC
	address. The encoding of a MAC address MUST be the 6-octet MAC		address. The encoding of a MAC address MUST be the 6-octet MAC
	address specified by [IEEE-802.1Q]. Examples of invalid MAC		address specified by [IEEE-802.1Q]. Examples of invalid MAC
	addresses are broadcast or multicast MAC addresses. The route		addresses are broadcast or multicast MAC addresses. The route
	MUST be treat as withdraw in case of an invalid MAC address.		MUST be treat as withdraw in case of an invalid MAC address.
	The presence of the EVPN Router's MAC Extended Community alone		The presence of the EVPN Router's MAC Extended Community alone
	is not enough to indicate the use of the MAC address as the		is not enough to indicate the use of the MAC address as the
	Overlay Index since the extended community can be used for		Overlay Index since the extended community can be used for
	other purposes.		other purposes.
	** In this case, the Overlay Index may be the RT-5's MAC address		** In this case, the Overlay Index may be the RT-5's MAC address
	or "None", depending on the local policy of the receiving NVE/		or "None", depending on the local policy of the receiving NVE/
	PE. Note that the advertising NVE/PE that sets the Overlay		PE. Note that the advertising NVE/PE that sets the Overlay
	Index SHOULD advertise an RT-2 for the MAC Overlay Index if		Index SHOULD advertise an RT-2 for the MAC Overlay Index if
	there are receiving NVE/PEs configured to use the MAC as the		there are receiving NVE/PEs configured to use the MAC as the
	Overlay Index. This case in Table 4 is used in the IP-VRF-to-		Overlay Index. This case in Table 1 is used in the IP-VRF-to-
	IP-VRF implementations described in Sections 4.4.1 and 4.4.3.		IP-VRF implementations described in Sections 4.4.1 and 4.4.3.
	The support of a MAC Overlay Index in this model is OPTIONAL.		The support of a MAC Overlay Index in this model is OPTIONAL.
	*** The Overlay Index is "None". This is a special case used for		*** The Overlay Index is "None". This is a special case used for
	IP-VRF-to-IP-VRF where the NVE/PEs are connected by IP NVO		IP-VRF-to-IP-VRF where the NVE/PEs are connected by IP NVO
	tunnels as opposed to Ethernet NVO tunnels.		tunnels as opposed to Ethernet NVO tunnels.
	If the combination of ESI, GW IP, MAC, and Label in the receiving		If the combination of ESI, GW IP, MAC, and Label in the receiving
	RT-5 is different than the combinations shown in Table 4, the router		RT-5 is different than the combinations shown in Table 1, the router
	will process the route as per the rules described at the beginning of		will process the route as per the rules described at the beginning of
	this section (Section 3.2).		this section (Section 3.2).
	Table 5 shows the different inter-subnet use cases described in this		Table 2 shows the different inter-subnet use cases described in this
	document and the corresponding coding of the Overlay Index in the		document and the corresponding coding of the Overlay Index in the
	route type 5 (RT-5).		route type 5 (RT-5).
	+=========+=====================+===========================+		+=========+=====================+===========================+
	| Section | Use Case | Overlay Index in the RT-5 |		| Section | Use Case | Overlay Index in the RT-5 |
	+=========+=====================+===========================+		+=========+=====================+===========================+
	| 4.1 | TS IP address | GW IP |		| 4.1 | TS IP address | GW IP |
	+---------+---------------------+---------------------------+		+---------+---------------------+---------------------------+
	| 4.2 | Floating IP address | GW IP |		| 4.2 | Floating IP address | GW IP |
	+---------+---------------------+---------------------------+		+---------+---------------------+---------------------------+
	| 4.3 | "Bump-in-the-wire" | ESI or MAC |		| 4.3 | "Bump-in-the-wire" | ESI or MAC |
	+---------+---------------------+---------------------------+		+---------+---------------------+---------------------------+
	| 4.4 | IP-VRF-to-IP-VRF | GW IP, MAC, or None |		| 4.4 | IP-VRF-to-IP-VRF | GW IP, MAC, or None |
	+---------+---------------------+---------------------------+		+---------+---------------------+---------------------------+
	Table 5: Use Cases and Overlay Indexes for Recursive		Table 2: Use Cases and Overlay Indexes for Recursive
	Resolution		Resolution
	The above use cases are representative of the different Overlay		The above use cases are representative of the different Overlay
	Indexes supported by the RT-5 (GW IP, ESI, MAC, or None).		Indexes supported by the RT-5 (GW IP, ESI, MAC, or None).
	4. Overlay Index Use Cases		4. Overlay Index Use Cases
	This section describes some use cases for the Overlay Index types		This section describes some use cases for the Overlay Index types
	used with the IP Prefix route. Although the examples use IPv4		used with the IP Prefix route. Although the examples use IPv4
	prefixes and subnets, the descriptions of the RT-5 are valid for the		prefixes and subnets, the descriptions of the RT-5 are valid for the
	same cases with IPv6, except that IP Prefixes, IPL, and GW IP are		same cases with IPv6, except that IP Prefixes, IPL, and GW IP are
	replaced by the corresponding IPv6 values.		replaced by the corresponding IPv6 values.
	4.1. TS IP Address Overlay Index Use Case		4.1. TS IP Address Overlay Index Use Case
	Figure 2 illustrates an example of inter-subnet forwarding for		Figure 5 illustrates an example of inter-subnet forwarding for
	subnets sitting behind VAs (on TS2 and TS3).		subnets sitting behind VAs (on TS2 and TS3).
	IP4---+ NVE2 DGW1		IP4---+ NVE2 DGW1
	| +-----------+ +---------+ +-------------+		| +-----------+ +---------+ +-------------+
	SN2---TS2(VA)--| (BD-10) |-| |----| (BD-10) |		SN2---TS2(VA)--| (BD-10) |-| |----| (BD-10) |
	| M2/IP2 +-----------+ | | | IRB1\ |		| M2/IP2 +-----------+ | | | IRB1\ |
	-+---+ | | | (IP-VRF)|---+		-+---+ | | | (IP-VRF)|---+
	| | | +-------------+ _|_		| | | +-------------+ _|_
	SN1 | VXLAN/ | ( )		SN1 | VXLAN/ | ( )
	| | GENEVE | DGW2 ( WAN )		| | GENEVE | DGW2 ( WAN )
	-+---+ NVE3 | | +-------------+ (___)		-+---+ NVE3 | | +-------------+ (___)
	| M3/IP3 +-----------+ | |----| (BD-10) | |		| M3/IP3 +-----------+ | |----| (BD-10) | |
	SN3---TS3(VA)--| (BD-10) |-| | | IRB2\ | |		SN3---TS3(VA)--| (BD-10) |-| | | IRB2\ | |
	| +-----------+ +---------+ | (IP-VRF)|---+		| +-----------+ +---------+ | (IP-VRF)|---+
	IP5---+ +-------------+		IP5---+ +-------------+
	Figure 2: TS IP Address Use Case		Figure 5: TS IP Address Use Case
	An example of inter-subnet forwarding between subnet SN1, which uses		An example of inter-subnet forwarding between subnet SN1, which uses
	a 24-bit IP prefix (written as SN1/24 in the future), and a subnet		a 24-bit IP prefix (written as SN1/24 in the future), and a subnet
	sitting in the WAN is described below. NVE2, NVE3, DGW1, and DGW2		sitting in the WAN is described below. NVE2, NVE3, DGW1, and DGW2
	are running BGP EVPN. TS2 and TS3 do not participate in dynamic		are running BGP EVPN. TS2 and TS3 do not participate in dynamic
	routing protocols, and they only have a static route to forward the		routing protocols, and they only have a static route to forward the
	traffic to the WAN. SN1/24 is dual-homed to NVE2 and NVE3.		traffic to the WAN. SN1/24 is dual-homed to NVE2 and NVE3.
	In this case, a GW IP is used as an Overlay Index. Although a		In this case, a GW IP is used as an Overlay Index. Although a
	different Overlay Index type could have been used, this use case		different Overlay Index type could have been used, this use case
	skipping to change at line 858 ¶		skipping to change at line 858 ¶
	Note that in the opposite direction, TS2 will send traffic based on		Note that in the opposite direction, TS2 will send traffic based on
	its static-route next-hop information (IRB1 and/or IRB2), and regular		its static-route next-hop information (IRB1 and/or IRB2), and regular
	EVPN procedures will be applied.		EVPN procedures will be applied.
	4.2. Floating IP Overlay Index Use Case		4.2. Floating IP Overlay Index Use Case
	Sometimes TSs work in active/standby mode where an upstream floating		Sometimes TSs work in active/standby mode where an upstream floating
	IP owned by the active TS is used as the Overlay Index to get to some		IP owned by the active TS is used as the Overlay Index to get to some
	subnets behind the TS. This redundancy mode, already introduced in		subnets behind the TS. This redundancy mode, already introduced in
	Sections 2.1 and 2.2, is illustrated in Figure 3.		Sections 2.1 and 2.2, is illustrated in Figure 6.
	NVE2 DGW1		NVE2 DGW1
	+-----------+ +---------+ +-------------+		+-----------+ +---------+ +-------------+
	+---TS2(VA)--| (BD-10) |-| |----| (BD-10) |		+---TS2(VA)--| (BD-10) |-| |----| (BD-10) |
	| M2/IP2 +-----------+ | | | IRB1\ |		| M2/IP2 +-----------+ | | | IRB1\ |
	| <-+ | | | (IP-VRF)|---+		| <-+ | | | (IP-VRF)|---+
	| | | | +-------------+ _|_		| | | | +-------------+ _|_
	SN1 vIP23 (floating) | VXLAN/ | ( )		SN1 vIP23 (floating) | VXLAN/ | ( )
	| | | GENEVE | DGW2 ( WAN )		| | | GENEVE | DGW2 ( WAN )
	| <-+ NVE3 | | +-------------+ (___)		| <-+ NVE3 | | +-------------+ (___)
	| M3/IP3 +-----------+ | |----| (BD-10) | |		| M3/IP3 +-----------+ | |----| (BD-10) | |
	+---TS3(VA)--| (BD-10) |-| | | IRB2\ | |		+---TS3(VA)--| (BD-10) |-| | | IRB2\ | |
	+-----------+ +---------+ | (IP-VRF)|---+		+-----------+ +---------+ | (IP-VRF)|---+
	+-------------+		+-------------+
	Figure 3: Floating IP Overlay Index for Redundant TS		Figure 6: Floating IP Overlay Index for Redundant TS
	In this use case, a GW IP is used as an Overlay Index for the same		In this use case, a GW IP is used as an Overlay Index for the same
	reasons as in Section 4.1. However, this GW IP is a floating IP that		reasons as in Section 4.1. However, this GW IP is a floating IP that
	belongs to the active TS. Assuming TS2 is the active TS and owns		belongs to the active TS. Assuming TS2 is the active TS and owns
	vIP23:		vIP23:
	(1) NVE2 advertises the following BGP routes for TS2:		(1) NVE2 advertises the following BGP routes for TS2:
	* Route type 2 (MAC/IP Advertisement route) containing: ML =		* Route type 2 (MAC/IP Advertisement route) containing: ML =
	48, M = M2, IPL = 32, and IP = vIP23 (as well as BGP		48, M = M2, IPL = 32, and IP = vIP23 (as well as BGP
	skipping to change at line 952 ¶		skipping to change at line 952 ¶
	floating vIP23 and will signal this new ownership using a		floating vIP23 and will signal this new ownership using a
	gratuitous ARP REPLY message (explained in [RFC5227]) or		gratuitous ARP REPLY message (explained in [RFC5227]) or
	similar. Upon receiving the new owner's notification, NVE3 will		similar. Upon receiving the new owner's notification, NVE3 will
	issue a route type 2 for M3/vIP23, and NVE2 will withdraw the		issue a route type 2 for M3/vIP23, and NVE2 will withdraw the
	RT-2 for M2/vIP23. DGW1 and DGW2 will update their ARP tables		RT-2 for M2/vIP23. DGW1 and DGW2 will update their ARP tables
	with the new MAC resolving the floating IP. No changes are made		with the new MAC resolving the floating IP. No changes are made
	in the IP-VRF table.		in the IP-VRF table.
	4.3. Bump-in-the-Wire Use Case		4.3. Bump-in-the-Wire Use Case
	Figure 4 illustrates an example of inter-subnet forwarding for an IP		Figure 7 illustrates an example of inter-subnet forwarding for an IP
	Prefix route that carries subnet SN1. In this use case, TS2 and TS3		Prefix route that carries subnet SN1. In this use case, TS2 and TS3
	are Layer 2 VA devices without any IP addresses that can be included		are Layer 2 VA devices without any IP addresses that can be included
	as an Overlay Index in the GW IP field of the IP Prefix route. Their		as an Overlay Index in the GW IP field of the IP Prefix route. Their
	MAC addresses are M2 and M3, respectively, and are connected to BD-		MAC addresses are M2 and M3, respectively, and are connected to BD-
	10. Note that IRB1 and IRB2 (in DGW1 and DGW2, respectively) have IP		10. Note that IRB1 and IRB2 (in DGW1 and DGW2, respectively) have IP
	addresses in a subnet different than SN1.		addresses in a subnet different than SN1.
	NVE2 DGW1		NVE2 DGW1
	M2 +-----------+ +---------+ +-------------+		M2 +-----------+ +---------+ +-------------+
	+---TS2(VA)--| (BD-10) |-| |----| (BD-10) |		+---TS2(VA)--| (BD-10) |-| |----| (BD-10) |
	skipping to change at line 974 ¶		skipping to change at line 974 ¶
	| + | | | (IP-VRF)|---+		| + | | | (IP-VRF)|---+
	| | | | +-------------+ _|_		| | | | +-------------+ _|_
	SN1 | | VXLAN/ | ( )		SN1 | | VXLAN/ | ( )
	| | | GENEVE | DGW2 ( WAN )		| | | GENEVE | DGW2 ( WAN )
	| + NVE3 | | +-------------+ (___)		| + NVE3 | | +-------------+ (___)
	| ESI23 +-----------+ | |----| (BD-10) | |		| ESI23 +-----------+ | |----| (BD-10) | |
	+---TS3(VA)--| (BD-10) |-| | | IRB2\ | |		+---TS3(VA)--| (BD-10) |-| | | IRB2\ | |
	M3 +-----------+ +---------+ | (IP-VRF)|---+		M3 +-----------+ +---------+ | (IP-VRF)|---+
	+-------------+		+-------------+
	Figure 4: Bump-in-the-Wire Use Case		Figure 7: Bump-in-the-Wire Use Case
	Since TS2 and TS3 cannot participate in any dynamic routing protocol		Since TS2 and TS3 cannot participate in any dynamic routing protocol
	and neither has an IP address assigned, there are two potential		and neither has an IP address assigned, there are two potential
	Overlay Index types that can be used when advertising SN1:		Overlay Index types that can be used when advertising SN1:
	a) an ESI, i.e., ESI23, that can be provisioned on the attachment		a) an ESI, i.e., ESI23, that can be provisioned on the attachment
	ports of NVE2 and NVE3, as shown in Figure 4 or		ports of NVE2 and NVE3, as shown in Figure 7 or
	b) the VA's MAC address, which can be added to NVE2 and NVE3 by		b) the VA's MAC address, which can be added to NVE2 and NVE3 by
	policy.		policy.
	The advantage of using an ESI as the Overlay Index as opposed to the		The advantage of using an ESI as the Overlay Index as opposed to the
	VA's MAC address is that the forwarding to the egress NVE can be done		VA's MAC address is that the forwarding to the egress NVE can be done
	purely based on the state of the AC in the Ethernet segment (notified		purely based on the state of the AC in the Ethernet segment (notified
	by the Ethernet A-D per EVI route), and all the EVPN multihoming		by the Ethernet A-D per EVI route), and all the EVPN multihoming
	redundancy mechanisms can be reused. For instance, the mass		redundancy mechanisms can be reused. For instance, the mass
	withdrawal mechanism described in [RFC7432] for fast failure		withdrawal mechanism described in [RFC7432] for fast failure
	skipping to change at line 1147 ¶		skipping to change at line 1147 ¶
	2. Interface-ful with an SBD IRB model: requires SBD as well as GW		2. Interface-ful with an SBD IRB model: requires SBD as well as GW
	IP addresses as Overlay Indexes.		IP addresses as Overlay Indexes.
	3. Interface-ful with an unnumbered SBD IRB model: requires SBD as		3. Interface-ful with an unnumbered SBD IRB model: requires SBD as
	well as MAC addresses as Overlay Indexes.		well as MAC addresses as Overlay Indexes.
	Inter-subnet IP multicast is outside the scope of this document.		Inter-subnet IP multicast is outside the scope of this document.
	4.4.1. Interface-less IP-VRF-to-IP-VRF Model		4.4.1. Interface-less IP-VRF-to-IP-VRF Model
	Figure 5 depicts the Interface-less IP-VRF-to-IP-VRF model.		Figure 8 depicts the Interface-less IP-VRF-to-IP-VRF model.
	NVE1(M1)		NVE1(M1)
	+------------+		+------------+
	IP1+----| (BD-1) | DGW1(M3)		IP1+----| (BD-1) | DGW1(M3)
	| \ | +---------+ +--------+		| \ | +---------+ +--------+
	| (IP-VRF)|----| |-|(IP-VRF)|----+		| (IP-VRF)|----| |-|(IP-VRF)|----+
	| / | | | +--------+ |		| / | | | +--------+ |
	+---| (BD-2) | | | _+_		+---| (BD-2) | | | _+_
	| +------------+ | | ( )		| +------------+ | | ( )
	SN1| | VXLAN/ | ( WAN )--H1		SN1| | VXLAN/ | ( WAN )--H1
	| NVE2(M2) | GENEVE/| (___)		| NVE2(M2) | GENEVE/| (___)
	| +------------+ | MPLS | +		| +------------+ | MPLS | +
	+---| (BD-2) | | | DGW2(M4) |		+---| (BD-2) | | | DGW2(M4) |
	| \ | | | +--------+ |		| \ | | | +--------+ |
	| (IP-VRF)|----| |-|(IP-VRF)|----+		| (IP-VRF)|----| |-|(IP-VRF)|----+
	| / | +---------+ +--------+		| / | +---------+ +--------+
	SN2+----| (BD-3) |		SN2+----| (BD-3) |
	+------------+		+------------+
	Figure 5: Interface-less IP-VRF-to-IP-VRF Model		Figure 8: Interface-less IP-VRF-to-IP-VRF Model
	In this case:		In this case:
	a) The NVEs and DGWs must provide connectivity between hosts in SN1,		a) The NVEs and DGWs must provide connectivity between hosts in SN1,
	SN2, and IP1 and hosts sitting at the other end of the WAN -- for		SN2, and IP1 and hosts sitting at the other end of the WAN -- for
	example, H1. It is assumed that the DGWs import/export IP and/or		example, H1. It is assumed that the DGWs import/export IP and/or
	VPN-IP routes to/from the WAN.		VPN-IP routes to/from the WAN.
	b) The IP-VRF instances in the NVE/DGWs are directly connected		b) The IP-VRF instances in the NVE/DGWs are directly connected
	through NVO tunnels, and no IRBs and/or BD instances are		through NVO tunnels, and no IRBs and/or BD instances are
	skipping to change at line 1285 ¶		skipping to change at line 1285 ¶
	subsequent lookup in the ARP table and the BD FIB will		subsequent lookup in the ARP table and the BD FIB will
	provide the forwarding information for the packet in BD-2.		provide the forwarding information for the packet in BD-2.
	The model described above is called an "interface-less" model since		The model described above is called an "interface-less" model since
	the IP-VRFs are connected directly through tunnels, and they don't		the IP-VRFs are connected directly through tunnels, and they don't
	require those tunnels to be terminated in SBDs instead, as in		require those tunnels to be terminated in SBDs instead, as in
	Sections 4.4.2 or 4.4.3.		Sections 4.4.2 or 4.4.3.
	4.4.2. Interface-ful IP-VRF-to-IP-VRF with SBD IRB		4.4.2. Interface-ful IP-VRF-to-IP-VRF with SBD IRB
	Figure 6 depicts the Interface-ful IP-VRF-to-IP-VRF with SBD IRB		Figure 9 depicts the Interface-ful IP-VRF-to-IP-VRF with SBD IRB
	model.		model.
	NVE1		NVE1
	+------------+ DGW1		+------------+ DGW1
	IP10+---+(BD-1) | +---------------+ +------------+		IP10+---+(BD-1) | +---------------+ +------------+
	| \ | | | | |		| \ | | | | |
	|(IP-VRF)-(SBD)| |(SBD)-(IP-VRF)|-----+		|(IP-VRF)-(SBD)| |(SBD)-(IP-VRF)|-----+
	| / IRB(M1/IP1) IRB(M3/IP3) | |		| / IRB(M1/IP1) IRB(M3/IP3) | |
	+---+(BD-2) | | | +------------+ _+_		+---+(BD-2) | | | +------------+ _+_
	| +------------+ | | ( )		| +------------+ | | ( )
	SN1| | VXLAN/ | ( WAN )--H1		SN1| | VXLAN/ | ( WAN )--H1
	| NVE2 | GENEVE/ | (___)		| NVE2 | GENEVE/ | (___)
	| +------------+ | MPLS | DGW2 +		| +------------+ | MPLS | DGW2 +
	+---+(BD-2) | | | +------------+ |		+---+(BD-2) | | | +------------+ |
	| \ | | | | | |		| \ | | | | | |
	|(IP-VRF)-(SBD)| |(SBD)-(IP-VRF)|-----+		|(IP-VRF)-(SBD)| |(SBD)-(IP-VRF)|-----+
	| / IRB(M2/IP2) IRB(M4/IP4) |		| / IRB(M2/IP2) IRB(M4/IP4) |
	SN2+----+(BD-3) | +---------------+ +------------+		SN2+----+(BD-3) | +---------------+ +------------+
	+------------+		+------------+
	Figure 6: Interface-ful with SBD IRB Model		Figure 9: Interface-ful with SBD IRB Model
	In this model:		In this model:
	a) As in Section 4.4.1, the NVEs and DGWs must provide connectivity		a) As in Section 4.4.1, the NVEs and DGWs must provide connectivity
	between hosts in SN1, SN2, and IP10 and in hosts sitting at the		between hosts in SN1, SN2, and IP10 and in hosts sitting at the
	other end of the WAN.		other end of the WAN.
	b) However, the NVE/DGWs are now connected through Ethernet NVO		b) However, the NVE/DGWs are now connected through Ethernet NVO
	tunnels terminated in the SBD instance. The IP-VRFs use IRB		tunnels terminated in the SBD instance. The IP-VRFs use IRB
	interfaces for their connectivity to the SBD.		interfaces for their connectivity to the SBD.
	skipping to change at line 1415 ¶		skipping to change at line 1415 ¶
	provide the forwarding information for the packet in BD-2.		provide the forwarding information for the packet in BD-2.
	The model described above is called an "interface-ful with SBD IRB"		The model described above is called an "interface-ful with SBD IRB"
	model because the tunnels connecting the DGWs and NVEs need to be		model because the tunnels connecting the DGWs and NVEs need to be
	terminated into the SBD. The SBD is connected to the IP-VRFs via SBD		terminated into the SBD. The SBD is connected to the IP-VRFs via SBD
	IRB interfaces, and that allows the recursive resolution of RT-5s to		IRB interfaces, and that allows the recursive resolution of RT-5s to
	GW IP addresses.		GW IP addresses.
	4.4.3. Interface-ful IP-VRF-to-IP-VRF with Unnumbered SBD IRB		4.4.3. Interface-ful IP-VRF-to-IP-VRF with Unnumbered SBD IRB
	Figure 7 depicts the Interface-ful IP-VRF-to-IP-VRF with unnumbered		Figure 10 depicts the Interface-ful IP-VRF-to-IP-VRF with unnumbered
	SBD IRB model. Note that this model is similar to the one described		SBD IRB model. Note that this model is similar to the one described
	in Section 4.4.2, only without IP addresses on the SBD IRB		in Section 4.4.2, only without IP addresses on the SBD IRB
	interfaces.		interfaces.
	NVE1		NVE1
	+------------+ DGW1		+------------+ DGW1
	IP1+----+(BD-1) | +---------------+ +------------+		IP1+----+(BD-1) | +---------------+ +------------+
	| \ | | | | |		| \ | | | | |
	|(IP-VRF)-(SBD)| (SBD)-(IP-VRF) |-----+		|(IP-VRF)-(SBD)| (SBD)-(IP-VRF) |-----+
	| / IRB(M1)| | IRB(M3) | |		| / IRB(M1)| | IRB(M3) | |
	skipping to change at line 1438 ¶		skipping to change at line 1438 ¶
	SN1| | VXLAN/ | ( WAN )--H1		SN1| | VXLAN/ | ( WAN )--H1
	| NVE2 | GENEVE/ | (___)		| NVE2 | GENEVE/ | (___)
	| +------------+ | MPLS | DGW2 +		| +------------+ | MPLS | DGW2 +
	+---+(BD-2) | | | +------------+ |		+---+(BD-2) | | | +------------+ |
	| \ | | | | | |		| \ | | | | | |
	|(IP-VRF)-(SBD)| (SBD)-(IP-VRF) |-----+		|(IP-VRF)-(SBD)| (SBD)-(IP-VRF) |-----+
	| / IRB(M2)| | IRB(M4) |		| / IRB(M2)| | IRB(M4) |
	SN2+----+(BD-3) | +---------------+ +------------+		SN2+----+(BD-3) | +---------------+ +------------+
	+------------+		+------------+
	Figure 7: Interface-ful with Unnumbered SBD IRB Model		Figure 10: Interface-ful with Unnumbered SBD IRB Model
	In this model:		In this model:
	a) As in Sections 4.4.1 and 4.4.2, the NVEs and DGWs must provide		a) As in Sections 4.4.1 and 4.4.2, the NVEs and DGWs must provide
	connectivity between hosts in SN1, SN2, and IP1 and in hosts		connectivity between hosts in SN1, SN2, and IP1 and in hosts
	sitting at the other end of the WAN.		sitting at the other end of the WAN.
	b) As in Section 4.4.2, the NVE/DGWs are connected through Ethernet		b) As in Section 4.4.2, the NVE/DGWs are connected through Ethernet
	NVO tunnels terminated in the SBD instance. The IP-VRFs use IRB		NVO tunnels terminated in the SBD instance. The IP-VRFs use IRB
	interfaces for their connectivity to the SBD.		interfaces for their connectivity to the SBD.
	skipping to change at line 1569 ¶		skipping to change at line 1569 ¶
	IANA has registered value 5 in the "EVPN Route Types" registry		IANA has registered value 5 in the "EVPN Route Types" registry
	[EVPNRouteTypes] defined by [RFC7432] as follows:		[EVPNRouteTypes] defined by [RFC7432] as follows:
	+=======+=============+===========+		+=======+=============+===========+
	| Value | Description | Reference |		| Value | Description | Reference |
	+=======+=============+===========+		+=======+=============+===========+
	| 5 | IP Prefix | RFC 9136 |		| 5 | IP Prefix | RFC 9136 |
	+-------+-------------+-----------+		+-------+-------------+-----------+
	Table 6		Table 3
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[EVPNRouteTypes]		[EVPNRouteTypes]
	IANA, "EVPN Route Types",		IANA, "EVPN Route Types",
	<https://www.iana.org/assignments/evpn>.		<https://www.iana.org/assignments/evpn>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
End of changes. 27 change blocks.
	61 lines changed or deleted		61 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/