rfc9625v2.txt		rfc9625.txt
	skipping to change at line 777 ¶		skipping to change at line 777 ¶
	packet to PE2. The tunnel encapsulation will identify the		packet to PE2. The tunnel encapsulation will identify the
	apparent source BD as the SBD. Since the apparent source BD is		apparent source BD as the SBD. Since the apparent source BD is
	the SBD, PE2 will know to treat the frame as an inter-subnet		the SBD, PE2 will know to treat the frame as an inter-subnet
	multicast.		multicast.
	When IR is used to transmit IP multicast frames from an ingress EVPN		When IR is used to transmit IP multicast frames from an ingress EVPN
	PE to a set of egress PEs, then the ingress PE has to send multiple		PE to a set of egress PEs, then the ingress PE has to send multiple
	copies of the frame. Each copy is the original Ethernet frame;		copies of the frame. Each copy is the original Ethernet frame;
	decapsulation and IP processing take place only at the egress PE.		decapsulation and IP processing take place only at the egress PE.
	If a P2MP tree or Bit Index Explicit Replication (BIER) [EVPN-BUM] is		If a P2MP tree or Bit Index Explicit Replication (BIER) [RFC9624] is
	used to transmit an IP multicast frame from an ingress PE to a set of		used to transmit an IP multicast frame from an ingress PE to a set of
	egress PEs, then the ingress PE only has to send one copy of the		egress PEs, then the ingress PE only has to send one copy of the
	frame to each of its next hops. Again, each egress PE receives the		frame to each of its next hops. Again, each egress PE receives the
	original frame and does any necessary IP processing.		original frame and does any necessary IP processing.
	2. Detailed Model of Operation		2. Detailed Model of Operation
	The model described in Section 1.5.2 can be expressed more precisely		The model described in Section 1.5.2 can be expressed more precisely
	using the notion of IRB interface (see Appendix A). For a given		using the notion of IRB interface (see Appendix A). For a given
	Tenant Domain:		Tenant Domain:
	skipping to change at line 815 ¶		skipping to change at line 815 ¶
	These cases will be discussed in Section 7.		These cases will be discussed in Section 7.
	2.1. Supplementary Broadcast Domain		2.1. Supplementary Broadcast Domain
	Suppose a given Tenant Domain contains three BDs (BD1, BD2, and BD3)		Suppose a given Tenant Domain contains three BDs (BD1, BD2, and BD3)
	and two PEs (PE1 and PE2). PE1 attaches to BD1 and BD2, while PE2		and two PEs (PE1 and PE2). PE1 attaches to BD1 and BD2, while PE2
	attaches to BD2 and BD3.		attaches to BD2 and BD3.
	To carry out the procedures described above, all the PEs attached to		To carry out the procedures described above, all the PEs attached to
	the Tenant Domain must be provisioned with the SBD for that Tenant		the Tenant Domain must be provisioned with the SBD for that Tenant
	Domain. A RT must be associated with the SBD and provisioned on each		Domain. An RT must be associated with the SBD and provisioned on
	of those PEs. We will refer to that RT as the "SBD-RT".		each of those PEs. We will refer to that RT as the "SBD-RT".
	A Tenant Domain is also configured with an IP-VRF [RFC9135], and the		A Tenant Domain is also configured with an IP-VRF [RFC9135], and the
	IP-VRF is associated with an RT. This RT MAY be the same as the SBD-		IP-VRF is associated with an RT. This RT MAY be the same as the SBD-
	RT.		RT.
	Suppose an (S,G) multicast frame originating on BD1 has a receiver on		Suppose an (S,G) multicast frame originating on BD1 has a receiver on
	BD3. PE1 will transmit the packet to PE2 as a frame, and the		BD3. PE1 will transmit the packet to PE2 as a frame, and the
	encapsulation will identify the frame's source BD as BD1. Since PE2		encapsulation will identify the frame's source BD as BD1. Since PE2
	is not provisioned with BD1, it will treat the packet as if its		is not provisioned with BD1, it will treat the packet as if its
	source BD were the SBD. That is, a packet can be transmitted from		source BD were the SBD. That is, a packet can be transmitted from
	skipping to change at line 854 ¶		skipping to change at line 854 ¶
	In this document, we frequently say that a particular multicast route		In this document, we frequently say that a particular multicast route
	is "from" or "for" a particular BD or is "related to" or "associated		is "from" or "for" a particular BD or is "related to" or "associated
	with" a particular BD. These terms are used interchangeably.		with" a particular BD. These terms are used interchangeably.
	Subsequent sections of this document explain when various routes must		Subsequent sections of this document explain when various routes must
	be originated for particular BDs. In this section, we explain how		be originated for particular BDs. In this section, we explain how
	the PE originating a route marks the route to indicate which BD it is		the PE originating a route marks the route to indicate which BD it is
	for. We also explain how a PE receiving the route determines which		for. We also explain how a PE receiving the route determines which
	BD the route is for.		BD the route is for.
	In EVPN, each BD is assigned a RT. An RT is a BGP Extended Community		In EVPN, each BD is assigned an RT. An RT is a BGP Extended
	that can be attached to the BGP routes used by the EVPN control		Community that can be attached to the BGP routes used by the EVPN
	plane. In some EVPN service models, each BD is assigned a unique RT.		control plane. In some EVPN service models, each BD is assigned a
	In other service models, a set of BDs (all in the same EVI) may be		unique RT. In other service models, a set of BDs (all in the same
	assigned the same RT. The RT that is assigned to the SBD is called		EVI) may be assigned the same RT. The RT that is assigned to the SBD
	the "SBD-RT".		is called the "SBD-RT".
	In those service models that allow a set of BDs to share a single RT,		In those service models that allow a set of BDs to share a single RT,
	each BD is assigned a non-zero Tag ID. The Tag ID appears in the		each BD is assigned a non-zero Tag ID. The Tag ID appears in the
	Network Layer Reachability Information (NLRI) of many of the BGP		Network Layer Reachability Information (NLRI) of many of the BGP
	routes that are used by the EVPN control plane.		routes that are used by the EVPN control plane.
	A given route may be for the SBD or an ordinary BD (a BD that is not		A given route may be for the SBD or an ordinary BD (a BD that is not
	the SBD). An RT that has been assigned to an ordinary BD will be		the SBD). An RT that has been assigned to an ordinary BD will be
	known as an "ordinary BD-RT".		known as an "ordinary BD-RT".
	skipping to change at line 965 ¶		skipping to change at line 965 ¶
	In this case, the route is associated with the BD in EVI-1		In this case, the route is associated with the BD in EVI-1
	that is identified (in the context of EVI-1) by the Tag ID		that is identified (in the context of EVI-1) by the Tag ID
	field of the route's NLRI. (If EVI-1 contains only a single		field of the route's NLRI. (If EVI-1 contains only a single
	BD, the Tag ID is likely to be zero.)		BD, the Tag ID is likely to be zero.)
	This is the case where the route is for a BD to which the		This is the case where the route is for a BD to which the
	receiving PE is attached, but the route also carries the		receiving PE is attached, but the route also carries the
	SBD-RT. In this case, the receiving PE associates the route		SBD-RT. In this case, the receiving PE associates the route
	with the ordinary BD, not with the SBD.		with the ordinary BD, not with the SBD.
	NB: According to the above rules, the mapping from BD to RT is a		Note that according to the above rules, the mapping from BD to RT is
	many-to-one or one-to-one mapping. A route that an EVPN PE		a many-to-one or one-to-one mapping. A route that an EVPN PE
	originates for a particular BD carries that BD's RT, and an EVPN PE		originates for a particular BD carries that BD's RT, and an EVPN PE
	that receives the route associates it with a BD as described above.		that receives the route associates it with a BD as described above.
	However, RTs are not used only to help identify the BD to which a		However, RTs are not used only to help identify the BD to which a
	route belongs; they may also be used by BGP to determine the path		route belongs; they may also be used by BGP to determine the path
	along which the route is distributed and to determine which PEs		along which the route is distributed and to determine which PEs
	receive the route. There may be cases where it is desirable to		receive the route. There may be cases where it is desirable to
	originate a route for a particular BD but have that route distributed		originate a route for a particular BD but have that route distributed
	to only some of the EVPN PEs attached to that BD. Or one might want		to only some of the EVPN PEs attached to that BD. Or one might want
	the route distributed to some intermediate set of systems, where it		the route distributed to some intermediate set of systems, where it
	might be modified or replaced before being propagated further. Such		might be modified or replaced before being propagated further. Such
	skipping to change at line 1222 ¶		skipping to change at line 1222 ¶
	BDs that can freely send and receive IP multicast traffic to/from		BDs that can freely send and receive IP multicast traffic to/from
	each other. If an EVPN PE has one or more ACs in a BD of a		each other. If an EVPN PE has one or more ACs in a BD of a
	particular Tenant Domain, and if the EVPN PE supports the procedures		particular Tenant Domain, and if the EVPN PE supports the procedures
	of this document, that EVPN PE MUST be provisioned with the SBD of		of this document, that EVPN PE MUST be provisioned with the SBD of
	that Tenant Domain.		that Tenant Domain.
	At each EVPN PE attached to a given Tenant Domain, there is an IRB		At each EVPN PE attached to a given Tenant Domain, there is an IRB
	interface leading from the L3 routing instance of that Tenant Domain		interface leading from the L3 routing instance of that Tenant Domain
	to the SBD. However, the SBD has no ACs.		to the SBD. However, the SBD has no ACs.
	Each SBD is provisioned with a RT. All the EVPN PEs supporting a		Each SBD is provisioned with an RT. All the EVPN PEs supporting a
	given SBD are provisioned with that RT as an import RT. That RT MUST		given SBD are provisioned with that RT as an import RT. That RT MUST
	NOT be the same as the RT associated with any other BD.		NOT be the same as the RT associated with any other BD.
	We will use the term "SBD-RT" to denote the RT that has been assigned		We will use the term "SBD-RT" to denote the RT that has been assigned
	to the SBD. Routes carrying this RT will be propagated to all EVPN		to the SBD. Routes carrying this RT will be propagated to all EVPN
	PEs in the same Tenant Domain as the originator.		PEs in the same Tenant Domain as the originator.
	Section 2.2 specifies the rules by which an EVPN PE that receives a		Section 2.2 specifies the rules by which an EVPN PE that receives a
	route determines whether a received route belongs to a particular		route determines whether a received route belongs to a particular
	ordinary BD or SBD.		ordinary BD or SBD.
	skipping to change at line 1419 ¶		skipping to change at line 1419 ¶
	Suppose an ingress EVPN PE, say PE1, needs to use BIER to tunnel an		Suppose an ingress EVPN PE, say PE1, needs to use BIER to tunnel an
	IP multicast frame to a set of egress EVPN PEs. And suppose the		IP multicast frame to a set of egress EVPN PEs. And suppose the
	frame's source BD is BD1. The frame is encapsulated as follows:		frame's source BD is BD1. The frame is encapsulated as follows:
	* A four-octet MPLS label stack entry [RFC3032] is prepended to the		* A four-octet MPLS label stack entry [RFC3032] is prepended to the
	frame. The Label field is set to the upstream-assigned label that		frame. The Label field is set to the upstream-assigned label that
	PE1 has assigned to BD1.		PE1 has assigned to BD1.
	* The resulting MPLS packet is then encapsulated in a BIER		* The resulting MPLS packet is then encapsulated in a BIER
	encapsulation [RFC8296] [EVPN-BUM]. The BIER BitString is set to		encapsulation [RFC8296] [RFC9624]. The BIER BitString is set to
	identify the egress EVPN PEs. The BIER Proto field is set to the		identify the egress EVPN PEs. The BIER Proto field is set to the
	value for "MPLS packet with an upstream-assigned label at top of		value for "MPLS packet with an upstream-assigned label at top of
	the stack".		the stack".
	Note: It is possible that the packet being tunneled from PE1		Note: It is possible that the packet being tunneled from PE1
	originated outside the Tenant Domain. In this case, the actual		originated outside the Tenant Domain. In this case, the actual
	source BD, BD1, is considered to be the SBD, and the upstream-		source BD, BD1, is considered to be the SBD, and the upstream-
	assigned label it carries will be the label that PE1 assigned to the		assigned label it carries will be the label that PE1 assigned to the
	SBD and advertised in its SBD-IMET route.		SBD and advertised in its SBD-IMET route.
	skipping to change at line 1448 ¶		skipping to change at line 1448 ¶
	This enables PE2 to determine the apparent source BD (as defined		This enables PE2 to determine the apparent source BD (as defined
	in Section 2.4).		in Section 2.4).
	2. PE2 has not received and installed an IMET route for BD1 from		2. PE2 has not received and installed an IMET route for BD1 from
	PE1.		PE1.
	In this case, PE2 will not recognize the upstream-assigned label		In this case, PE2 will not recognize the upstream-assigned label
	carried in the BIER packet. PE2 MUST discard the packet.		carried in the BIER packet. PE2 MUST discard the packet.
	Further details on the use of BIER to support EVPN can be found in		Further details on the use of BIER to support EVPN can be found in
	[EVPN-BUM].		[RFC9624].
	3.2.5. Inclusive P2MP Tunnels		3.2.5. Inclusive P2MP Tunnels
	3.2.5.1. Using the BUM Tunnels as IP Multicast Inclusive Tunnels		3.2.5.1. Using the BUM Tunnels as IP Multicast Inclusive Tunnels
	The procedures in this section apply only when:		The procedures in this section apply only when:
	a) it is desired to use the BUM tunnels to carry IP multicast		a) it is desired to use the BUM tunnels to carry IP multicast
	traffic across the backbone and		traffic across the backbone and
	skipping to change at line 2428 ¶		skipping to change at line 2428 ¶
	group G has both external sources (sources outside the EVPN Tenant		group G has both external sources (sources outside the EVPN Tenant
	Domain) and internal sources (sources inside the EVPN Tenant Domain).		Domain) and internal sources (sources inside the EVPN Tenant Domain).
	Section 4.2 states that when there are internal sources, the SBD IRB		Section 4.2 states that when there are internal sources, the SBD IRB
	interface must not be added to the OIF list of the (*,G) state.		interface must not be added to the OIF list of the (*,G) state.
	Traffic from internal sources will already have been delivered to all		Traffic from internal sources will already have been delivered to all
	the EVPN PEs that have interest in it. However, if the OIF list of		the EVPN PEs that have interest in it. However, if the OIF list of
	the (*,G) state does not contain its SBD IRB interface, then traffic		the (*,G) state does not contain its SBD IRB interface, then traffic
	from external sources will not get delivered to other EVPN PEs.		from external sources will not get delivered to other EVPN PEs.
	One way of handling this is the following. When an L3 Gateway		One way of handling this is the following. When an L3 Gateway
	receives (S,G) traffic from other than an IRB interface, and the		receives (S,G) traffic that is from an interface other than IRB, and
	traffic corresponds to a Layer 3 (*,G) state, the L3 Gateway can		the traffic corresponds to a Layer 3 (*,G) state, the L3 Gateway can
	create (S,G) state. The IIF will be set to the external interface		create (S,G) state. The IIF will be set to the external interface
	over which the traffic is expected. The OIF list will contain the		over which the traffic is expected. The OIF list will contain the
	SBD IRB interface, as well as the IRB interfaces of any other BDs		SBD IRB interface, as well as the IRB interfaces of any other BDs
	attached to the PEG DR that have locally attached receivers with		attached to the PEG DR that have locally attached receivers with
	interest in the (S,G) traffic. The (S,G) state will ensure that the		interest in the (S,G) traffic. The (S,G) state will ensure that the
	external traffic is sent down the SBD IRB interface. The following		external traffic is sent down the SBD IRB interface. The following
	text will assume this procedure; however, other implementation		text will assume this procedure; however, other implementation
	techniques may also be possible.		techniques may also be possible.
	If a particular BD is attached to several L3 Gateways, one of the L3		If a particular BD is attached to several L3 Gateways, one of the L3
	skipping to change at line 2455 ¶		skipping to change at line 2455 ¶
	an FHR, the DR for a given BD would send the PIM Register messages		an FHR, the DR for a given BD would send the PIM Register messages
	for sources on that BD). Although, note that the DR for the SBD does		for sources on that BD). Although, note that the DR for the SBD does
	not perform FHR functionality on behalf of external sources.		not perform FHR functionality on behalf of external sources.
	An optional alternative is to have each L3 Gateway perform FHR		An optional alternative is to have each L3 Gateway perform FHR
	functionality for locally attached sources. Then, the DR would only		functionality for locally attached sources. Then, the DR would only
	have to perform FHR functionality on behalf of sources that are		have to perform FHR functionality on behalf of sources that are
	locally attached to itself AND sources that are not attached to any		locally attached to itself AND sources that are not attached to any
	L3 Gateway.		L3 Gateway.
	NB: If it is possible that more than one BD contains a tenant		Note that if it is possible that more than one BD contains a tenant
	multicast router, then a PE receiving a SMET route for that BD MUST		multicast router, then a PE receiving a SMET route for that BD MUST
	NOT reconstruct IGMP/MLD Join Reports from the SMET route and MUST		NOT reconstruct IGMP/MLD Join Reports from the SMET route and MUST
	NOT transmit any such IGMP/MLD Join Reports on its local ACs		NOT transmit any such IGMP/MLD Join Reports on its local ACs
	attaching to that BD. Otherwise, multicast traffic may be		attaching to that BD. Otherwise, multicast traffic may be
	duplicated.		duplicated.
	6.1.2. Interworking with MVPN		6.1.2. Interworking with MVPN
	In this section, we specify the procedures necessary to allow EVPN		In this section, we specify the procedures necessary to allow EVPN
	PEs running OISM procedures to interwork with L3VPN PEs that run BGP-		PEs running OISM procedures to interwork with L3VPN PEs that run BGP-
	skipping to change at line 3316 ¶		skipping to change at line 3316 ¶
	DOI 10.17487/RFC9572, May 2024,		DOI 10.17487/RFC9572, May 2024,
	<https://www.rfc-editor.org/info/rfc9572>.		<https://www.rfc-editor.org/info/rfc9572>.
	[RFC9574] Rabadan, J., Ed., Sathappan, S., Lin, W., Katiyar, M., and		[RFC9574] Rabadan, J., Ed., Sathappan, S., Lin, W., Katiyar, M., and
	A. Sajassi, "Optimized Ingress Replication Solution for		A. Sajassi, "Optimized Ingress Replication Solution for
	Ethernet VPNs (EVPNs)", RFC 9574, DOI 10.17487/RFC9574,		Ethernet VPNs (EVPNs)", RFC 9574, DOI 10.17487/RFC9574,
	May 2024, <https://www.rfc-editor.org/info/rfc9574>.		May 2024, <https://www.rfc-editor.org/info/rfc9574>.
	10.2. Informative References		10.2. Informative References
	[EVPN-BUM] Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan,
	"EVPN Broadcast, Unknown Unicast, and Multicast (BUM)
	Using Bit Index Explicit Replication (BIER)", Work in
	Progress, Internet-Draft, draft-ietf-bier-evpn-14, August
	2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
	bier-evpn-14>.
	[EVPN-DF] Rabadan, J., Sathappan, S., Lin, W., Drake, J., and A.		[EVPN-DF] Rabadan, J., Sathappan, S., Lin, W., Drake, J., and A.
	Sajassi, "Preference-based EVPN DF Election", Work in		Sajassi, "Preference-based EVPN DF Election", Work in
	Progress, Internet-Draft, draft-ietf-bess-evpn-pref-df-13,		Progress, Internet-Draft, draft-ietf-bess-evpn-pref-df-13,
	9 October 2023, <https://datatracker.ietf.org/doc/html/		9 October 2023, <https://datatracker.ietf.org/doc/html/
	draft-ietf-bess-evpn-pref-df-13>.		draft-ietf-bess-evpn-pref-df-13>.
	[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>.
	skipping to change at line 3371 ¶		skipping to change at line 3364 ¶
	Multicast - Sparse Mode (PIM-SM): Protocol Specification		Multicast - Sparse Mode (PIM-SM): Protocol Specification
	(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March		(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
	2016, <https://www.rfc-editor.org/info/rfc7761>.		2016, <https://www.rfc-editor.org/info/rfc7761>.
	[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,		[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
	Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation		Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
	for Bit Index Explicit Replication (BIER) in MPLS and Non-		for Bit Index Explicit Replication (BIER) in MPLS and Non-
	MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January		MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
	2018, <https://www.rfc-editor.org/info/rfc8296>.		2018, <https://www.rfc-editor.org/info/rfc8296>.
			[RFC9624] Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan,
			"EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Using
			Bit Index Explicit Replication (BIER)", RFC 9624,
			DOI 10.17487/RFC9624, August 2024,
			<https://www.rfc-editor.org/info/rfc9624>.
	Appendix A. Integrated Routing and Bridging		Appendix A. Integrated Routing and Bridging
	This appendix provides a short tutorial on the interaction of routing		This appendix provides a short tutorial on the interaction of routing
	and bridging. First, it shows the traditional model, where bridging		and bridging. First, it shows a model, where bridging and routing
	and routing are performed in separate devices. Then, it shows the		are performed in separate devices. Then, it shows the model
	model specified in [RFC9135], where a single device contains both		specified in [RFC9135], where a single device contains both routing
	routing and bridging functions. The latter model is presupposed in		and bridging functions. The latter model is presupposed in the body
	the body of this document.		of this document.
	Figure 2 shows a traditional router that only does routing and has no		Figure 2 shows the model where a router only does routing and has no
	L2 bridging capabilities. There are two LANs: LAN1 and LAN2. LAN1		L2 bridging capabilities. There are two LANs: LAN1 and LAN2. LAN1
	is realized by switch1, and LAN2 is realized by switch2. The router		is realized by switch1, and LAN2 is realized by switch2. The router
	has an interface, lan1, that attaches to LAN1 (via switch1) and an		has an interface, lan1, that attaches to LAN1 (via switch1) and an
	interface, lan2, that attaches to LAN2 (via switch2). Each interface		interface, lan2, that attaches to LAN2 (via switch2). Each interface
	is configured, as an IP interface, with an IP address and a subnet		is configured, as an IP interface, with an IP address and a subnet
	mask.		mask.
	+-------+ +--------+ +-------+		+-------+ +--------+ +-------+
	| | lan1| |lan2 | |		| | lan1| |lan2 | |
	H1 -----+Switch1+--------+ Router1+--------+Switch2+------H3		H1 -----+Switch1+--------+ Router1+--------+Switch2+------H3
End of changes. 13 change blocks.
	30 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.48.