rfc9572v2.txt		rfc9572.txt
	skipping to change at line 497 ¶		skipping to change at line 497 ¶
	| If the received Inter-AS A-D route carries the PMSI Tunnel		| If the received Inter-AS A-D route carries the PMSI Tunnel
	| attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then		| attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then
	| the ASBR that originated the route MUST establish an RSVP-TE P2MP		| the ASBR that originated the route MUST establish an RSVP-TE P2MP
	| LSP with the local PE/ASBR as a leaf. This LSP MAY have been		| LSP with the local PE/ASBR as a leaf. This LSP MAY have been
	| established before the local PE/ASBR receives the route, or it MAY		| established before the local PE/ASBR receives the route, or it MAY
	| be established after the local PE receives the route.		| be established after the local PE receives the route.
	is changed to the following when applied to EVPNs:		is changed to the following when applied to EVPNs:
	| If the received Inter-AS A-D route has the L flag set in its PTA,		| If the received Inter-AS A-D route has the L flag set in its PTA,
	| then a receiving PE MUST originate a corresponding Leaf A-D route,		| then a receiving PE MUST originate a corresponding Leaf A-D route.
	| while a receiving ASBR MUST originate a corresponding Leaf A-D		| A receiving ASBR MUST originate a corresponding Leaf A-D route if
	| route if and only if it received and imported one or more		| and only if one of the following conditions is met: (1) it
	| corresponding Leaf A-D routes from its downstream IBGP or EBGP		| received and imported one or more corresponding Leaf A-D routes
	| peers, or it has non-null downstream forwarding state for the PIM/		| from its downstream IBGP or EBGP peers or (2) it has non-null
	| mLDP tunnel that instantiates its downstream intra-AS segment.		| downstream forwarding state for the PIM/mLDP tunnel that
	| The targeted ASBR for the Leaf A-D route, which (re-)advertised		| instantiates its downstream intra-AS segment. The targeted ASBR
	| the Inter-AS A-D route, MUST establish a tunnel to the leaves		| for the Leaf A-D route, which (re-)advertised the Inter-AS A-D
	| discovered by the Leaf A-D routes.		| route, MUST establish a tunnel to the leaves discovered by the
			| Leaf A-D routes.
	5.2. I-PMSI Leaf Tracking		5.2. I-PMSI Leaf Tracking
	An ingress PE does not set the L flag in its IMET A-D route's PTA,		An ingress PE does not set the L flag in its IMET A-D route's PTA,
	even with ingress replication or RSVP-TE P2MP tunnels. It does not		even with Ingress Replication tunnels or RSVP-TE P2MP tunnels. It
	rely on the Leaf A-D routes to discover leaves in its AS, and		does not rely on the Leaf A-D routes to discover leaves in its AS,
	Section 11.2 of [RFC7432] explicitly states that the L flag must be		and Section 11.2 of [RFC7432] explicitly states that the L flag must
	set to 0.		be set to 0.
	An implementation of [RFC7432] might have used the Originating		An implementation of [RFC7432] might have used the Originating
	Router's IP Address field of the IMET A-D routes to determine the		Router's IP Address field of the IMET A-D routes to determine the
	leaves or might have used the Next Hop field instead. Within the		leaves or might have used the Next Hop field instead. Within the
	same AS, both will lead to the same result.		same AS, both will lead to the same result.
	With segmentation, an ingress PE MUST determine the leaves in its AS		With segmentation, an ingress PE MUST determine the leaves in its AS
	from the BGP next hops in all its received IMET A-D routes, so it		from the BGP next hops in all its received IMET A-D routes, so it
	does not have to set the L flag to request Leaf A-D routes. PEs		does not have to set the L flag to request Leaf A-D routes. PEs
	within the same AS will all have different next hops in their IMET		within the same AS will all have different next hops in their IMET
	skipping to change at line 788 ¶		skipping to change at line 789 ¶
	determines the leaves based on the BGP next hops in its received		determines the leaves based on the BGP next hops in its received
	I-PMSI A-D routes, as specified in Section 5.2.		I-PMSI A-D routes, as specified in Section 5.2.
	The same backward-compatibility issue exists, and the same solution		The same backward-compatibility issue exists, and the same solution
	as that for the inter-AS case applies, as specified in Section 5.3.		as that for the inter-AS case applies, as specified in Section 5.3.
	7. Multihoming Support		7. Multihoming Support
	To support multihoming with segmentation, Ethernet Segment Identifier		To support multihoming with segmentation, Ethernet Segment Identifier
	(ESI) labels SHOULD be allocated from a "Domain-wide Common Block"		(ESI) labels SHOULD be allocated from a "Domain-wide Common Block"
	(DCB) [RFC9573] for all tunnel types, including ingress replication		(DCB) [RFC9573] for all tunnel types, including Ingress Replication
	tunnels [RFC7988]. Via means outside the scope of this document, PEs		tunnels [RFC7988]. Via means outside the scope of this document, PEs
	know that ESI labels are from a DCB, and existing multihoming		know that ESI labels are from a DCB, and existing multihoming
	procedures will then work "as is" (whether a multihomed Ethernet		procedures will then work "as is" (whether a multihomed Ethernet
	Segment spans segmentation regions or not).		Segment spans segmentation regions or not).
	Not using DCB-allocated ESI labels is outside the scope of this		Not using DCB-allocated ESI labels is outside the scope of this
	document.		document.
	8. IANA Considerations		8. IANA Considerations
End of changes. 3 change blocks.
	14 lines changed or deleted		15 lines changed or added
This html diff was produced by rfcdiff 1.48.