rfc9572v2.txt   rfc9572.txt 
Internet Engineering Task Force (IETF) Z. Zhang Internet Engineering Task Force (IETF) Z. Zhang
Request for Comments: 9572 W. Lin Request for Comments: 9572 W. Lin
Updates: 7432 Juniper Networks Updates: 7432 Juniper Networks
Category: Standards Track J. Rabadan Category: Standards Track J. Rabadan
ISSN: 2070-1721 Nokia ISSN: 2070-1721 Nokia
K. Patel K. Patel
Arrcus Arrcus
A. Sajassi A. Sajassi
Cisco Systems Cisco Systems
April 2024 May 2024
Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM)
Procedures Procedures
Abstract Abstract
This document specifies updated procedures for handling Broadcast, This document specifies updated procedures for handling Broadcast,
Unknown Unicast, or Multicast (BUM) traffic in Ethernet VPNs (EVPNs), Unknown Unicast, or Multicast (BUM) traffic in Ethernet VPNs (EVPNs),
including selective multicast and segmentation of provider tunnels. including selective multicast and segmentation of provider tunnels.
This document updates RFC 7432. This document updates RFC 7432.
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
skipping to change at line 896 skipping to change at line 897
<https://www.rfc-editor.org/info/rfc8584>. <https://www.rfc-editor.org/info/rfc8584>.
[RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J., [RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J.,
and W. Lin, "Internet Group Management Protocol (IGMP) and and W. Lin, "Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) Proxies for Ethernet Multicast Listener Discovery (MLD) Proxies for Ethernet
VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022, VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022,
<https://www.rfc-editor.org/info/rfc9251>. <https://www.rfc-editor.org/info/rfc9251>.
[RFC9573] Zhang, Z., Rosen, E., Lin, W., Li, Z., and IJ. Wijnands, [RFC9573] Zhang, Z., Rosen, E., Lin, W., Li, Z., and IJ. Wijnands,
"MVPN/EVPN Tunnel Aggregation with Common Labels", "MVPN/EVPN Tunnel Aggregation with Common Labels",
RFC 9573, DOI 10.17487/RFC9573, April 2024, RFC 9573, DOI 10.17487/RFC9573, May 2024,
<https://www.rfc-editor.org/info/rfc9573>. <https://www.rfc-editor.org/info/rfc9573>.
10.2. Informative References 10.2. Informative References
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
November 2006, <https://www.rfc-editor.org/info/rfc4684>. November 2006, <https://www.rfc-editor.org/info/rfc4684>.
 End of changes. 5 change blocks. 
16 lines changed or deleted 17 lines changed or added

This html diff was produced by rfcdiff 1.48.