<?xml version="1.0"encoding="US-ASCII"?>encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYRFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">nbsp " "> <!ENTITYRFC7117 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7117.xml">zwsp "​"> <!ENTITYRFC7432 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"> <!ENTITY RFC7524 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7524.xml"> <!ENTITY RFC6513 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6513.xml"> <!ENTITY RFC6514 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6514.xml"> <!ENTITY RFC7988 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7988.xml"> <!ENTITY RFC8174 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY RFC8279 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml"> <!ENTITY RFC8584 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8584.xml"> <!ENTITY RFC8534 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8534.xml">nbhy "‑"> <!ENTITYRFC4875 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4875.xml"> <!ENTITY RFC4684 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4684.xml"> <!ENTITY RFC6388 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6388.xml">wj "⁠"> ]><?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc strict="no"?> <?rfc rfcedstyle="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?><rfccategory="std"xmlns:xi="http://www.w3.org/2001/XInclude" updates="7432" docName="draft-ietf-bess-evpn-bum-procedure-updates-14"ipr="trust200902">number="9572" ipr="trust200902" obsoletes="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.12.0 --> <front> <titleabbrev="evpn-bum-procedure-update">Updatesabbrev="EVPN BUM Procedures: Updates">Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Procedures</title> <!-- [rfced] Document title: Running (abbreviated) title (PDF output): We changed "evpn-bum-procedure-update" to "EVPN BUM Procedures: Updates" so that the title is more descriptive. Title: We changed "Updates on EVPN BUMProcedures</title>Procedures" to "Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Procedures" per similar titles of published RFCs (i.e., there aren't any published RFCs to date that have "Updates on" in the document title). Please let us know any objections to these updates. Original: evpn-bum-procedure-update Updates on EVPN BUM Procedures Currently (PDF output for the running title): Running title: EVPN BUM Procedures: Updates Title: Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Procedures --> <seriesInfo name="RFC" value="9572"/> <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang"> <organization>Juniper Networks</organization> <address> <email>zzhang@juniper.net</email> </address> </author> <author fullname="Wen Lin" initials="W." surname="Lin"> <organization>Juniper Networks</organization> <address> <email>wlin@juniper.net</email> </address> </author> <author fullname="Jorge Rabadan" initials="J." surname="Rabadan"> <organization>Nokia</organization> <address> <email>jorge.rabadan@nokia.com</email> </address> </author> <author fullname="Keyur Patel" initials="K." surname="Patel"> <organization>Arrcus</organization> <address> <email>keyur@arrcus.com</email> </address> </author> <author fullname="Ali Sajassi" initials="A." surname="Sajassi"> <organization>Cisco Systems</organization> <address> <email>sajassi@cisco.com</email> </address> </author> <dateyear="2021"/>year="2024" month="April" /> <area>rtg</area> <workgroup>BESS</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on <https://www.rfc-editor.org/search>. --> <abstract> <t>This document specifies updated procedures for handlingbroadcast, unknown unicast, and multicastBroadcast, Unknown Unicast, or Multicast (BUM) traffic in Ethernet VPNs(EVPN),(EVPNs), including selective multicast, and provider tunnel segmentation. This document updates RFC 7432.</t> </abstract> <note title="Requirements Language"> <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in<!-- [rfced] Abstract: We had trouble parsing thisdocument aresentence due tobe interpreted as describedcomma usage. If the suggested text is not correct, please provide clarifying text. Original: This document specifies updated procedures for handling broadcast, unknown unicast, and multicast (BUM) traffic inBCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when,Ethernet VPNs (EVPN), including selective multicast, andonly when, they appearprovider tunnel segmentation. Suggested: This document specifies updated procedures for handling Broadcast, Unknown Unicast, or Multicast (BUM) traffic inall capitals, as shown here.Ethernet VPNs (EVPNs), including selective multicast and segmentation of provider tunnels. --> </t></note></abstract> </front> <middle><section title="Terminology"> <t>It is expected that audience is familiar with MVPN [RFC6513] [RFC6514], VPLS Multicast [RFC7117]<!-- [rfced] We restructured Sections 1 andEVPN [RFC7432] concepts2 of this document per standard practice (e.g., RFCs 9251 andterminologies. For convenience, the following terms9252, which arebriefly explained. <list style="symbols"> <t>PMSI [RFC6513]: P-Multicast Service Interface - a conceptual interface for a PE to send customer multicast traffic to all or some PEs in the same VPN. </t> <t>I-PMSI: Inclusive PMSI - to all PEs in the same VPN. </t> <t>S-PMSI: Selective PMSI - to somealso part ofthe PEs in the same VPN. </t> <t>I/S-PMSI A-D Route: Auto-Discovery routes used to announce the tunnels that instantiate an I/S-PMSI. </t> <t>Leaf Auto-Discovery (A-D) routes [RFC6513]: For explicit leaf tracking purpose. Triggered by I/S-PMSI A-D routesCluster 448 (https://www.rfc-editor.org/cluster_info.php?cid=C448)) andtargeted at triggering route's (re-)advertiser. Its NLRI embeds the entire NLRIper Section 4.8.1 ("Introduction Section") ofthe triggering PMSI A-D route. </t> <t>IMET A-D route [RFC7432]: Inclusive Multicast Ethernet Tag A-D route. The EVPN equivalentRFC 7322 ("RFC Style Guide" - https://www.rfc-editor.org/info/rfc7322). Please let us know any concerns. Original: 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Tunnel Segmentation . . . . . . . . . . . . . . . . . . . 4 2.1.1. Reasons for Tunnel Segmentation . . . . . . . . . . . 5 3. Additional Route Types ofMVPN Intra-AS I-PMSI A-D route used to announce the tunnels that instantiate an I-PMSI. </t> <t>SMET A-D route <xref target="I-D.ietf-bess-evpn-igmp-mld-proxy"/>: Selective Multicast Ethernet Tag A-D route. TheEVPNequivalent of MVPN Leaf A-D route but unsolicited and untargeted. </t> <t>PMSINLRI . . . . . . . . . . . . . 6 ... Currently: 1. Introduction 1.1. Requirements Language 1.2. Terminology 2. TunnelAttribute (PTA): An optional transitive BGP attribute that may be attached to PMSI/Leaf A-D routes to provide informationSegmentation 2.1. Reasons fora PMSI tunnel. </t> </list> </t> </section>Tunnel Segmentation 3. Additional Route Types of EVPN NLRI ... --> <sectiontitle="Introduction"> <t>[RFC7117]numbered="true" toc="default"> <name>Introduction</name> <t><xref target="RFC7117" format="default"/> specifies procedures forMulticastmulticast in the Virtual Private LAN Service (VPLSMulticast)multicast), using both inclusive tunnels and selective tunnels with or withoutinter-asinter-AS segmentation, similar to the Multicast VPN (MVPN) procedures specified in[RFC6513]<xref target="RFC6513" format="default"/> and[RFC6514]. [RFC7524]<xref target="RFC6514" format="default"/>. <xref target="RFC7524" format="default"/> specifies inter-area tunnel segmentation procedures for both VPLSMulticastmulticast andMVPN.MVPNs. </t><t>[RFC7432]<t><xref target="RFC7432" format="default"/> specifies BGPMPLS-BasedMPLS-based Ethernet VPN (EVPN) procedures, including those handlingbroadcast, unknown unicast, and multicastBroadcast, Unknown Unicast, or Multicast (BUM) traffic. A lot of details are referred to[RFC7117],<xref target="RFC7117" format="default"/>, yet with quite some feature gaps like selective tunnel and tunnel segmentation (<xreftarget="segmentation"/>).target="segmentation" format="default"/>). <!-- [rfced] Introduction: We cannot follow the meaning of this sentence. If the suggested text is not correct, please clarify "are referred to [RFC7117]" and "yet with quite some feature gaps like". Original: A lot of details are referred to [RFC7117], yet with quite some feature gaps like selective tunnel and tunnel segmentation (Section 2.1). Suggested: [RFC7117] provides many details but leaves quite a few feature gaps related to selective tunnels and tunnel segmentation (Section 2). --> </t> <t>This document aimsat filling theto fill in those gaps- coverby covering the use of selective and segmented tunnels inEVPN.EVPNs. It follows the same editorial choice as that discussed inRFC7432<xref target="RFC7432"/> and only specifies differences from relevant procedures provided in[RFC7117]<xref target="RFC7117" format="default"/> and[RFC7524],<xref target="RFC7524" format="default"/>, instead of repeating the text. Note that these differences are applicable toEVPN only,EVPNs only and are not updates to[RFC7117]<xref target="RFC7117" format="default"/> or[RFC7524].<xref target="RFC7524" format="default"/>. <!-- [rfced] Introduction: Looking at RFC 7432, we could not determine the meaning of "same editorial choice". Will this expression be understood by readers? Original (the previous sentence is included for context): This document aims at filling the gaps - cover the use of selective and segmented tunnels in EVPN. It follows the same editorial choice as in RFC7432 and only specifies differences from relevant procedures in [RFC7117] and [RFC7524], instead of repeating the text. --> </t> <t>MVPN,VPLSVPLS, and EVPN technologies allhave theneed to discover otherPEsProvider Edges (PEs) in the same L3/L2 VPN and announce the inclusive tunnels. MVPN technology introduced theI-PMSIInclusive P-Multicast Service Interface (I-PMSI) concept and uses I-PMSIA-D routeAuto-Discovery (A-D) routes forthat.that purpose. EVPN technology uses Inclusive Multicast Ethernet TagRoute(IMET) A-Drouteroutes, but VPLS technology just addsana PMSI Tunnel Attribute (PTA) tothean existing VPLS A-D route for that purpose. For selective tunnels, they all do use the same termS-PMSISelective PMSI (S-PMSI) A-D routes.</t> <t>Many places<!-- [rfced] Introduction: Please clarify the meaning of "same term S-PMSI A-D routes". Does this mean that "S-PMSI A-D routes" is the same term as something else? If yes, what would that other term be? Also, please clarify "they all do use"; does this mean "they all use" or something else? Original: For selective tunnels, they all do use the same term S-PMSI A-D routes. Possibly: In the case of selective tunnels, all of these technologies use Selective PMSI (S-PMSI) A-D routes. --> </t> <t>This documentinvolveoften refers to the I-PMSIconcept thatconcept, which isallthe same for all three technologies. For consistency and convenience, an EVPN's IMET A-D route and a VPLS's VPLS A-D route carrying a PTA for BUM trafficpurposepurposes mayalleach be referred to as an I-PMSI A-Droutesroute, depending on the context.</t> <!--t>MVPN uses terms<!-- [rfced] Introduction: The original sentence did not parse. We updated it as follows. If this is incorrect, please provide clarifying text. Original: Many places of this document involve the I-PMSI concept that is all the same for all three technologies. Currently: This document often refers to the I-PMSI concept, which is the same for all three technologies. --> </t> <section numbered="true" toc="default"> <name>Requirements Language</name> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", andS-PMSI A-D Routes. For consistency and convenience,"<bcp14>OPTIONAL</bcp14>" in this documentwill useare to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> </section> <section numbered="true" toc="default"> <name>Terminology</name> <t>It is assumed that thesame I/S-PMSIreader is familiar with concepts and terminologies related to MVPN technology <xref target="RFC6513" format="default"/> <xref target="RFC6514" format="default"/>, VPLS multicast <xref target="RFC7117" format="default"/>, and EVPN technology <xref target="RFC7432" format="default"/>. For convenience, the following terms are briefly explained. </t> <dl spacing="normal"> <dt>AS:</dt><dd>Autonomous System</dd> <dt>PMSI <xref target="RFC6513" format="default"/>:</dt><dd>P-Multicast Service Interface. A conceptual interface forVPLSa PE to send customer multicast traffic to all or some PEs in the same VPN.</dd> <dt>I-PMSI:</dt><dd>Inclusive PMSI. Enables traffic to be sent to all PEs in the same VPN.</dd> <dt>S-PMSI:</dt><dd>Selective PMSI. Enables traffic to be sent to some of the PEs in the same VPN.</dd> <dt>I/S-PMSI A-D Route:</dt><dd>Auto-Discovery route used to announce the tunnels that instantiate an I/S-PMSI.</dd> <dt>Leaf Auto-Discovery (A-D) Route <xref target="RFC6513" format="default"/>:</dt><dd>For explicit leaf-tracking purposes. Triggered by I/S-PMSI A-D routes andEVPN. In particular, EVPN's Inclusivetargeted at the triggering route's (re-)advertiser. Its Network Layer Reachability Information (NLRI) embeds the entire NLRI of the triggering PMSI A-D route.</dd> <dt>IMET A-D Route <xref target="RFC7432" format="default"/>:</dt><dd>Inclusive Multicast Ethernet TagRoute and VPLS's VPLSA-D route. The EVPN equivalent of an MVPN Intra-AS I-PMSI A-D routecarrying PTA (PMSIused to announce the tunnels that instantiate an I-PMSI.</dd> <dt>SMET A-D Route <xref target="RFC9251" format="default"/>:</dt> <dd>Selective Multicast Ethernet Tag A-D route. The EVPN equivalent of an MVPN Leaf A-D route, but unsolicited and untargeted.</dd> <dt>PMSI TunnelAttribute) for BUM traffic purpose will allAttribute (PTA):</dt><dd>An optional transitive BGP attribute that may bereferredattached toas I-PMSIPMSI/Leaf A-Droutes. Depending onroutes to provide information for a PMSI tunnel.</dd> <dt>IBGP:</dt><dd>Internal BGP. Provides communications with neighbors in thecontext, theysame AS.</dd> <dt>EBGP:</dt><dd>External BGP. Provides communications with neighbors in different ASes.</dd> <dt>RT:</dt><dd>Route Target. Enables the management of routing information.</dd> </dl> <!-- [rfced] "Terminology" section: For ease of the reader, we added definitions of "IBGP" and "EBGP", per Section 3.2.3 of RFC 1164. We also added a definition of "RT" (per RFC 7117), as "RT" is used later in this document but is not defined. Please let us know any objections. Original: ... o PMSI Tunnel Attribute (PTA): An optional transitive BGP attribute that may beused interchangeably. </t-->attached to PMSI/Leaf A-D routes to provide information for a PMSI tunnel. Currently: ... PMSI Tunnel Attribute (PTA): An optional transitive BGP attribute that may be attached to PMSI/Leaf A-D routes to provide information for a PMSI tunnel. IBGP: Internal BGP. Provides communications with neighbors in the same AS. EBGP: External BGP. Provides communications with neighbors in different ASes. RT: Route Target. Enables the management of routing information. --> </section> </section> <sectiontitle="Tunnel Segmentation" anchor="segmentation">anchor="segmentation" numbered="true" toc="default"> <name>Tunnel Segmentation</name> <t>MVPN provider tunnels and EVPN/VPLS BUM provider tunnels, which are referred to as MVPN/EVPN/VPLS provider tunnels in this document for simplicity, can be segmented for technical or administrative reasons, which are summarized in <xreftarget="motivation"/>target="motivation" format="default"/> of this document.[RFC6513]<xref target="RFC6513" format="default"/> and[RFC6514]<xref target="RFC6514" format="default"/> cover MVPNinter-asinter-AS segmentation,[RFC7117]<xref target="RFC7117" format="default"/> covers VPLS multicastinter-asinter-AS segmentation, and[RFC7524] (Seamless<xref target="RFC7524" format="default"/> (seamless MPLSMulticast)multicast) covers inter-area segmentation for bothMVPNMVPNs andVPLS.VPLSs. </t> <t>With tunnel segmentation, different segments of an end-to-end tunnel may have different encapsulationoverhead.overheads. However, the largest overhead of the tunnel caused by an encapsulation method on a particular segment is not different from the case of a non-segmented tunnel with that encapsulation method. This is similar to the case of a network with different link types. </t> <t>There is a difference between MVPN and VPLS multicastinter-asinter-AS segmentation (the VPLS approach is brieflydiscribeddescribed in <xreftarget="interaschanges"/>).target="interaschanges" format="default"/>). For simplicity,EVPNEVPNs will use the same procedures asin MVPN.those for MVPNs. All ASBRs can re-advertise their choice of the best route. Each can become the root of its intra-AS segment and inject traffic it receives from its upstream, while each downstream PE/ASBR will only pick one of the upstream ASBRs as its upstream. This is also the behavior even for VPLS in the case of inter-area segmentation. </t> <t>For inter-area segmentation,[RFC7524]<xref target="RFC7524" format="default"/> requires the use ofInter-area P2MPthe Inter-Area Point-to-Multipoint (P2MP) Segmented Next-Hop Extended Community(S-NH-EC),(S-NH-EC) and the setting of"Leafthe Leaf InformationRequired" LRequired (L) flag in the PTA in certain situations. In the EVPN case, the requirements around the S-NH-EC and thePTA "L"L flag in the PTA differ from[RFC7524]<xref target="RFC7524" format="default"/> to make the segmentation procedures transparent to ingress and egress PEs. <!-- [rfced] "Tunnel Segmentation" section: We found both quoted and unquoted forms of "Leaf Information Required" in this document. We then found "Leaf Information Required (L)" in RFC 6514. We updated this sentence accordingly, and we changed the quoted "Leaf Information Required" in Section 4 to "L flag" (no quotes). Please let us know any objections. Original: For inter-area segmentation, [RFC7524] requires the use of Inter-area P2MP Segmented Next-Hop Extended Community (S-NH-EC), and the setting of "Leaf Information Required" L flag in PTA in certain situations. Currently: For inter-area segmentation, [RFC7524] requires the use of the Inter- Area Point-to-Multipoint (P2MP) Segmented Next-Hop Extended Community (S-NH-EC) and the setting of the Leaf Information Required (L) flag in the PTA in certain situations. --> </t><t>[RFC7524]<t><xref target="RFC7524" format="default"/> assumes that segmentation happens at area borders. However, it could be at "regional" borders, where a region could be a sub-area, or even an entire AS plus its external links (<xreftarget = "region"/>). Thattarget="region" format="default"/>); this would allow for more flexible deployment scenarios(e.g.(e.g., for single-area provider networks). This document extends the inter-area segmentation concept to inter-region segmentation forEVPN.EVPNs. </t> <sectiontitle="Reasonsanchor="motivation" numbered="true" toc="default"> <name>Reasons for TunnelSegmentation" anchor="motivation">Segmentation</name> <t>Tunnel segmentation may be required and/or desiredbecause offor administrative and/or technical reasons. </t> <t>For example, an MVPN/VPLS/EVPNnetworkmay span multipleprovidersproviders, and the end-to-end provider tunnels have to be segmented at and stitched by the ASBRs. Different providers may use different tunnel technologies (e.g., provider A usesIngress Replication [RFC7988],ingress replication <xref target="RFC7988" format="default"/>, provider B uses RSVP-TE P2MP[RFC4875] while<xref target="RFC4875" format="default"/>, and provider C usesmLDP [RFC6388]).Multipoint LDP (mLDP) <xref target="RFC6388" format="default"/>). Even if they use the same tunnel technologylike(e.g., RSVP-TEP2MP,P2MP), it may be impractical to set up the tunnels across provider boundaries. </t> <t>The same situations may apply between the ASes and/or areas of a single provider. For example, the backbone area may use RSVP-TE P2MP tunnels while non-backbone areas may use mLDP tunnels. </t> <t>Segmentation can also be used to divide an AS/area into smaller regions, so that control plane state and/or forwarding plane state/burden can be limited to that of individual regions. For example, instead ofIngress Replicatingingress-replicating to 100 PEs in the entire AS, with inter-area segmentation[RFC7524]<xref target="RFC7524" format="default"/>, a PE only needs to replicate to local PEs andABRs.Area Border Routers (ABRs). The ABRs will further replicate to their downstream PEs and ABRs. This not only reduces the forwarding plane burden, but also reduces theleaf trackingleaf-tracking burden in the control plane.</t> <t>Smaller regions also have<!-- [rfced] "Reasons for Tunnel Segmentation" section: For ease of thebenefit that,reader, we expanded "ABR" as "Area Border Router" per the second sentence in Section 6.1 ('However, if "area" is replaced by "region" and "ABR" is replaced by "RBR" ...'). Please let us know any objections. Original: For example, instead of Ingress Replicating to 100 PEs in the entire AS, with inter-area segmentation [RFC7524] a PE only needs to replicate to local PEs and ABRs. Currently: For example, instead of ingress-replicating to 100 PEs in the entire AS, with inter-area segmentation [RFC7524] a PE only needs to replicate to local PEs and Area Border Routers (ABRs). --> </t> <t>In the case of tunnel aggregation, smaller regions provide the benefit of making itiseasier to find congruence among the segments of different constituent (service) tunnels and the resulting aggregation (base) tunnel in a region. This leads to better bandwidth efficiency, because the more congruent they are, the fewer leaves of the base tunnel need to discard traffic when a service tunnel's segment does not need to receive the traffic (yet it is receiving the traffic due to aggregation). </t> <t>Another advantage of the smaller region is smallerBIER [RFC8279] sub-domains.Bit Index Explicit Replication (BIER) subdomains <xref target="RFC8279" format="default"/>. With BIER, packets carry a BitString, in which the bits correspond to edge routers thatneedsneed to receive traffic. Smallersub-domainssubdomains means that smaller BitStrings can be used without having to send multiple copies of the same packet. </t><!-- <t>Finally, EVPN tunnel segmentation can be used for EVPN DCIs, as discussed in <xref target="dci"/>. It follows the same concepts discussed above. </t> --> </section></section> </section> <sectiontitle="Additionalanchor="routes" numbered="true" toc="default"> <name>Additional Route Types of EVPNNLRI" anchor="routes"> <t>[RFC7432]NLRI</name> <t><xref target="RFC7432" format="default"/> defines the format of EVPN NLRI asthe following: <figure> <artwork>follows: </t> <artwork name="" type="" align="left" alt=""><![CDATA[ +-----------------------------------+ | Route Type (1 octet) | +-----------------------------------+ | Length (1 octet) | +-----------------------------------+ | Route Type specific (variable) | +-----------------------------------+</artwork> </figure>]]></artwork> <t> Sofarfar, eight route types have been defined in[RFC7432],<xreftarget="I-D.ietf-bess-evpn-prefix-advertisement"/>,target="RFC7432" format="default"/>, <xref target="RFC9136" format="default"/>, and <xreftarget="I-D.ietf-bess-evpn-igmp-mld-proxy"/>: <figure> <artwork>target="RFC9251" format="default"/>: </t> <!-- [rfced] Please note that we updated some of these names to match what appears at <https://www.iana.org/assignments/evpn/>. Please let us know if corrections are needed. Original: So far eight route types have been defined in [RFC7432], [I-D.ietf-bess-evpn-prefix-advertisement], and [I-D.ietf-bess-evpn-igmp-mld-proxy]: + 1 - Ethernet Auto-Discovery (A-D) route + 2 - MAC/IP Advertisement route + 3 - Inclusive Multicast Ethernet Tag route + 4 - Ethernet Segment route + 5 - IP Prefix Route + 6 - Selective Multicast Ethernet Tag Route + 7 - Multicast Join Synch Route + 8 - Multicast Leave Synch Route</artwork> </figure>Current (note that row separators (hyphyens) have been removed so the list can be included within an XML comment): So far, eight route types have been defined in [RFC7432], [RFC9136], and [RFC9251]: +=======+=========================================+ | Value | Description | +=======+=========================================+ | 1 | Ethernet Auto-discovery | | 2 | MAC/IP Advertisement | | 3 | Inclusive Multicast Ethernet Tag | | 4 | Ethernet Segment | | 5 | IP Prefix | | 6 | Selective Multicast Ethernet Tag Route | | 7 | Multicast Membership Report Synch Route | | 8 | Multicast Leave Synch Route | --> <table anchor="tab-0"> <!-- Assign an anchor --> <name>Pre-existing Route Types</name> <!-- Give the table a title --> <thead> <tr> <th>Value</th> <!-- <th>: header --> <th>Description</th> </tr> </thead> <tbody> <!-- The rows --> <tr> <td>1</td> <td>Ethernet Auto-discovery</td> </tr> <tr> <td>2</td> <td>MAC/IP Advertisement</td> </tr> <tr> <td>3</td> <td>Inclusive Multicast Ethernet Tag</td> </tr> <tr> <td>4</td> <td>Ethernet Segment</td> </tr> <tr> <td>5</td> <td>IP Prefix</td> </tr> <tr> <td>6</td> <td>Selective Multicast Ethernet Tag Route</td> </tr> <tr> <td>7</td> <td>Multicast Membership Report Synch Route</td> </tr> <tr> <td>8</td> <td>Multicast Leave Synch Route</td> </tr> </tbody> </table> <t> This document defines three additional route types: </t> <!-- [rfced] Is "route" needed as part of the names, since these are registered in the "EVPN Route Types" registry? If you prefer to keep "route" as part of the description, should it be capitalized (i.e., Route) to match the descriptions for values 6-8? We will udpate the IANA Considerations section based on your reply. Original: This document defines three additional route types:<figure> <artwork>+ 9 - Per-Region I-PMSI A-D route + 10 - S-PMSI A-D route + 11 - Leaf A-D route</artwork> </figure>--> <table anchor="tab-0a"> <!-- Assign an anchor --> <name>New Route Types</name> <!-- Give the table a title --> <thead> <tr> <th>Value</th> <!-- <th>: header --> <th>Description</th> </tr> </thead> <tbody> <!-- The rows --> <tr> <td>9</td> <td>Per-Region I-PMSI A-D route</td> </tr> <tr> <td>10</td> <td>S-PMSI A-D route</td> </tr> <tr> <td>11</td> <td>Leaf A-D route</td> </tr> </tbody> </table> <!-- <artwork name="" type="" align="left" alt=""><![CDATA[ 9 - Per-Region I-PMSI A-D route 10 - S-PMSI A-D route 11 - Leaf A-D route ]]></artwork> --> <t> The "Route Type specific" field of the Type 9 and Type 10 EVPN NLRIs starts with a Type 1 RD (Route Distinguisher), whose Administrator sub-field <bcp14>MUST</bcp14> match that of the RD in all current non-Leaf A-D (<xref target="leaf" format="default"/>) EVPN routes from the same advertising router for a given EVPN instance (EVI). <!-- [rfced] Section 3: For ease of the reader, we defined "RD" as "Route Distinguisher" per RFC 9251, which says "The Route Distinguisher (RD) SHOULD be a Type 1 RD [RFC4364]." We also defined "EVI" as "EVPN instance" per RFCs 9251 and 9252. Please let us know any objections. Also, please note that the citation "non-Leaf A-D (Section 3.3)" is confusing, as we do not see any mention of "non-Leaf" in Section 3.3. Would the "Possibly" text below help to clarify? If not, please provide clarifying text. Original: The "Route Type specific" field of the type 9 and type 10 EVPN NLRIs starts with a type 1 RD, whose Administrator sub-field MUST match that of the RD in all current non-Leaf A-D(<xref target="leaf"/>)(Section 3.3) EVPN routes from the same advertising router for a given EVI. Currently: The "Route Type specific" field of the Type 9 and Type 10 EVPN NLRIs starts with a Type 1 RD (Route Distinguisher), whose Administrator sub-field MUST match that of the RD in all current non-Leaf A-D (Section 3.3) EVPN routes from the same advertising router for a given EVPN instance (EVI). Possibly: The "Route Type specific" field of the Type 9 and Type 10 EVPN NLRIs starts with a Type 1 RD (Route Distinguisher), whose Administrator sub-field MUST match that of the RD in all current EVPN routes that are not Leaf A-D routes (Section 3.3), i.e., non-Leaf A-D routes from the same advertising router for a given EVPN instance (EVI). --> </t> <sectiontitle="Per-Regionanchor="per-region" numbered="true" toc="default"> <name>Per-Region I-PMSI A-Droute" anchor="per-region">Route</name> <t>ThePer-regionper-region I-PMSI A-D route has the following format. Its usage is discussed in <xreftarget="aggregation"/>. <figure> <artwork>target="aggregation" format="default"/>. </t> <artwork name="" type="" align="left" alt=""><![CDATA[ +-----------------------------------+ | RD (8 octets) | +-----------------------------------+ | Ethernet Tag ID (4 octets) | +-----------------------------------+ | Region ID (8 octets) | +-----------------------------------+</artwork> </figure>]]></artwork> <t> The Region ID identifies the region and is encodedjust as howin the same way that anExtended CommunityEC is encoded, as detailed in <xreftarget="aggregation"/>.target="aggregation" format="default"/>. </t> </section> <sectiontitle="S-PMSInumbered="true" toc="default"> <name>S-PMSI A-Droute">Route</name> <t>The S-PMSI A-D route has the following format:<figure> <artwork></t> <artwork name="" type="" align="left" alt=""><![CDATA[ +-----------------------------------+ | RD (8 octets) | +-----------------------------------+ | Ethernet Tag ID (4 octets) | +-----------------------------------+ | Multicast Source Length (1 octet) | +-----------------------------------+ | Multicast Source(Variable)(variable) | +-----------------------------------+ | Multicast Group Length (1 octet) | +-----------------------------------+ | Multicast Group(Variable)(variable) | +-----------------------------------+ |Originator's Addr Length (1 octet) | +-----------------------------------+ |Originator's Addr (4 or 16 octets) | +-----------------------------------+</artwork> </figure>]]></artwork> <t> Other than the addition of the Ethernet Tag ID and Originator's AddrLength,Length fields, it is identical to the S-PMSI A-D route as defined in[RFC7117].<xref target="RFC7117" format="default"/>. The procedures specified in[RFC7117]<xref target="RFC7117" format="default"/> also apply (including wildcard functionality), except that the granularity level is per Ethernet Tag. </t> </section> <sectiontitle="Leafanchor="leaf" numbered="true" toc="default"> <name>Leaf A-Droute" anchor="leaf">Route</name> <t>The Route Type specific field of a Leaf A-D route consists of the following:<figure> <artwork></t> <artwork name="" type="" align="left" alt=""><![CDATA[ +-----------------------------------+ | Route Key (variable) | +-----------------------------------+ |Originator's Addr Length (1 octet) | +-----------------------------------+ |Originator's Addr (4 or 16 octets) | +-----------------------------------+</artwork> </figure>]]></artwork> <t> A Leaf A-D route is originated in response to a PMSI route, which could be anInclusive Multicast TagIMET A-D route, a per-region I-PMSI A-D route, an S-PMSI A-D route, or some other types of routes that may be defined in the future thattriggerstrigger Leaf A-D routes. The Route Key is the NLRI of the route for which this Leaf A-D route is generated. <!-- [rfced] Section 3.3: As it appears that "Inclusive Multicast Tag route" means "IMET A-D route" and "triggers" refers to the routes and not to the future, we updated this sentence accordingly. If this is incorrect, please provide clarifying text. (FYI that we don't see "Inclusive Multicast Tag" used anywhere else in this document or in any published RFC except for RFC 9489.) Original: A Leaf A-D route is originated in response to a PMSI route, which could be an Inclusive Multicast Tag route, a per-region I-PMSI A-D route, an S-PMSI A-D route, or some other types of routes that may be defined in the future that triggers Leaf A-D routes. Currently: A Leaf A-D route is originated in response to a PMSI route, which could be an IMET A-D route, a per-region I-PMSI A-D route, an S-PMSI A-D route, or some other types of routes that may be defined in the future that trigger Leaf A-D routes. --> </t> <t>The general proceduresoffor Leaf A-Droute areroutes were first specified in[RFC6514]<xref target="RFC6514" format="default"/> forMVPN.MVPNs. The principles therein apply toVPLSVPLSs andEVPNEVPNs as well.[RFC7117] has<xref target="RFC7117" format="default"/> provides detailsforregarding VPLSMulticast,multicast, and this document points out some specifics forEVPN, e.g.EVPNs, e.g., in <xreftarget="inter-as"/>.target="inter-as" format="default"/>. </t> </section> </section> <sectiontitle="Selective Multicast">numbered="true" toc="default"> <name>Selective Multicast</name> <t><xreftarget="I-D.ietf-bess-evpn-igmp-mld-proxy"/>target="RFC9251" format="default"/> specifies procedures for EVPN selective forwarding of IP multicast traffic using SMET routes. It assumes that selective forwarding is always used withIRingress replication for all flows (though the same signaling can also be used for an ingress PE tofind outlearn the set of egress PEs for selective forwarding with BIER).An NVEA Network Virtualization Edge (NVE) proxies the IGMP/MLD state ("MLD" stands for "Multicast Listener Discovery") that it learns on its ACs to (C-S,C-G) or (C-*,C-G) SMET routes that advertises to other NVEs, and a receiving NVE converts the SMET routes back to IGMP/MLD messages and sends them out of its ACs. The receiving NVE also uses the SMET routes to identify which NVEs need to receive traffic for a particular (C-S,C-G) or (C-*,C-G) to achieve selective forwarding using ingress replication or BIER. <!-- [rfced] Section 4: a) As it appears that "IR" stands for "ingress replication" per RFC 9251 and is only used three times in this document, we spelled it out per the rest of this document. If this is incorrect, please provide the correct definition for "IR". Original It assumes selective forwarding is always used with IR for all flows (though the same signaling can also be used for an ingress PE to find out the set of egress PEs for selective forwarding with BIER). ... The receiving NVE also uses the SMET routes to identify which NVEs need to receive traffic for a particular (C-S,C-G) or (C-*,C-G) to achieve selective forwarding using IR or BIER. ... For that, or for tunnel types other than IR/BIER, S-PMSI/Leaf A-D procedures defined for Selective Multicast for VPLS in [RFC7117] are used. Currently: It assumes that selective forwarding is always used with ingress replication for all flows (though the same signaling can also be used for an ingress PE to learn the set of egress PEs for selective forwarding with BIER). ... The receiving NVE also uses the SMET routes to identify which NVEs need to receive traffic for a particular (C-S,C-G) or (C-*,C-G) to achieve selective forwarding using ingress replication or BIER. ... For that, or for tunnel types other than ingress replication or BIER, S-PMSI/Leaf A-D procedures defined for selective multicast for VPLS in [RFC7117] are used. b) Does "AC" stand for "Attachment Circuit", "Access Circuit", or something else? Also, to what does "advertises" refer - the NVE, the state, or the routes? Please note in the meantime that for ease of the reader we expanded "NVE" as "Network Virtualization Edge" per companion draft-ietf-bess-evpn-optimized-ir and "MLD" as "Multicast Listener Discovery" per RFC 9251. Original: An NVE proxies the IGMP/MLD state that it learns on its ACs to (C-S,C-G) or (C-*,C-G) SMET routes that advertises to other NVEs, and a receiving NVE converts the SMET routes back to IGMP/MLD messages and sends them out of its ACs. Currently: A Network Virtualization Edge (NVE) proxies the IGMP/MLD state ("MLD" stands for "Multicast Listener Discovery") that it learns on its ACs to (C-S,C-G) or (C-*,C-G) SMET routes that advertises to other NVEs, and a receiving NVE converts the SMET routes back to IGMP/MLD messages and sends them out of its ACs. --> </t> <t>With the above procedures, selective forwarding is done for allflowsflows, and the SMET routes are advertised for all flows. It is possible that an operator may not want to track all those (C-S, C-G) or (C-*,C-G)statestates on the NVEs, and the multicast traffic pattern allows inclusive forwarding for most flows while selective forwarding is needed only for a few high-rate flows. For that, or for tunnel types other thanIR/BIER,ingress replication or BIER, S-PMSI/Leaf A-D procedures defined forSelective Multicastselective multicast for VPLS in[RFC7117]<xref target="RFC7117" format="default"/> are used. Other than that different route types and formats are specified with an EVPN SAFI for S-PMSI A-D and Leaf A-D routes (<xreftarget="routes"/>),target="routes" format="default"/>), all procedures specified in[RFC7117]<xref target="RFC7117" format="default"/> with respect toSelective Multicastselective multicast apply toEVPNEVPNs as well, including wildcard procedures. In a nutshell, a source NVE advertises S-PMSI A-D routes to announce the tunnels used for certain flows, and receiving NVEs either join the announced PIM/mLDP tunnel or respond with Leaf A-D routes if theLeaf Information RequiredL flag is set in the S-PMSI A-D route's PTA (so that the source NVE can include them as tunnel leaves). <!-- [rfced] Section 4: a) To what does "that" refer in the "For that ..." sentence? Original (the previous sentence is included for context): It is possible that an operator may not want to track all those (C-S, C-G) or (C-*,C-G) state on the NVEs, and the multicast traffic pattern allows inclusive forwarding for most flows while selective forwarding is needed only for a few high-rate flows. For that, or for tunnel types other than IR/BIER, S-PMSI/Leaf A-D procedures defined for Selective Multicast for VPLS in [RFC7117] are used. b) This sentence does not parse. Are some words or punctuation missing? For example, does "Other than that different route types" mean "Other than the fact that different route types", "Other than that, different route types", or something else? Please provide clarifying text. Original: Other than that different route types and formats are specified with EVPN SAFI for S-PMSI A-D and Leaf A-D routes (Section 3), all procedures in [RFC7117] with respect to Selective Multicast apply to EVPN as well, including wildcard procedures. --> </t> <t>An optimization to the[RFC7117]procedures provided in <xref target="RFC7117" format="default"/> may be applied. Even if a source NVE sets the L flag to request Leaf A-D routes, an egress NVEMAY<bcp14>MAY</bcp14> omit the Leaf A-D route if it has already advertised a corresponding SMET route, and the source NVEMUST<bcp14>MUST</bcp14> use that in lieu of the Leaf A-D route. </t> <t>The optional optimizations specified forMVPNMVPNs in <xreftarget="RFC8534"/>target="RFC8534" format="default"/> are also applicable toEVPNEVPNs when the procedures for S-PMSI/Leaf A-D routesproceduresare used for EVPN selective multicast forwarding. </t> </section> <sectiontitle="Inter-AS Segmentation" anchor="inter-as">anchor="inter-as" numbered="true" toc="default"> <name>Inter-AS Segmentation</name> <sectiontitle="Differencesanchor="interaschanges" numbered="true" toc="default"> <name>Differences from Section 7.2.2 of[RFC7117] WhenRFC 7117 when Applied toEVPN" anchor="interaschanges">EVPNs</name> <t>The first paragraph ofSection 7.2.2.2 of [RFC7117]<xref target="RFC7117" sectionFormat="of" section="7.2.2.2"/> says:<figure> <artwork> "...</t> <!-- DNE; verified --> <blockquote> ... The best route procedures ensure that if multiple ASBRs, in an AS, receive the same Inter-AS A-D route from their EBGP neighbors, only one of these ASBRs propagates this route in Internal BGP (IBGP). This ASBR becomes the root of the intra-AS segment of the inter-AS tree and ensures that this is the only ASBR that accepts traffic into this AS from the inter-AStree." </artwork> </figure>tree. </blockquote> <t> The above VPLS behavior requires complicatedVPLS specificVPLS-specific procedures for the ASBRs to reach agreement. ForEVPN,EVPNs, a different approach isused andused; the abovequotedtext from <xref target="RFC7117"/> is not applicable toEVPN.EVPNs. </t> <t>With the different approach forEVPN/MVPN,EVPNs/MVPNs, each ASBR will re-advertise its received Inter-AS A-D route to its IBGP peers and becomes the root of an intra-AS segment of the inter-AS tree. The intra-AS segment rooted at one ASBR is disjointwithfrom another intra-AS segment rooted at another ASBR. This is the same as the procedures for S-PMSI routes in[RFC7117]<xref target="RFC7117" format="default"/> itself. </t> <t>The following bullet inSection 7.2.2.2 of [RFC7117]<xref target="RFC7117" sectionFormat="of" section="7.2.2.2"/> does not apply toEVPN. <figure> <artwork> + IfEVPNs. </t> <!-- DNE; verified --> <blockquote> <ul><li>If the ASBR uses ingress replication to instantiate the intra-AS segment of the inter-AS tunnel, the re-advertised routeMUST NOT<bcp14>MUST NOT</bcp14> carry the PMSI Tunnelattribute. </artwork> </figure> </t>attribute.</li></ul> </blockquote> <t>The following bullet inSection 7.2.2.2 of [RFC7117]: <figure> <artwork> +<xref target="RFC7117" sectionFormat="of" section="7.2.2.2"/>: </t> <!-- DNE; verified --> <blockquote><ul><li> If the ASBR uses a P-multicast tree to instantiate the intra-AS segment of the inter-AS tunnel, the PMSI Tunnel attributeMUST<bcp14>MUST</bcp14> contain the identity of the tree that is used to instantiate the segment (note that the ASBR could create the identity of the tree prior to the actual instantiation of the segment). If, in order to instantiate the segment, the ASBR needs to know the leaves of the tree, then the ASBR obtains this information from the A-D routes received from other PEs/ASBRs in the ASBR's ownAS. </artwork> </figure> </t>AS.</li></ul> </blockquote> <t>is changed to the following when applied toEVPN: <figure> <artwork> "The PMSI Tunnel attribute MUSTEVPNs: </t> <blockquote><ul><li> The PTA <bcp14>MUST</bcp14> specify the tunnel for the segment. If and only if, in order to establish the tunnel, the ASBR needs to know the leaves of the tree, then the ASBRMUST<bcp14>MUST</bcp14> set the L flag to 1 in the PTA to trigger Leaf A-D routes from egress PEs and downstream ASBRs. ItMUST<bcp14>MUST</bcp14> be (auto-)configured with an import RT, which controls acceptance ofleafLeaf A-D routes by theASBR." </artwork> </figure> </t>ASBR.</li></ul> </blockquote> <t>Accordingly, the following paragraph inSection 7.2.2.4 of [RFC7117]: <figure> <artwork> "If<xref target="RFC7117" sectionFormat="of" section="7.2.2.4"/>: </t> <!-- DNE; verified --> <blockquote> If the received Inter-AS A-D route carries the PMSI Tunnel attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR that originated the routeMUST<bcp14>MUST</bcp14> establish an RSVP-TE P2MP LSP with the local PE/ASBR as a leaf. This LSPMAY<bcp14>MAY</bcp14> have been established before the local PE/ASBR receives the route, or itMAY<bcp14>MAY</bcp14> be established after the local PE receives theroute." </artwork> </figure>route. </blockquote> <t> is changed to the following when applied toEVPN:EVPNs: </t><t> "If<blockquote> If the received Inter-AS A-D route has the L flag set in its PTA, then a receiving PEMUST<bcp14>MUST</bcp14> originate a corresponding Leaf A-D route, while a receiving ASBRMUST<bcp14>MUST</bcp14> originate a corresponding Leaf A-D route if and only if it received and imported one or more corresponding Leaf A-D routes from its downstream IBGP or EBGP peers, or it has non-null downstream forwarding state for the PIM/mLDP tunnel that instantiates its downstream intra-AS segment. The targeted ASBR for the Leaf A-D route, which (re-)advertised the Inter-AS A-D route,MUST<bcp14>MUST</bcp14> establish a tunnel to the leaves discovered by the Leaf A-Droutes." </t>routes. </blockquote> <!-- [rfced] Section 5.1: We had trouble following this sentence. If neither suggestion below is correct, please clarify the purpose of the comma in "... peers, or it has". Original: "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, while a receiving ASBR MUST originate a corresponding Leaf A-D route if and only if it received and imported one or more corresponding Leaf A-D routes from its downstream IBGP or EBGP peers, or it has non-null downstream forwarding state for the PIM/mLDP tunnel that instantiates its downstream intra-AS segment. ..." Suggestion #1 ("if and only if ... peers or if it has"): | 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, | while a receiving ASBR MUST originate a corresponding Leaf A-D | route if and only if it received and imported one or more | corresponding Leaf A-D routes from its downstream IBGP or EBGP | peers or if it has non-null downstream forwarding state for the | PIM/mLDP tunnel that instantiates its downstream intra-AS segment. ... Suggestion #2 ("if and only if ... peers; otherwise, it has"): | 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, | while a receiving ASBR MUST originate a corresponding Leaf A-D | route if and only if it received and imported one or more | corresponding Leaf A-D routes from its downstream IBGP or EBGP | peers; otherwise, it has non-null downstream forwarding state for | the PIM/mLDP tunnel that instantiates its downstream intra-AS | segment. ... --> </section> <sectiontitle="I-PMSIanchor="leaf-tracking" numbered="true" toc="default"> <name>I-PMSI LeafTracking" anchor="leaf-tracking">Tracking</name> <t>An ingress PE does not set the L flag in itsInclusive Multicast Ethernet Tag (IMET)IMET A-D route's PTA, even withIngress Replicationingress replication or RSVP-TE P2MP tunnels. It does not rely on the Leaf A-D routes to discover leaves in its AS, andSection 11.2 of [RFC7432]<xref target="RFC7432" sectionFormat="of" section="11.2"/> explicitly states that the L flag must be set tozero.0. </t> <t>An implementation of[RFC7432]<xref target="RFC7432" format="default"/> might have used the Originating Router's IP Address field of the IMET A-D routes to determine theleaves,leaves or might have used the Next Hop field instead. Within the same AS, both will lead to the same result. </t> <t>With segmentation, an ingress PEMUST<bcp14>MUST</bcp14> determine the leaves in its AS from the BGP next hops in all its received IMET A-D routes, so it does not have to set the L flagsetto request Leaf A-D routes. PEs within the same AS will all have different next hops in their IMET A-D routes(hence(and hence will all be considered as leaves), and PEs from other ASes will have the next hop in their IMET A-D routes set to addresses of ASBRs in this localAS, henceAS; hence, only those ASBRs will be considered as leaves (as proxies for those PEs in other ASes). Note that in the case ofIngress Replication,ingress replication, when an ASBR re-advertises IMET A-D routes to IBGP peers, itMUST<bcp14>MUST</bcp14> advertise the same label for all those routes for the same Ethernet Tag ID and the same EVI. Otherwise, duplicated copies will be sent by the ingress PE and received by egress PEs in other regions. For the same reason, when an ingress PE builds its flooding list, if multiple routes have the same (nexthop, label)tupletuple, theyMUST<bcp14>MUST</bcp14> only be added as a single branch in the flooding list. <!-- [rfced] Section 5.2: a) We changed "set the L flag set" in this sentence to "set the L flag". If this is incorrect, please clarify the text. Original: 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 does not have to set the L flag set to request Leaf A-D routes. Currently: 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 does not have to set the L flag to request Leaf A-D routes. b) As it appears that "all those" refers to the routes and not to the IBGP peers, we updated this sentence accordingly. If this is not correct, please clarify "all those". Original: Note that in case of Ingress Replication, when an ASBR re-advertises IMET A-D routes to IBGP peers, it MUST advertise the same label for all those for the same Ethernet Tag ID and the same EVI. Currently: Note that in the case of ingress replication, when an ASBR re-advertises IMET A-D routes to IBGP peers, it MUST advertise the same label for all those routes for the same Ethernet Tag ID and the same EVI. --> </t> </section> <sectiontitle="Backward Compatibility" anchor="compatibility">anchor="compatibility" numbered="true" toc="default"> <name>Backward Compatibility</name> <t>The above procedures assume that all PEs are upgraded to support the segmentation procedures:<list style="symbols"> <t>An</t> <ul spacing="normal"> <li>An ingress PE uses the Next Hop and not the Originating Router's IP Address to determine leaves for the I-PMSI tunnel.</t> <t>An</li> <li>An egress PE sends Leaf A-D routes in response to I-PMSI routes, if the PTA has the L flag set by the re-advertising ASBR.</t> <t>In</li> <li>In the case ofIngress Replication,ingress replication, when an ingress PE builds its flooding list, multiple I-PMSI routes may have the same (nexthop, label)tupletuple, and only a single branch for those routes will be added in the flooding list.</t> </list> </t></li> </ul> <t>If a deployment has legacy PEs thatdoesdo not support the above, then a legacy ingress PE would include all PEs (including those in remote ASes) as leaves of the inclusive tunnel and try to send traffic to them directly (no segmentation), which is eitherundesiredundesirable ornot possible;impossible; a legacy egress PE would not send Leaf A-D routes so the ASBRs would not know to send external traffic to them. </t> <t>If thisbackward compatibilitybackward-compatibility problem needs to be addressed, the following procedureMUST<bcp14>MUST</bcp14> be used (see <xreftarget="aggregation"/>target="aggregation" format="default"/> for per-PE/AS/region I-PMSI A-D routes):<list style="symbols"> <t>An</t> <ul spacing="normal"> <li>An upgraded PE indicates in its per-PE I-PMSI A-D route that it supports the new procedures. This is done by setting a flag bit in the EVPN Multicast Flags Extended Community.</t> <t>All</li> <li>All per-PE I-PMSI A-D routes are restricted to the local AS and not propagated to external peers.</t> <t>The</li> <li>The ASBRs in an AS originate per-region I-PMSI A-D routes and advertise them to their external peers to specify tunnels used to carry traffic from the local AS to other ASes. Depending on the types of tunnels being used, the L flag in the PTA may be set, in which case the downstream ASBRs and upgraded PEs will send Leaf A-D routes to pull traffic from their upstream ASBRs. In a particular downstream AS, one of the ASBRs is elected, based on the per-region I-PMSI A-D routes for a particular source AS, to send traffic from that source AS to legacy PEs in the downstream AS. The traffic arrives at the elected ASBR on the tunnel announced in the best per-region I-PMSI A-D route for the source AS, that the ASBR has selected of all those that it received over EBGP or IBGP sessions. The election procedure is described in <xreftarget="election"/>. </t> <t>Intarget="election" format="default"/>. <!-- [rfced] Section 5.3: This sentence is difficult to parse. If the suggested text is not correct, please clarify "the best per-region I-PMSI A-D route for the source AS, that the ASBR has selected of all those". Original: The traffic arrives at the elected ASBR on the tunnel announced in the best per-region I-PMSI A-D route for the source AS, that the ASBR has selected of all those that it received over EBGP or IBGP sessions. Suggested: The traffic arrives at the elected ASBR on the tunnel announced in the best per-region I-PMSI A-D route for the source AS, as selected by the ASBR from all the routes that it received over EBGP or IBGP sessions. --> </li> <li>In an ingress/upstream AS, if and only if an ASBR has active downstream receivers (PEs and ASBRs), which are learned either explicitly via Leaf A-D routes or implicitly via PIM Join or mLDP label mapping, the ASBR originates a per-PE I-PMSI A-D route (i.e., a regular IMET route) into the local AS and stitches incoming per-PE I-PMSI tunnels into its per-region I-PMSI tunnel. With this, it gets traffic from local PEs and sends the traffic to other ASes via the tunnel announced in its per-region I-PMSI A-D route. <!-- [rfced] Sections 5.3 and 6.3: Do these two instances of "With this," mean "Using this technique", "Via this process", or something else? Also, are all per-PE I-PMSI A-D routes regular Inclusive Multicast Ethernet Tag routes, or should "i.e." ("that is") be "e.g." ("for example")? Original (previous sentences are included for context): o In an ingress/upstream AS, if and only if an ASBR has active downstream receivers (PEs and ASBRs), which are learned either explicitly via Leaf A-D routes or implicitly via PIM join or mLDP label mapping, the ASBR originates a per-PE I-PMSI A-D route (i.e., regular Inclusive Multicast Ethernet Tag route) into the local AS, and stitches incoming per-PE I-PMSI tunnels into its per-region I-PMSI tunnel. With this, it gets traffic from local PEs and send to other ASes via the tunnel announced in itsper-regionper- region I-PMSI A-D route.</t> </list> </t>... Similar to [RFC7524], the upstream RBR MUST (auto-)configure a RT with the Global Administrator field set to the Next Hop in the re- advertised I/S-PMSI A-D route and with the Local Administrator field set to 0. With this, the mechanisms specified in [RFC4684] for constrained BGP route distribution can be used along with this specification to ensure that only the needed PE/ABR will have to process a said Leaf A-D route. --> </li> </ul> <t>Note that even if there are no backward-compatibility issues, the use of per-region I-PMSI A-D routes provides the benefit of keeping all per-PE I-PMSI A-D routes in their local ASes, greatly reducing the flooding of the routes and their corresponding Leaf A-D routes (when needed) and reducing the number of inter-AS tunnels. <!-- [rfced] Section 5.3: As this instance of "per-region I-PMSI" was the only instance not followed by "A-D route(s)" or "tunnel(s)", we added "A-D routes". If this is incorrect, please let us know whether "per-region I-PMSI tunnels" or something else would be appropriate. Original: Note that, even if there is no backward compatibility issue, the use of per-region I-PMSI has the benefit of keeping all per-PE I-PMSI A-D routes in their local ASes, greatly reducing the flooding of the routes and their corresponding Leaf A-D routes (when needed), and the number of inter-as tunnels. Currently: Note that even if there are no backward-compatibility issues, the use of per-region I-PMSI A-D routes provides the benefit of keeping all per-PE I-PMSI A-D routes in their local ASes, greatly reducing the flooding of the routes and their corresponding Leaf A-D routes (when needed) and reducing the number of inter-AS tunnels. --> </t> <sectiontitle="Designatedanchor="election" numbered="true" toc="default"> <name>Designated ASBRElection" anchor="election">Election</name> <t>When an ASBR re-advertises a per-region I-PMSI A-D route into an AS in which a designated ASBR needs to be used to forward traffic to the legacy PEs in the AS, itMUST<bcp14>MUST</bcp14> include aDFDesignated Forwarder (DF) Election EC. The EC and its useisare specified in <xreftarget="RFC8584"/>.target="RFC8584" format="default"/>. The AC-DF bit in the DF Election ECMUST<bcp14>MUST</bcp14> be cleared. If it is known that no legacy PEs exist in the AS, the ASBRMUST NOT<bcp14>MUST NOT</bcp14> include the EC andMUST<bcp14>MUST</bcp14> remove the DF Election EC if one is carried in the per-region I-PMSI A-D routes that it receives. Note that this is done for each set of per-region I-PMSI A-D routes with the same NLRI. <!-- [rfced] Section 5.3.1: We expanded "DF" as "Designated Forwarder" per RFC 9251. If this is incorrect, please provide the correct definition. Original: When an ASBR re-advertises a per-region I-PMSI A-D route into an AS in which a designated ASBR needs to be used to forward traffic to the legacy PEs in the AS, it MUST include a DF Election EC. Currently: When an ASBR re-advertises a per-region I-PMSI A-D route into an AS in which a designated ASBR needs to be used to forward traffic to the legacy PEs in the AS, it MUST include a Designated Forwarder (DF) Election EC. --> </t> <t>Based on the procedures specified in <xreftarget="RFC8584"/>,target="RFC8584" format="default"/>, an election algorithm is determined according to the DF Election ECs carried in the set of per-region I-PMSI routes of the same NLRIre-adverisedre-advertised into the AS. The algorithm is then applied to a candidate list, which is the set of ASBRs that re-advertised the per-region I-PMSI routes of the same NLRI carrying the DF Election EC. </t> </section> </section> </section> <sectiontitle="Inter-Region Segmentation" anchor="inter-region">anchor="inter-region" numbered="true" toc="default"> <name>Inter-Region Segmentation</name> <sectiontitle="Area/ASanchor="region" numbered="true" toc="default"> <name>Area/AS vs.Region" anchor="region"> <t>[RFC7524] is forRegion</name> <t><xref target="RFC7524" format="default"/> addresses MVPN/VPLS inter-area segmentation and does not explicitly coverEVPN.EVPNs. However, if "area" is replaced by "region" and "ABR" is replaced by "RBR" (Regional BorderRouter)Router), then everything stillworks,works and can be applied toEVPNEVPNs as well. </t> <t>A region can be a sub-area, or it can be an entireASAS, including its external links. Instead of automatic region definition based on IGP areas, a region would be defined as a BGP peer group. In fact, even withIGP area baseda regiondefinition,definition based on an IGP area, a BGP peer group listing the PEs and ABRs in an area is still needed. <!-- [rfced] Section 6.1: Does "Instead of automatic region definition" mean "Instead of automatically defining a region" or something else? If the suggested text is not correct, please clarify. Original: Instead of automatic region definition based on IGP areas, a region would be defined as a BGP peer group. Suggested: Instead of automatically defining a region based on IGP areas, a region would be defined as a BGP peer group. --> </t> <t>Consider the following example diagram forinter-asinter-AS segmentation:<figure> <artwork></t> <artwork name="" type="" align="left" alt=""><![CDATA[ --------- ------ --------- / \ / \ / \ / \ / \ / \ | PE1 o ASBR1 -- ASBR2 ASBR3 -- ASBR4 o PE2 | \ / \ / \ / \ / \ / \ / --------- ------ --------- AS 100 AS 200 AS 300 |-----------|--------|---------|--------|------------| segment1 segment2 segment3 segment4 segment5</artwork> </figure>]]></artwork> <t> Theinter-asinter-AS segmentation procedures specified so far([RFC6513] [RFC6514], [RFC7117],(<xref target="RFC6513" format="default"/>, <xref target="RFC6514" format="default"/>, <xref target="RFC7117" format="default"/>, and <xreftarget="inter-as"/>target="inter-as" format="default"/> of this document) require all ASBRs to be involved, andIngress Replicationingress replication is used between two ASBRs in different ASes. </t> <t> In the above diagram, it's possible that ASBR1/4 does not support segmentation, and the provider tunnels in AS 100/300 can actually extend across the external link. In this case, the inter-region segmentation procedures can be used instead--- a region is the entire(AS100"AS100 +ASBR1-ASBR2 link)ASBR1-ASBR2" link or(AS300the entire "AS300 +ASBR3-ASBR4 link).ASBR3-ASBR4" link. ASBR2/3 would be the RBRs, and ASBR1/4 will just be a transit core router with respect to provider tunnels. <!-- [rfced] Section 6.1: This sentence did not parse as written. We updated it as follows to indicate that the region is one of the two types of links. If this is incorrect, please provide clarifying text. Original: In this case, the inter-region segmentation procedures can be used instead - a region is the entire (AS100 + ASBR1-ASBR2 link) or (AS300 + ASBR3-ASBR4 link). Currently: In this case, the inter-region segmentation procedures can be used instead - a region is the entire "AS100 + ASBR1-ASBR2" link or the entire "AS300 + ASBR3-ASBR4" link. --> </t> <t>As illustrated in the diagram below, ASBR2/3 will establish a multihop EBGP session with eitheraan RR or directly with PEs in the neighboring AS. I/S-PMSI A-D routes from ingress PEs will not be processed by ASBR1/4. When ASBR2 re-advertises the routes into AS 200, it changes the next hop to its own address and changes its PTA to specify the tunnel type/identification in its own AS. When ASBR3 re-advertises I/S-PMSI A-D routes into the neighboring AS 300, it changes the next hop to its own address and changes its PTA to specify the tunnel type/identification in the neighboring region.NowNow, the segment is rooted at ASBR3 and extends across the external link to PEs.<figure> <artwork><!-- [rfced] Section 6.1: This sentence does not parse. Does "either a RR or directly with PEs" mean "either (1) with an RR or (2) directly with PEs" or something else? Also, does "RR" stand for "Route Reflector" or something else? Original: As illustrated in the diagram below, ASBR2/3 will establish a multihop EBGP session with either a RR or directly with PEs in the neighboring AS. --> </t> <artwork name="" type="" align="left" alt=""><![CDATA[ --------- ------ --------- / RR....\.mh-ebpg / \ mh-ebgp/....RR \ / : \ `. / \ .' / : \ | PE1 o ASBR1 -- ASBR2 ASBR3 -- ASBR4 o PE2 | \ / \ / \ / \ / \ / \ / --------- ------ --------- AS 100 AS 200 AS 300 |-------------------|----------|---------------------| segment 1 segment 2 segment 3</artwork> </figure> </t>]]></artwork> </section> <sectiontitle="Per-region Aggregation" anchor="aggregation">anchor="aggregation" numbered="true" toc="default"> <name>Per-Region Aggregation</name> <t>Notice that every I/S-PMSI route from each PE will be propagated throughout all the ASes or regions. They may also trigger corresponding Leaf A-Droutesroutes, depending on the types of tunnels used in each region. This maybecomeresult in too many-routes and corresponding tunnels. To address this concern, the I-PMSI routes from all PEs inaan AS/region can be aggregated into a single I-PMSI route originated from the RBRs, and traffic from all those individual I-PMSI tunnels will be switched into the single I-PMSI tunnel. This is like the MVPN Inter-AS I-PMSI route originated by ASBRs. <!-- [rfced] Section 6.2: The "This may become too many" sentence did not parse. We updated the wording as noted below. If this is incorrect, please clarify the text. Original (the previous two sentences are included for context): Notice that every I/S-PMSI route from each PE will be propagated throughout all the ASes or regions. They may also trigger corresponding Leaf A-D routes depending on the types of tunnels used in each region. This may become too many - routes and corresponding tunnels. Currently: This may result in too many routes and corresponding tunnels. --> </t> <t>The MVPN Inter-AS I-PMSI A-D route can be better calledas per-ASa "per-AS I-PMSI A-Droute,route", to be compared against the (per-PE) Intra-AS I-PMSI A-D routes originated by each PE. In thisdocumentdocument, we will call itas per-regiona "per-region I-PMSI A-Droute,route" incasecases where we want to applytheaggregation at the regional level. The per-PE I-PMSI routes will not be propagated to other regions. If multiple RBRs are connected to a region, then each will advertise such a route, with the same Region ID and Ethernet Tag ID (<xreftarget= "per-region"/>).target="per-region" format="default"/>). Similar to the per-PE I-PMSI A-D routes, RBRs/PEs in a downstream region will each select the best route from all those re-advertised by the upstream RBRs and hence will only receive traffic injected by one of them. <!-- [rfced] Section 6.2: As it appears that "best one" in this sentence means "best route", we updated the wording accordingly. If this is not correct, please provide clarifying text. Original: Similar to the per-PE I-PMSI A-D routes, RBRs/PEs in a downstream region will each select a best one from all those re-advertised by the upstream RBRs, hence will only receive traffic injected by one of them. Currently: Similar to the per-PE I-PMSI A-D routes, RBRs/PEs in a downstream region will each select the best route from all those re-advertised by the upstream RBRs and hence will only receive traffic injected by one of them. --> </t><t>MVPN does<t>MVPNs do not aggregate S-PMSI routes from all PEs in an AS likeit doesthey do forI-PMSIsI-PMSI routes, because the number of PEs that will advertise S-PMSI routes for the same(s,g)(S,G) or(*,g)(*,G) is small. This is also the case forEVPN,EVPNs, i.e., thereisare no per-region S-PMSI routes. <!-- [rfced] Section 6.2: Please note that we changed "(s,g) or (*,g)" to "(S,G) or (*,G)" per RFC 9251 (and also because we do not see the lowercase form used in any published RFC). Please let us know any concerns. Original: MVPN does not aggregate S-PMSI routes from all PEs in an AS like it does for I-PMSIs routes, because the number of PEs that will advertise S-PMSI routes for the same (s,g) or (*,g) is small. Currently: MVPNs do not aggregate S-PMSI routes from all PEs in an AS like they do for I-PMSI routes, because the number of PEs that will advertise S-PMSI routes for the same (S,G) or (*,G) is small. --> </t> <t>Notice that per-region I-PMSI routes can also be used to addressbackwards compatibility issue,backward-compatibility issues, as discussed in <xreftarget="compatibility"/>.target="compatibility" format="default"/>. </t> <t>The Region ID in the per-region I-PMSI route's NLRI is encoded like an EC. For example, the Region ID can encode an AS number or area ID in the following EC format:<list style="symbols"> <t>For</t> <ul spacing="normal"> <li>For a two-octet AS number, a Transitive Two-OctetAS-SpecificAS-specific EC of sub-type 0x09 (Source AS), with the Global Administrator sub-field set to the AS number and the Local Administrator sub-field set to 0.</t> <t>For</li> <li>For a four-octet AS number, a Transitive Four-OctetAS-SpecificAS-specific EC of sub-type 0x09 (Source AS), with the Global Administrator sub-field set to the AS number and the Local Administrator sub-field set to 0.</t> <t>For</li> <li>For an area ID, a TransitiveIPv4-Address-SpecificIPv4-Address-specific EC of any sub-type, with the Global Administrator sub-field set to the area ID and the Local Administrator sub-field set to 0.</t> </list> Uses</li> </ul> <t> The use of other ECencoding MAYencodings <bcp14>MAY</bcp14> be allowed as long asitthey uniquelyidentifiesidentify the region and the RBRs for the same regionusesuse the same Region ID. </t> </section> <sectiontitle="Usenumbered="true" toc="default"> <name>Use ofS-NH-EC"> <t>[RFC7524]S-NH-EC</name> <t><xref target="RFC7524" format="default"/> specifies the use of the S-NH-EC because it does not allow ABRs to change the BGP next hop when they re-advertise I/S-PMSI A-D routes to downstream areas. That is only to be consistent with the MVPN Inter-AS I-PMSI A-D routes, whose next hop must not be changed when they're re-advertised by the segmenting ABRs for reasons specific toMVPN.MVPNs. ForEVPN,EVPNs, it is perfectly fine to change the next hop when RBRs re-advertise the I/S-PMSI A-D routes, instead of relying on the S-NH-EC. As a result, this document specifies that RBRs change the BGP next hop when they re-advertise I/S-PMSI A-D routes and do not use the S-NH-EC.TheThis provides the advantageof this isthat neither ingress PEs nor egress PEs need to understand/use the S-NH-EC, and a consistent procedure (based on BGP nexthop)hops) is used for bothinter-asinter-AS and inter-region segmentation. <!-- [rfced] Section 6.3: To what does "That" refer in this sentence? Original (the previous sentence is included for context): [RFC7524] specifies the use of S-NH-EC because it does not allow ABRs to change the BGP next hop when they re-advertise I/S-PMSI A-D routes to downstream areas. That is only to be consistent with the MVPN Inter-AS I-PMSI A-D routes, whose next hop must not be changed when they're re-advertised by the segmenting ABRs for reasons specific to MVPN. --> </t> <t> If a downstream PE/RBR needs to originate Leaf A-D routes, it constructs an IP-based Route Target Extended Community by placing the IP address carried in the Next Hop of the received I/S-PMSI A-D route in the Global Administrator field of theCommunity,extended community, with the Local Administrator field of thisCommunityextended community set to00, and also setting the Extended Communities attribute of the Leaf A-D route to thatCommunity.extended community. </t> <t>Similar to[RFC7524],<xref target="RFC7524" format="default"/>, the upstream RBRMUST<bcp14>MUST</bcp14> (auto-)configureaan RT with the Global Administrator field set to the Next Hop in the re-advertised I/S-PMSI A-D route and with the Local Administrator field set to 0. With this, the mechanisms specified in[RFC4684]<xref target="RFC4684" format="default"/> for constrained BGP route distribution can be used along with this specification to ensure that only the needed PE/ABR will have to process asaidparticular Leaf A-D route. </t> </section> <sectiontitle="Ingressnumbered="true" toc="default"> <name>Ingress PE's I-PMSI LeafTracking"> <t>[RFC7524]Tracking</name> <t><xref target="RFC7524" format="default"/> specifies that when an ingress PE/ASBR (re-)advertisesana VPLS I-PMSI A-D route, it sets the L flag to 1 in the route's PTA. Similar to theinter-asinter-AS case, this is actually not really needed forEVPN.EVPNs. To be consistent with theinter-asinter-AS case, the ingress PE does not set the L flag in its originated I-PMSI A-D routes, and it determines the leaves based on the BGP next hops in its received I-PMSI A-D routes, as specified in <xreftarget="leaf-tracking"/>.target="leaf-tracking" format="default"/>. </t> <t>The samebackward compatibilitybackward-compatibility issue exists, and the same solution asinthat for theinter-asinter-AS case applies, as specified in <xreftarget= "compatibility"/>.target="compatibility" format="default"/>. </t> </section> </section> <sectiontitle="Multi-homing Support"> <!-- <t>EVPN support active-active multi-homing. For BUM traffic, only an elected DF PE is allowed to send to a multi-homed Ethernet Segment (ES), while a TS may use any of its active-active links to the ES. If the link a TS uses is not attached to the DF PE, the receiving non-DF PE will deliver the traffic to all PEs in the same EVI, including the DF PE for the sourcing ES. To prevent the DF PE from delivering the received traffic back to the ES, in case of MPLS encapsulation, a BUM packet from a non-DF PE carries an ESI label, so that when the DF receives the packet it will know from the ESI label that the packet is from a non-DF for an ES and will not send the packet back to the ES. </t> -->numbered="true" toc="default"> <name>Multihoming Support</name> <t>To supportmulti-homingmultihoming with segmentation,ESIEthernet Segment Identifier (ESI) labelsSHOULD<bcp14>SHOULD</bcp14> be allocated from a "Domain-wide Common Block" (DCB) <xreftarget="I-D.ietf-bess-mvpn-evpn-aggregation-label"/>target="RFC9573" format="default"/> for all tunneltypestypes, includingIngress Replication.ingress replication tunnels <xref target="RFC7988"/>. Via means outside the scope of this document, PEs know that ESI labels are fromDCBa DCB, andthenexistingmulti-homingmultihoming procedures will then workas is"as is" (whether amulti-homedmultihomed Ethernet Segment spansacrosssegmentation regions or not). </t> <t>Not using DCB-allocated ESI labels is outside the scope of thisdocument.<!-- It would require complicated forwarding procedures on segmentation points, and, in case of multi-homing across segmentation regions, complicated control plane procedures as well.-->document. </t> </section> <section anchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>IANA hastemporarilyassigned the following new EVPN route types in theEVPN"EVPN RouteTypesTypes" registry:<list style="symbols"> <t>9 - Per-Region I-PMSI A-D route</t> <t>10 - S-PMSI A-D route</t> <t>11 - Leaf A-D route</t> </list></t><t>This document requests IANA to assign<table anchor="tab-1"> <name>New Route Types</name> <thead> <tr> <th>Value</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>9</td> <td>Per-Region I-PMSI A-D route</td> <td>RFC 9572</td> </tr> <tr> <td>10</td> <td>S-PMSI A-D route</td> <td>RFC 9572</td> </tr> <tr> <td>11</td> <td>Leaf A-D route</td> <td>RFC 9572</td> </tr> </tbody> </table> <t>IANA has assigned one flag bit from theEVPN Multicast"Multicast Flags ExtendedCommunity FlagsCommunity" registryto becreatedin [draft-ietf-bess-evpn-igmp-mld-proxy]: <list style="symbols"> <t>Bit-Sby <xref target="RFC9251"/>: </t> <!-- [rfced] The description of the flag bit has been updated per this note from IANA: ... the authors want to change "Bit-S - Segmentation ProcedureSupport </t> </list> </t>Support" to "Segmentation Support," ... Please verify that the text appears correctly. --> <table anchor="tab-2"> <name>New Multicast Flag</name> <thead> <tr> <th>Bit</th> <th>Name</th> <th>Reference</th> <th>Change Controller</th> </tr> </thead> <tbody> <tr> <td>8</td> <td>Segmentation Support</td> <td>RFC 9572</td> <td>IETF</td> </tr> </tbody> </table> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t> TheSelective Forwardingprocedures specified in this document for selective forwarding via S-PMSI/Leaf A-D routesin this documentare based on the same procedures as those used forMVPN [RFC6513] [RFC6514]MVPNs <xref target="RFC6513" format="default"/> <xref target="RFC6514" format="default"/> and VPLSMulticast [RFC7117].multicast <xref target="RFC7117" format="default"/>. The procedures for tunnel segmentationproceduresas specified in this document are based onthesimilar procedures used for MVPN inter-AS[RFC6514]tunnel segmentation <xref target="RFC6514" format="default"/> and inter-area[RFC7524]tunnelsegmentation, andsegmentation <xref target="RFC7524" format="default"/>, as well as procedures for VPLSMulticast [RFC7117] inter-asmulticast inter-AS tunnelsegmentation.segmentation <xref target="RFC7117" format="default"/>. When applied toEVPN,EVPNs, they do not introduce new security concernsbesides what have beenbeyond those discussed in[RFC6513], [RFC6514], [RFC7117],<xref target="RFC6513" format="default"/>, <xref target="RFC6514" format="default"/>, <xref target="RFC7117" format="default"/>, and[RFC7524].<xref target="RFC7524" format="default"/>. They also do not introduce new security concerns compared to[RFC7432].<xref target="RFC7432" format="default"/>. </t> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7117.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7524.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8584.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8534.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6513.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6514.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9251.xml"/> <!-- draft-ietf-bess-mvpn-evpn-aggregation-label (AUTH48 as RFC 9573) --> <reference anchor='RFC9573' target="https://www.rfc-editor.org/info/rfc9573"> <front> <title>MVPN/EVPN Tunnel Aggregation with Common Labels</title> <author initials='Z' surname='Zhang' fullname='Zhaohui Zhang'> <organization /> </author> <author initials='E' surname='Rosen' fullname='Eric Rosen'> <organization /> </author> <author initials='W' surname='Lin' fullname='Wen Lin'> <organization /> </author> <author initials='Z' surname='Li' fullname='Zhenbin Li'> <organization /> </author> <author initials='IJ' surname='Wijnands' fullname='IJsbrand Wijnands'> <organization /> </author> <date year='2024' month='April' /> </front> <seriesInfo name="RFC" value="9573"/> <seriesInfo name="DOI" value="10.17487/RFC9573"/> </reference> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4875.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4684.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6388.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7988.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9136.xml"/> </references> </references> <section anchor="Acknowledgements"title="Acknowledgements">numbered="false" toc="default"> <name>Acknowledgements</name> <t>The authors thankEric Rosen, John Drake, and Ron Bonica<contact fullname="Eric Rosen"/>, <contact fullname="John Drake"/>, and <contact fullname="Ron Bonica"/> for their comments and suggestions. </t> </section> <sectiontitle="Contributors">numbered="false" toc="default"> <name>Contributors</name> <t>The following people also contributed to this document through their earlier work in EVPN selective multicast.<figure> <artwork> Junlin Zhang Huawei Technologies Huawei</t> <contact fullname="Junlin Zhang"> <organization>Huawei Technologies</organization> <address> <postal> <street>Huawei Bld.,No.156No. 156 BeiqingRd. Beijing 100095 China Email: jackey.zhang@huawei.com Zhenbin Li Huawei Technologies HuaweiRd.</street> <city>Beijing</city> <code>100095</code> <country>China</country> </postal> <email>jackey.zhang@huawei.com</email> </address> </contact> <contact fullname="Zhenbin Li"> <organization>Huawei Technologies</organization> <address> <postal> <street>Huawei Bld.,No.156No. 156 BeiqingRd. Beijing 100095 China Email: lizhenbin@huawei.com </artwork> </figure> </t>Rd.</street> <city>Beijing</city> <code>100095</code> <country>China</country> </postal> <email>lizhenbin@huawei.com</email> </address> </contact> </section></middle> <back> <references title="Normative References"> &RFC2119; &RFC8174; &RFC7432; &RFC7117; &RFC7524; &RFC8584; &RFC8534; &RFC6513; &RFC6514; <?rfc include='reference.I-D.ietf-bess-evpn-igmp-mld-proxy'?> <?rfc include='reference.I-D.ietf-bess-mvpn-evpn-aggregation-label'?> </references> <references title="Informative References"> &RFC8279; &RFC4875; &RFC4684; &RFC6388; &RFC7988; <?rfc include='reference.I-D.ietf-bess-evpn-prefix-advertisement'?> </references></back> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide at <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, and let us know if any changes are needed. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> <!-- [rfced] Please let us know if any changes are needed for the following: a) The following terms were used inconsistently in this document. We chose to use the latter forms. Please let us know any objections. Ingress Replication / ingress replication (per RFCs 9251 and 9252) inter-as / inter-AS (segmentation, tree, tunnel) (per published RFCs) "L" flag (1 instance) / L flag (11 instances) leaf A-D (1 instance) / Leaf A-D (37 instances) Per-region I-PMSI A-D route / per-region I-PMSI A-D route Selective Forwarding (1 instance) / selective forwarding (6 instances) Selective Multicast / selective multicast (per RFC 9251) set to zero (1 instance) / set to 0 (5 instances) VPLS Multicast / VPLS multicast (per RFC 7117) b) The following term appears to be used inconsistently in this document. Please let us know which form is preferred. the next hop / the Next Hop Do the instances of "the Next Hop" refer to the Next Hop field, or do they refer to next hops in general? c) Next-hop field vs. Next-Hop field (draft-ietf-bess-evpn-optimized-ir) vs. Next Hop field (draft-ietf-bess-evpn-bum-procedure-updates) (We see "Next-Hop address" in draft-ietf-bess-evpn-optimized-ir.) --> </rfc>