<?xmlversion="1.1" encoding="US-ASCII"?>version='1.0' encoding='UTF-8'?> <!-- pre-edited by ST 02/12/24 --> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY 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"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-bier-evpn-14"ipr="trust200902">number="9624" ipr="trust200902" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> <front> <!--[rfced] Please note that the title of the document has been updated as follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review. Original: EVPN BUM Using BIER Current: EVPN Broadcast, Unknown Unicast, and Multicast (BUM) Using Bit Index Explicit Replication (BIER) Additionally, we have updated the short title. This can be seen in the header of the PDF output. Original: bier-evpn Current: EVPN BUM Using BIER --> <titleabbrev="bier-evpn">EVPNabbrev="EVPN BUM UsingBIER</title>BIER">EVPN Broadcast, Unknown Unicast, and Multicast (BUM) Using Bit Index Explicit Replication (BIER)</title> <seriesInfo name="RFC" value="9624"/> <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang"> <organization>Juniper Networks</organization> <address> <email>zzhang@juniper.net</email> </address> </author> <authorfullname="Antonifullname="Tony Przygienda"initials="A."initials="T." surname="Przygienda"> <organization>Juniper Networks</organization> <address> <email>prz@juniper.net</email> </address> </author> <author fullname="Ali Sajassi" initials="A." surname="Sajassi"> <organization>Cisco Systems</organization> <address> <email>sajassi@cisco.com</email> </address> </author> <author fullname="Jorge Rabadan" initials="J." surname="Rabadan"> <organization>Nokia</organization> <address> <email>jorge.rabadan@nokia.com</email> </address> </author> <date month="July" year="2024"/> <area>RTF</area> <workgroup>BIER</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 protocols and procedures for forwardingbroadcast, unknown unicast,Broadcast, Unknown Unicast, andmulticastMulticast (BUM) traffic of Ethernet VPNs(EVPN)(EVPNs) using Bit Index Explicit Replication (BIER). </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 this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. </t> </note></front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t><xreftarget="RFC7432"/>target="RFC7432" format="default"/> and <xreftarget='RFC8365'/>target="RFC8365" format="default"/> specify the protocols and procedures for Ethernet VPNs (EVPNs). Forbroadcast, unknown unicastBroadcast, Unknown Unicast, andmulticastMulticast (BUM) traffic, provider/underlay tunnels are used to carry the BUM traffic. Several kinds of tunnel technologies can be used as specified in <xreftarget="RFC7432"/>target="RFC7432" format="default"/> and <xreftarget="RFC8365"/>,target="RFC8365" format="default"/>, and this document specifies the protocols and procedures to use Bit Index Explicit Replication (BIER) <xreftarget='RFC8279'/>target="RFC8279" format="default"/> as provider tunnels for EVPN BUM traffic. </t> <t> BIER is an architecture that provides optimal multicast forwarding through a "multicastdomain",domain" without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. </t> <t> The EVPN BUM procedures specified in <xreftarget="RFC7432"/>target="RFC7432" format="default"/> and extended in <xreftarget='I-D.ietf-bess-evpn-bum-procedure-updates'/>,target="RFC9572" format="default"/>, <xreftarget='RFC9251'/>,target="RFC9251" format="default"/>, and <xreftarget='I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements'/>target="I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements" format="default"/> are much aligned with Multicast VPN (MVPN) procedures <xreftarget="RFC6514"/>target="RFC6514" format="default"/>, and an EVPN Broadcast Domain (BD) corresponds to a VPN in MVPN. As such, this document is also very much aligned with <xreftarget='RFC8556'/> thattarget="RFC8556" format="default"/>, which specifies MVPN with BIER. For terseness, some background,termsterms, and concepts are not repeated here. Additionally, some text is borrowed verbatim from <xreftarget='RFC8556'/>.target="RFC8556" format="default"/>. </t> <sectiontitle="Terminologies"> <t> <list style="symbols"> <t>ES: Ethernet Segment.</t> <t>ESI: Ethernetnumbered="true" toc="default"> <name>Terminology</name> <dl newline="false" spacing="normal"> <dt>ES:</dt> <dd>Ethernet Segment</dd> <dt>ESI:</dt> <dd>Ethernet SegmentIdentifier.</t> <t>BFR: Bit-Forwarding Router.</t> <t>BFIR: Bit-ForwardingIdentifier</dd> <dt>BFR:</dt> <dd>Bit-Forwarding Router</dd> <dt>BFIR:</dt> <dd>Bit-Forwarding IngressRouter.</t> <t>BFER: Bit-ForwardingRouter</dd> <dt>BFER:</dt> <dd>Bit-Forwarding EgressRouter.</t> <t>BFR-Prefix: AnRouter</dd> <dt>BFR-Prefix:</dt> <dd>An IP address that uniquely identifies a BFR and is routable in a BIERdomain.</t> <t> C-S: Adomain.</dd> <dt>C-S:</dt> <dd>A multicast source address identifying a multicast source located at an EVPN customer site. "C-" stands for "Customer-".</t> <t> C-G: A</dd> <dt>C-G:</dt> <dd>A multicast group address used by an EVPNcustomer. </t> <t> C-flow: Acustomer.</dd> <dt>C-flow:</dt> <dd>A customer multicast flow. Each C-flow is identified by the ordered pair (source address, group address), where each address is in the customer's address space. The identifier of a particular C-flow is usually written as (C-S, C-G). Sets of C-flows can be denoted by the use of the "C-*" wildcard (see <xreftarget="RFC6625"/>),target="RFC6625" format="default"/>), e.g., (C-*,C-G). </t> <t> P-tunnel. AC-G).</dd> <dt>P-tunnel:</dt> <dd>A multicast tunnel through the network of one or more service providers used to transport C-flows. "P-" stands for "Provider-".</t> <t> IMET Route: Inclusive</dd> <dt>IMET A-D Route:</dt> <dd>Inclusive Multicast Ethernet Tag Auto-Discovery route. Carried in BGP Update messages, these routes are used to advertise the "default" P-tunnel for a particular broadcastdomain. </t> <t> SMET Route: Selectivedomain.</dd> <dt>SMET A-D Route:</dt> <dd>Selective Multicast Ethernet Tag Auto-Discovery route. Carried in BGP Update messages, these routes are used to advertise the C-flows that the advertisingPEProvider Edge (PE) is interestedin. </t> <t>PMSI [RFC6513]: Providerin.</dd> <dt>PMSI:</dt> <dd>Provider Multicast Service Interface- a<xref target="RFC6513" format="default"/>. A conceptual interfaceforused by a PE to send customer multicast traffic to all or some PEs in the sameVPN. </t> <t>I-PMSI:VPN.</dd> <!-- [rfced] For the descriptions of "I-PMSI" and "S-PMSI", is there something that is "sent" to the PEs or select PEs, or is "I-PMSI" and "S-PMSI" intended "for" PEs or select PEs? Please let us know if/how these entries may be updated for clarity. Original: I-PMSI: Inclusive PMSI - to all PEs in the same VPN.</t> <t>S-PMSI:S-PMSI: Selective PMSI - to some of the PEs in the same VPN.</t> <t>I-PMSI A-D Route:Perhaps: I-PMSI: Inclusive PMSI. For all PEs in the same VPN. S-PMSI: Selective PMSI. For some of the PEs in the same VPN. --> <dt>I-PMSI:</dt> <dd>Inclusive PMSI - to all PEs in the same VPN.</dd> <dt>S-PMSI:</dt> <dd>Selective PMSI - to some of the PEs in the same VPN.</dd> <dt>I-PMSI A-D Route:</dt> <dd>Inclusive PMSI Auto-Discovery route used to advertise the tunnels that instantiate anI-PMSI. </t> <t> S-PMSII-PMSI.</dd> <dt>S-PMSI A-Droute: SelectiveRoute:</dt> <dd>Selective PMSI Auto-Discovery route used to advertise that particular C-flows are bound to (i.e., are traveling through) particularP-tunnels. </t> <t> PMSIP-tunnels.</dd> <dt>PTA:</dt> <dd>PMSI Tunnelattribute (PTA):Attribute. A BGP attribute used to identify a particularP-tunnel. </t> <t>VXLAN [RFC7348]: VirtualP-tunnel.</dd> <dt>VXLAN:</dt> <dd>Virtual eXtensible Local AreaNetwork. </t> <t>NVGRE [RFC7637]:Network <xref target="RFC7348" format="default"/></dd> <dt>NVGRE:</dt> <dd>Network VirtualizationusingUsing Generic RoutingEncapsulation. </t> <t>GENEVE [RFC8926]: GenericEncapsulation <xref target="RFC7637" format="default"/></dd> <dt>GENEVE:</dt> <dd>Generic Network VirtualizationEncapsulation. </t> <t>VNI: VXLANEncapsulation <xref target="RFC8926" format="default"/></dd> <dt>VNI:</dt> <dd>VXLAN NetworkIdentifier. </t> <t>VSID: VirtualIdentifier</dd> <dt>VSID:</dt> <dd>Virtual SubnetIDentifier. </t> <t>RSVP-P2MP [RFC4875]: Resource ReserVationIDentifier</dd> <dt>RSVP-P2MP:</dt> <dd>Resource Reservation Protocol for Point-to-Multipoint TE Label SwitchedPaths. </t> <t>mLDP-P2MP [RFC6388]: LabelPaths (LSPs) <xref target="RFC4875" format="default"/></dd> <dt>mLDP-P2MP:</dt> <dd>Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-MultipointLabel Switched Paths. </t> </list>LSPs <xref target="RFC6388" format="default"/></dd> </dl> </section> <section> <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>", and "<bcp14>OPTIONAL</bcp14>" in this document are 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> <sectiontitle="Useanchor="pta" numbered="true" toc="default"> <name>Use of the PMSI TunnelAttribute" anchor="pta">Attribute</name> <t><xreftarget="RFC7432"/>target="RFC7432" format="default"/> specifies that Inclusive Multicast Ethernet Tag (IMET) routes carry a PMSI Tunnel Attribute (PTA) to identify the particular P-tunnel to which one or more BUM flows are being assigned, which is the same as specified in <xreftarget="RFC6514"/>target="RFC6514" format="default"/> for MVPN. <xreftarget='RFC8556'/>target="RFC8556" format="default"/> specifies the encoding of the PTA for the use of BIER with MVPN. Much of that specification is reused for the use of BIER withEVPNEVPN, and much of the text below is borrowed verbatim from <xreftarget='RFC8556'/>.target="RFC8556" format="default"/>. </t> <t>ThePMSI Tunnel Attribute (PTA)PTA contains the following fields:<list style="symbols"> <t>"Tunnel Type".</t> <ul spacing="normal"> <li> <t>Tunnel Type. The same codepoint 0x0B that IANA has assigned for BIER for MVPN <xreftarget='RFC8556'/>target="RFC8556" format="default"/> is used for EVPN as well. <!--The "composite tunnel" bit <xref target="RFC8317"/> of the type field can also be set. Its semantics are updated in [I-D.draft-zzhang-bess-mvpn-evpn-composite-tunnel]. In that case, the tunnel is referred to as a BIER composite tunnel. An example of its usage is provided in Section <xref target="ar"/> of this document.--> </t><t>"Tunnel</li> <li> <!--[rfced] In this list, the text in items 1 and 3 does not exactly match that in RFC 8556. Should we update this text to match RFC 8556? Or may we indicate that the text is based on RFC 8556 as shown below? Original: * "Tunnel Identifier". This field contains three subfields for BIER. The text below is exactly as in [RFC8556]. 1 The first subfield is a single octet, containing the sub- domain-id of the sub-domain to which the BFIR will assign the packets that it transmits on the PMSI identified by the Network Layer Reachability Information (NLRI) of the IMET, S-PMSI A-D, or per-region I-PMSI A-D route that contains this PTA. How that sub-domain is chosen is outside the scope of this document. ... 3 The third subfield is the BFR-Prefix (see [RFC8279]) of the originator of the route that is carrying this PTA. This will either be a /32 IPv4 address or a /128 IPv6 address. Whether the address is IPv4 or IPv6 can be inferred from the total length of the PMSI Tunnel attribute. The BFR-prefix need not be the same IP address that is carried in any other field of the x-PMSI A-D route, even if the BFIR is the originating router of the x-PMSI A-D route. Perhaps: * "Tunnel Identifier". This field contains three subfields for BIER. The text below is based on the text in [RFC8556]. 1. The first subfield is a single octet, containing the sub- domain-id of the sub-domain to which the BFIR will assign the packets that it transmits on the PMSI identified by the Network Layer Reachability Information (NLRI) of the IMET, S-PMSI A-D, or per-region I-PMSI A-D route that contains this PTA. How that sub-domain is chosen is outside the scope of this document. ... 3. The third subfield is the BFR-Prefix (see [RFC8279]) of the originator of the route that is carrying this PTA. This will either be a /32 IPv4 address or a /128 IPv6 address. Whether the address is IPv4 or IPv6 can be inferred from the total length of the PMSI Tunnel Attribute. The BFR-Prefix need not be the same IP address that is carried in any other field of the x-PMSI A-D route, even if the BFIR is the originating router of the x-PMSI A-D route. --> <t>Tunnel Identifier. This field contains three subfields for BIER. The text below is exactly as in <xreftarget='RFC8556'/>. <list style="format %d">target="RFC8556" format="default"/>. </t> <ol spacing="normal" type="1"><li> <t> The first subfield is a single octet, containing the sub- domain-id of the sub-domain to which the BFIR will assign the packets that it transmits on the PMSI identified by the Network Layer Reachability Information (NLRI) of the IMET, S-PMSI A-D, or per-region I-PMSI A-D route that contains this PTA. How that sub-domain is chosen is outside the scope of this document. </t> </li> <li> <t> The second subfield is a two-octet field containing theBFR-id,BFR-id in the sub-domain identified in the firstsubfield,subfield of the router that is constructing the PTA. </t> </li> <li> <t> The third subfield is the BFR-Prefix (see <xreftarget='RFC8279'/>)target="RFC8279" format="default"/>) of the originator of the route that is carrying this PTA. This will either be a /32 IPv4 address or a /128 IPv6 address. Whether the address is IPv4 or IPv6 can be inferred from the total length of the PMSI Tunnelattribute. <vspace/> <vspace/>Attribute. </t> <t> TheBFR-prefixBFR-Prefix need not be the same IP address that is carried in any other field of the x-PMSI A-D route, even if the BFIR is the originating router of the x-PMSI A-D route. </t></list></li> </ol> <t> <!--If the "composite tunnel" bit is set, as specified in [I-D.draft-zzhang-bess-mvpn-evpn-composite-tunnel], a three-octet label field is added before the "Tunnel Identifier" field to indicate the IR label that this PE uses to receive IR traffic with. The three-octet label field after the Tunnel Type field is the label that this PE uses to send/receive BIER traffic with.--> </t><t>"MPLS label".</li> <li> <t>MPLS Label. For EVPN-MPLS <xreftarget="RFC7432"/>,target="RFC7432" format="default"/>, this field contains an upstream-assigned MPLS label. It is assigned by the BFIR. Constraints on how the originating router selects this label are discussed in <xreftarget="label"/>.target="label" format="default"/>. For EVPN-VXLAN/NVGRE/GENEVE <xreftarget='RFC8365'/>target="RFC8365" format="default"/> <xreftarget='RFC7348'/>target="RFC7348" format="default"/> <xreftarget='RFC7637'/>target="RFC7637" format="default"/> <xreftarget='RFC8926'/>,target="RFC8926" format="default"/>, this field is a 24-bit VNI/VSID of global significance. </t><t>"Flags".</li> <li> <t>Flags. When the tunnel type is BIER, two of the flags in the PTA Flags field are meaningful. Details about the use of these flags can be found in <xreftarget="tracking"/>. <list style="symbols"> <t>"Leaftarget="tracking" format="default"/>. </t> <ul spacing="normal"> <li> <t>Leaf Info Required per Flow(LIR-pF)"(LIR-pF) <xreftarget="RFC8534"/>target="RFC8534" format="default"/> </t><t>"Leaf</li> <li> <t>Leaf Info Required Bit(LIR)" </t> </list>(LIR) </t> </li> </ul> </li> <!--t>"Auxiliary Information". This is optional, present if the total length of the PTA is larger then the sum of lengths of the fields before this one. It is in the form of a series of TLVs. </t--></list> </t></ul> <t> Note that if a PTA specifying "BIER" is attached to an IMET, S-PMSI A-D, or per-region I-PMSI A-D route, the routeMUST NOT<bcp14>MUST NOT</bcp14> be distributed beyond the boundaries of a BIER domain. That is, any routers that receive the route must be in the same BIER domain as the originator of the route. If the originator is in more than one BIER domain, the route must be distributed only within the BIER domain in which the BFR-Prefix in the PTA uniquely identifies the originator. As with all MVPN routes, the distribution of these routes is controlled by the provisioning of Route Targets. </t> <!--section title = "Auxiliary Information"> <t>For the "Auxiliary Information", one TLV is defined in this document - Tunnel Encapsulation TLV. The value part of the TLV is a Tunnel TLV as defined in <xref target="RFC9012"/>. </t> <t>This MAY be used when VXLAN/NVGRE/GENEVE encapsulation with an IP header (and UDP header in the case of VXLAN/GENEVE) is the BIER payload. Normally that is not needed with BIER, except when BIER Penultimate Hop Popping (PHP) <xref target="I-D.ietf-bier-php"/> is used and the encapsulation (after BIER header is popped) between the BIER Penultimate Hop and the egress PE does not have a way to indicate the next header is VXLAN/NVGRE/GENEVE. In that case the full VXLAN/NVGRE/GENEVE encapsulation with an IP header MUST be used. The tunnel type (VXLAN/NVGRE/GENEVE), endpoint, and some tunnel specific information MAY be specified in the Tunnel TLV or MAY be provisioned on PEs. The tunnel endpoint MUST be an IP multicast address and the receiving egress PE MUST be set up to receive and process packets addressed to the address. The same multicast address can be used for all Bridge Domains (BDs), as the the inner VXLAN/NVGRE/GENEVE header will be used to identify BDs. </t> </section--> <sectiontitle="IP-Basedanchor="php-address" numbered="true" toc="default"> <name>IP-Based Tunnel and BIERPHP" anchor="php-address">PHP</name> <t>When VXLAN/NVGRE/GENEVE is used for EVPN, bydefaultdefault, the outer IP header (and UDP header in the case of VXLAN/GENEVE) is not included in the BIER payload, except when it is knownaprioria priori that BIER Penultimate Hop Popping (PHP) <xreftarget="I-D.ietf-bier-php"/>target="I-D.ietf-bier-php" format="default"/> is used in the BIER domain and the encapsulation (after the BIER header is popped) between the BIER Penultimate Hop and the egress PE does not have a way to indicate the next header is VXLAN/NVGRE/GENEVE. In thatcasecase, the full VXLAN/NVGRE/GENEVE encapsulationMUST<bcp14>MUST</bcp14> be used. In the outer IP header, a well-known IP multicast address (to be assigned by IANA) is used as the destinationaddressaddress, and the egress PEsMUST<bcp14>MUST</bcp14> be set up to receive and process packets addressed to the destination address. The address is used for allBroadcast Domains (BDs)BDs, and the inner VXLAN/NVGRE/GENEVE header will be used to identify BDs. </t> </section> <sectiontitle="Explicit Tracking" anchor="tracking">anchor="tracking" numbered="true" toc="default"> <name>Explicit Tracking</name> <t> When using BIER to transport an EVPN BUM data packet through a BIER domain, an ingress PE functions as a BFIR (see <xreftarget='RFC8279'/>).target="RFC8279" format="default"/>). The BFIR must determine the set of BFERs to which the packet needs to be delivered. This can be done in either of two ways as described in the following two sections. </t> <sectiontitle="Usingnumbered="true" toc="default"> <name>Using IMET/SMETroutes">Routes</name> <t>Both IMET and SMET routes provide explicit tracking functionality. </t> <t>For an inclusive PMSI, the set of BFERs (egress PEs) includes the originators of all IMET routes for a broadcast domain. For a selective PMSI, the set of BFERs (egress PEs) includes the originators of corresponding SMET routes. </t> <t>The SMET routes do not carry a PTA. When an ingress PE sends traffic on a selective tunnel using BIER, it uses the upstream-assigned label that is advertised in its IMET route. </t><t>Only when selectively<t>When only selective forwarding is used for all flows and without tunnel segmentation, SMET routes are used without the need for S-PMSI A-D routes. Otherwise, the procedures in the following section apply. </t> </section> <sectiontitle="Usingnumbered="true" toc="default"> <name>Using S-PMSI/Leaf A-DRoutes">Routes</name> <t>There are two cases where S-PMSI/Leaf A-D routes are used as discussed in the following two sections. </t> <sectiontitle="Selectivenumbered="true" toc="default"> <name>Selective Forwarding Only for SomeFlows">Flows</name> <t>With the SMET procedure, a PE advertisesana SMET route for each (C-S, C-G) or (C-*, C-G) state that it learns on its Attachment Circuits (ACs), and each SMET route is tracked by every PE in the same broadcast domain. It may be desired that SMET routes are notused,used in order to reduce the burden of explicit tracking. </t> <t>In this case, most multicast traffic will follow the I-PMSI (advertised via the IMET route) and only some flows will follow S-PMSIs. To achieve that, S-PMSI/Leaf A-D routes can be used, as specified in <xreftarget='I-D.ietf-bess-evpn-bum-procedure-updates'/>.target="RFC9572" format="default"/>. </t> <t>The rules specified inSection 2.2.1Sections <xref target="RFC8556" section="2.2.1" sectionFormat="bare" format="default"/> andSection 2.2.2<xref target="RFC8556" section="2.2.2" sectionFormat="bare" format="default"/> of <xreftarget='RFC8556'/>target="RFC8556"/> apply. </t> </section> <sectiontitle="Tunnel Segmentation">numbered="true" toc="default"> <name>Tunnel Segmentation</name> <t>Another case where S-PMSI/Leaf A-D routes are necessary is tunnel segmentation, which is also specified in <xreftarget='I-D.ietf-bess-evpn-bum-procedure-updates'/>,target="RFC9572" format="default"/> and further clarified in <xreftarget='I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements'/>target="I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements" format="default"/> for segmentation with SMET routes. This is only applicable to EVPN-MPLS. </t> <t>The rules specified inSection 2.2.1 of<xreftarget='RFC8556'/>target="RFC8556" section="2.2.1" sectionFormat="of" format="default"/> apply.Section 2.2.2 of<xreftarget='RFC8556'/>target="RFC8556" section="2.2.2" sectionFormat="of" format="default"/> does not apply, because like in MVPN, the LIR-pF flag cannot be used with segmentation. </t> </section> <sectiontitle="Applicabilitynumbered="true" toc="default"> <name>Applicability of Additional MVPNSpecifications">Specifications</name> <t>As with the MVPN case,Section "3. Use"Use of the PMSI Tunnel Attribute in Leaf A-Droutes" of <xref target='RFC8556'/> apply.Routes" (<xref target="RFC8556" format="default" sectionFormat="of" section="3"/>) applies. </t> <t>Noticethat,that <xreftarget='RFC8556'/>target="RFC8556" format="default"/> refers to procedures specified in <xreftarget='RFC6625'/>target="RFC6625" format="default"/> and <xreftarget="RFC8534"/>.target="RFC8534" format="default"/>. Those two documents were specified for MVPN but apply to IP multicast payload in EVPN as well. </t> </section> </section> </section> <sectiontitle="MPLSanchor="label" numbered="true" toc="default"> <name>MPLS Label inPTA" anchor="label">the PTA</name> <t>Rules insection 2.1 of<xreftarget='RFC8556'/>target="RFC8556" section="2.1" sectionFormat="of" format="default"/> apply, EXCEPT the following three bullets (they do NOT apply to EVPN) in that section:<list style="symbols"></t> <ul spacing="normal"> <li> <t> If the two routes do not have the same Address Family Identifier (AFI) value, then their respective PTAsMUST<bcp14>MUST</bcp14> contain different MPLS label values. This ensures that when an egress PE receives a data packet with the given label, the egress PE can infer from the label whether the payload is an IPv4 packet or an IPv6 packet. </t> </li> <li> <t> If the BFIR is an ingress PE supporting MVPN extranet(<xref target="RFC7900"/>)<xref target="RFC7900" format="default"/> functionality, and if the two routes originate from different VRFs on this ingress PE, then the respective PTAs of the two routesMUST<bcp14>MUST</bcp14> contain different MPLS label values. </t> </li> <li> <t> If the BFIR is an ingress PE supporting the "Extranet Separation" feature of MVPN extranet (seeSection 7.3 of<xreftarget="RFC7900"/>),target="RFC7900" section="7.3" sectionFormat="of" format="default"/>), and if one of the routes carries the "Extranet Separation" extended community but the other does not, then the respective PTAs of the two routesMUST<bcp14>MUST</bcp14> contain different MPLS label values. </t></list> </t></li> </ul> </section> </section> <sectiontitle="Multihominganchor="multihoming" numbered="true" toc="default"> <name>Multihoming SplitHorizon" anchor="multihoming">Horizon</name> <t>For EVPN-MPLS, <xreftarget="RFC7432"/>target="RFC7432" format="default"/> specifies the use of ESI labels to identify the ES from which a BUM packet originates. A PE receiving that packet from the core side will not forward it to the same ES. The procedure works for both Ingress Replication (IR) and RSVP-TE/mLDP P2MP tunnels, using downstream- and upstream-assigned ESIlabelslabels, respectively. <!--[rfced] To clarify this sentence, may we update it as follows or is there another way it should be updated? Original: For EVPN-VXLAN/NVGRE/GENEVE,<xref target='RFC8365'/>[RFC8365] specifies local bias procedures, with which a PE receiving a BUM packet from the core side knows from encapsulation the ingress PE so it does not forward the packet to any multihoming ESes that the ingress PE is on. Perhaps: For EVPN-VXLAN/NVGRE/GENEVE, [RFC8365] specifies local bias procedures, where a PE receiving a BUM packet from the core side knows the ingress PE due to encapsulation; therefore, the PE does not forward the packet to any multihoming ESes that the ingress PE is on. --> For EVPN-VXLAN/NVGRE/GENEVE, <xref target="RFC8365" format="default"/> specifies local bias procedures with which a PE receiving a BUM packet from the core side knows from encapsulation the ingress PE so it does not forward the packet to any multihoming ESes that the ingress PE is on. This is because the ingress PE already forwarded the packet to thoseESesESes, regardless of whether the ingress PE is a Designated Forwarder for those ESes. </t> <t>With BIER, the local bias procedure still applies forEVPN-VXLAN/NVGRE/GENEVEEVPN-VXLAN/NVGRE/GENEVE, as the BFIR-id in the BIER header identifies the ingress PE. For EVPN-MPLS, ESI label procedures also stillapplyapply, though two upstream-assigned labels will be used (one for identifying the broadcast domain and one for identifying the ES)--- the same as in the case of using a single P2MP tunnel for multiple broadcast domains. The BFIR-id in the BIER header identifies the ingress PE that assigned those two labels. </t> </section> <!--section title = "Assisted Replication with BIER Composite Tunnel" anchor="ar"> <t>With Assisted Replication (AR) <xref target="I-D.ietf-bess-evpn-optimized-ir"/> (with IP tunnels) an AR-leaf sends traffic to an AR-replicator via Ingress Replication (IR), who will then relay the traffic to other AR-leaf and AR-replicators. While the AR-replicator receives via IR the relay could be via BIER. An AR-leaf may not support BIER in the forwarding path but it could still advertise the support of BIER and rely on its upstream router to do Penultimate Hop Popping as described in <xref target="I-D.ietf-bier-php"/>. To support that scenario, the procedures in <xref target="I-D.ietf-bess-evpn-optimized-ir"/> are followed with the following modifications: <list style="symbols"> <t>AR-replicators must support BIER in forwarding. It advertises a BIER tunnel in its IMET route with IR-IP as the Originating Router's IP Address, and advertises an AR tunnel in its IMET route with AR-IP as the Originating Router's IP Address. </t> <t>AR-leaves that can request BIER PHP advertise IMET route with a BIER composite tunnel. </t> <t>Traffic received by an AR-replicator with BIER encapsulation is not relayed. </t> <t>When there are Regular NVEs (RNVEs that only support the plain old procedures in <xref target="RFC7432"/>), the AR-replicator will relay traffic from RNVEs to AR-leaves that advertises BIER composite tunnel via BIER, and relay traffic from AR-leaves to RNVEs via IR. [question - do we need to elect an AR-replicator to relay traffic from RNVEs?] </t> </list> </t> <t>AR with MPLS tunnels, along with the usage of BIER composite tunnel, are specified in <xref target="I-D.keyupate-bess-evpn-virtual-hub"/>. </t> </section--> <sectiontitle="Data Plane">numbered="true" toc="default"> <name>Data Plane</name> <t>Like MVPN, the EVPN application plays the role of the "multicast flow overlay" as described in <xreftarget='RFC8279'/>.target="RFC8279" format="default"/>. </t> <sectiontitle="Encapsulationnumbered="true" toc="default"> <name>Encapsulation andTransmission">Transmission</name> <t>A BFIR could be either an ingress PE or a P-tunnel segmentation point. The procedures are slightly different as described below. </t> <sectiontitle="Atanchor="ingresspe" numbered="true" toc="default"> <name>At a BFIRthat isThat Is an IngressPE" anchor="ingresspe">PE</name> <t>To transmit a BUM data packet, an ingress PE first determines the route matched for transmission and routes for tracking leaves according to the following rules.<list style="numbers"> <t anchor="inclusive">If</t> <ol spacing="normal" type="1"><li anchor="inclusive"> <t>If selective forwarding is notused,used oritis not an IP Multicast packet after the Ethernet header, the IMET route originated for the BD by the ingress PE is the route matched for transmission.Leaf trackingLeaf-tracking routes are all other received IMET routes for the BD. </t> </li> <li> <t>Otherwise, if selective forwarding is used for all IP Multicast traffic based on SMET routes, the IMET route originated for the BD by the ingress PE is the route matched for transmission. Received SMET routes for theBDBD, whose source and destination address fields match the packet's source and destination IPaddressaddress, areleaf trackingleaf-tracking routes. </t> </li> <li> <t>Otherwise, the route matched for transmission is the S-PMSI A-D route originated by the ingress PE for the BD, whose source and destination address fields match the packet's source and destination IP address and have a PTA specifying a valid tunnel type that is not "no tunnel info". Leaf-tracking routes are determined as follows: </t> <!--[rfced] Section 4.1.1. We updated the numerals to letters within the nested list for clarity as shown below. Please let us know of any objections. Original: 3. Otherwise, the route matched for transmission is the S-PMSI A-D route originated by the ingress PE for the BD, whose source and destination address fields match the packet's source and destination IP address and has a PTA specifying a valid tunnel type that is not "no tunnel info". Leaf tracking routes are determined as follows:<list style="format %d)"> <t>If1) If the match for transmission route carries a PTA that has the LIR flag set but does not have the LIR-pF flag set, the routes matched for tracking are Leaf A-D routes whose "route key" field is identical to the NLRI of the S-PMSI A-D route.</t> <t>If2) If the match for transmission route carries a PTA that has the LIR-pF flag, the leaf tracking routes are Leaf A-D routes whose "route key" field is derived from the NLRI of the S-PMSI A-D route according to the procedures described in Section 5.2 of [RFC8534]. Current: 3. Otherwise, the route matched for transmission is the S-PMSI A-D route originated by the ingress PE for the BD, whose source and destination address fields match the packet's source and destination IP address and have a PTA specifying a valid tunnel type that is not "no tunnel info". Leaf-tracking routes are determined as follows: a. If the match for the transmission route carries a PTA that has the LIR flag set but does not have the LIR-pF flag set, the routes matched for tracking are Leaf A-D routes whose Route Key field is identical to the NLRI of the S-PMSI A-D route. b. If the match for the transmission route carries a PTA that has the LIR-pF flag, the leaf-tracking routes are Leaf A-D routes whose Route Key field is derived from the NLRI of the S-PMSI A-D route according to the procedures described in Section 5.2 of [RFC8534]. --> <!-- <ol spacing="normal" type="%d)"><li>--> <ol spacing="normal" type="a"><li> <t>If the match for the transmission route carries a PTA that has the LIR flag set but does not have the LIR-pF flag set, the routes matched for tracking are Leaf A-D routes whose Route Key field is identical to the NLRI of the S-PMSI A-D route. </t> </li> <li> <t>If the match for the transmission route carries a PTA that has the LIR-pF flag, the leaf-tracking routes are Leaf A-D routes whose Route Key field is derived from the NLRI of the S-PMSI A-D route according to the procedures described in <xreftarget="RFC8534"/>.target="RFC8534" section="5.2" sectionFormat="of" format="default"/>. </t></list> <vspace/> <vspace/></li> </ol> <t> Note that in both cases, SMET routes may be used in lieu of Leaf A-D routes, as a PE may omit the Leaf A-D route in response to an S-PMSI A-D route with the LIR or LIR-pF bitset,set ifana SMET route with the corresponding Tag, Source, and Group fields is already originated <xreftarget='I-D.ietf-bess-evpn-bum-procedure-updates'/>.target="RFC9572" format="default"/>. In particular, in the second case above, even though the SMET route does not have a PTA attached, it is still considered a Leaf A-D route in response to a wildcard S-PMSI A-D route with the LIR-pF bit set. </t> </li> <li> <t>Otherwise, the route matched for transmission andleaf trackingleaf-tracking routes are determined as in rule <xref target="inclusive" format="counter"/>. </t></list> </t></li> </ol> <t>If no route is matched for transmission, the packet is not forwarded onto a P-tunnel. If the tunnel that the ingress determines to use based on the route matched for transmission (and considering interworking with PEs that do not support certain tunnel types per procedures in <xreftarget="RFC9251"/>)target="RFC9251" format="default"/>) requires leaf tracking(e.g.(e.g., Ingress Replication, RSVP-TE P2MP tunnel, or BIER) but there are noleaf trackingleaf-tracking routes, the packet will not be forwarded onto a P-tunnel either. </t> <t>The following text assumes that BIER is the determined tunnel type. The ingress PE pushes an upstream-assigned ESI label per <xreftarget="RFC7432"/>target="RFC7432" format="default"/> if the following conditions are all met:<list style="symbols"></t> <ul spacing="normal"> <li> <t>The packet is received on a multihomed ES. </t><t>It's</li> <li> <t>It is EVPN-MPLS. </t><t>ESI</li> <li> <t>The ESI label procedure is used forsplit-horizon. </t> </list>split horizon. </t> </li> </ul> <t>The MPLS label from the PTA of the route matched for transmission is then pushed onto the packet's label stack for EVPN-MPLS. For EVPN-VXLAN/NVGRE/GENEVE, a VXLAN/NVGRE/GENEVE header is prepended to the packet with the VNI/VSID set to the value in the PTA'slabelLabel field, and then an IP/UDP header is prepended if needed(e.g.(e.g., for PHPpurpose).purposes). </t><t>Then<t>Then, the packet is encapsulated in a BIER header andforwarded,forwarded according to the procedures of <xreftarget='RFC8279'/>target="RFC8279" format="default"/> and <xreftarget='RFC8296'/>. See especially Section 4,target="RFC8296" format="default"/>. Specifically, see "Imposing and Processing the BIEREncapsulation", of <xref target='RFC8296'/>.Encapsulation" (<xref target="RFC8296" format="default" sectionFormat="of" section="3"/>). The"Proto"Proto field in the BIER header is set to 2 in the case of EVPN-MPLS,ora value to be assigned in the case of EVPN-VXLAN/NVGRE/GENEVE (<xreftarget="IANA"/>)target="IANA" format="default"/>) when an IP header is not used, or 4/6 if an IP header is used for EVPN-VXLAN/NVGRE/GENEVE. </t> <t>To create the proper BIER header for a given packet, the BFIR must know all the BFERs that need to receive that packet. This is determined from the set ofleaf trackingleaf-tracking routes. </t> </section> <sectiontitle="Atnumbered="true" toc="default"> <name>At a BFIRthat isThat Is aP-tunnelP-Tunnel SegmentationPoint">Point</name> <t>In this case, the encapsulation for the upstream segment of the P-tunnel includes (among other things) a label that identifies the x-PMSI or IMET A-D route that is the match for reception on the upstream segment. The segmentation point re-advertised the route into one or more downstream regions. Each instance of the re-advertised route for a downstream region has a PTA that specifies the tunnel for that region. For any particular downstream region, the route matched for transmission is the re-advertisedrouteroute, and theleaf trackingleaf-tracking routes are determined asfollowsfollows, ifneededneeded, for the tunnel type:<list style="symbols"></t> <ul spacing="normal"> <li> <t>If the route matched for transmission is an x-PMSI route, it must have the LIR flag set in itsPTAPTA, and theleaf trackingleaf-tracking routes are all the matching Leaf A-D and SMET routes received in the downstream region. </t> </li> <li> <t>If the route matched for transmission is an IMET route, theleaf trackingleaf-tracking routes are all the IMET routes for the same BD received in the downstream region. </t></list> </t></li> </ul> <t>If the downstream region uses BIER, the packet is forwarded as follows: the upstream segmentation's encapsulation is removed and the above-mentioned label is swapped to the upstream-assigned label in the PTA of the route matched for transmission, and then a BIER header is imposed as in <xreftarget="ingresspe"/>.target="ingresspe" format="default"/>. </t> </section> </section> <sectiontitle="Disposition">numbered="true" toc="default"> <name>Disposition</name> <t>The same procedures insection 4.2 of<xreftarget='RFC8556'/>target="RFC8556" section="4.2" sectionFormat="of" format="default"/> are followed for EVPN-MPLS, except for some EVPN specifics that are discussed in the following twosub-sections insubsections of this document. </t> <t>For EVPN-VXLAN/NVGRE/GENEVE, the onlydifference isdifferences are that the payload is VXLAN/NVGRE/GENEVE (with or without an IP header) and the VNI/VSID field in the VXLAN/NVGRE/GENEVE header is used to determine the corresponding broadcast domain. </t> <sectiontitle="Atnumbered="true" toc="default"> <name>At a BFERthat isThat Is an EgressPE">PE</name> <t>Once the corresponding broadcast domain is determined from the upstream-assigned label or VNI/VSID, EVPN forwarding procedures per <xreftarget="RFC7432"/>target="RFC7432" format="default"/> or <xreftarget='RFC8365'/>target="RFC8365" format="default"/> are followed. In the case of EVPN-MPLS, if there is an inner label in the label stack following the BIER header, that inner label is considered the upstream-assigned ESI label forsplit horizon purpose.split-horizon purposes. </t> </section> <sectiontitle="Atnumbered="true" toc="default"> <name>At a BFERthat isThat Is aP-tunnelP-Tunnel SegmentationPoint">Point</name> <t>This is only applicable to EVPN-MPLS. The same procedures inSection 4.2.2 of<xreftarget='RFC8556'/>target="RFC8556" section="4.2.2" sectionFormat="of" format="default"/> are followed, subject to multihoming procedures specified in <xreftarget='I-D.ietf-bess-evpn-bum-procedure-updates'/>.target="RFC9572" format="default"/>. </t> </section> </section> </section> <section anchor="IANA"title="IANA Considerations"> <t>This document requestsnumbered="true" toc="default"> <name>IANA Considerations</name> <t>Per this document, IANA has registered the following threeassignmentsvalues in the "BIER Next Protocol Identifiers"registry, with the following three recommended values: <list style="symbols"> <t>7: Payloadregistry: </t> <table align="center"> <name>BIER Next Protocol Identifiers Registry</name> <thead> <tr> <th>Value</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>7</td> <td>Payload is VXLAN encapsulated (no IP/UDPheader) </t> <t>8: Payloadheader)</td> <td>RFC 9624</td> </tr> <tr> <td>8</td> <td>Payload is NVGRE encapsulated (no IPheader) </t> <t>9: Payloadheader)</td> <td>RFC 9624</td> </tr> <tr> <td>9</td> <td>Payload is GENEVE encapsulated (no IP/UDPheader) </t> </list> </t> <t>This document requests assignments ofheader)</td> <td>RFC 9624</td> </tr> </tbody> </table> <t>IANA has also assigned an IPv4 and an IPv6 multicast address for the case discussed in <xreftarget="php-address"/>. Preferably this is assigned fromtarget="php-address" format="default"/>.</t> <t> The following entry has been added to theLocal"Local Network Control Block(224.0.0/24) for IPv4 and Link-Local(224.0.0.0 - 224.0.0.255 (224.0.0/24))" registry for IPv4:</t> <dl spacing="compact"> <dt>Address(es):</dt><dd> 224.0.0.122</dd> <dt>Description:</dt><dd> Network Virtualization Overlay (NVO) BUM Traffic</dd> <dt>Reference:</dt><dd> RFC 9624</dd> </dl> <t> The following entry has been added to the "Link-Local Scope MulticastAddressesAddresses" registry forIPv6. The description is "NVOIPv6:</t> <dl spacing="compact"> <dt>Address(es):</dt><dd>FF02:0:0:0:0:0:0:14</dd> <dt>Description:</dt><dd> Network Virtualization Overlay (NVO) BUMTraffic". </t>Traffic</dd> <dt>Reference:</dt><dd> RFC 9624</dd> </dl> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>This document is about using BIER as provider tunnels for EVPN. It is very similar to using BIER as MVPN providertunnel,tunnels and does not introduce additional security implications beyond what have been discussed in the EVPN base protocol specification <xreftarget="RFC7432"/>target="RFC7432" format="default"/> and MVPN using BIER <xreftarget="RFC8556"/>.target="RFC8556" format="default"/>. </t> </section> </middle> <back> <displayreference target="I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements" to="CMCAST-ENHANCEMENTS"/> <displayreference target="I-D.ietf-bier-php" to="BIER-PHP"/> <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.7900.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6625.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.8279.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8296.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8556.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.9251.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8365.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8926.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"/> <!-- [I-D.ietf-bess-evpn-bum-procedure-updates is now RFC 9572--> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9572.xml"/> </references> <references> <name>Informative References</name> <!-- [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] IESG State - I-D Exists as of 7/24/24. Long way used to fix initials--> <reference anchor="I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements" target="https://datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-04"> <front> <title>MVPN/EVPN C-Multicast Routes Enhancements</title> <author initials="Z." surname="Zhang" fullname="Zhaohui (Jeffrey) Zhang"> <organization>Juniper Networks</organization> </author> <author initials="R." surname="Kebler" fullname="Robert Kebler"> <organization>Juniper Networks</organization> </author> <author initials="W." surname="Lin" fullname="Wen Lin"> <organization>Juniper Networks</organization> </author> <author initials="E." surname="Rosen" fullname="Eric C. Rosen"> </author> <date month="March" day="17" year="2024"/> </front> <seriesInfo name="Internet-Draft" value="draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-04"/> </reference> <!-- [I-D.ietf-bier-php] IESG State - Publication Requested as of 07/24/24. Long way used to fix initials --> <reference anchor="I-D.ietf-bier-php" target="https://datatracker.ietf.org/doc/html/draft-ietf-bier-php-11"> <front> <title>BIER Penultimate Hop Popping</title> <author initials="Z." surname="Zhang" fullname="Zhaohui (Jeffrey) Zhang"> <organization>Juniper Networks</organization> </author> <date month="February" day="6" year="2024"/> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-bier-php-11"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7637.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.6388.xml"/> </references> </references> <section anchor="Acknowledgements"title="Acknowledgements">numbered="false" toc="default"> <name>Acknowledgements</name> <t>The authors thankEric Rosen<contact fullname="Eric Rosen"/> for his review and suggestions. Additionally, much of the text is borrowed verbatim from <xreftarget='RFC8556'/>.target="RFC8556" format="default"/>. </t> </section></middle> <back> <references title="Normative References"> <?rfc include='reference.RFC.2119.xml'?> <?rfc include='reference.RFC.8174.xml'?> <?rfc include='reference.RFC.7900.xml'?> <?rfc include='reference.RFC.6625.xml'?> <?rfc include='reference.RFC.7432.xml'?> <?rfc include='reference.RFC.8279.xml'?> <?rfc include='reference.RFC.8296.xml'?> <?rfc include='reference.RFC.8556.xml'?> <?rfc include='reference.RFC.8534.xml'?> <?rfc include='reference.RFC.9251.xml'?> <?rfc include='reference.RFC.8365.xml'?> <?rfc include='reference.RFC.8926.xml'?> <?rfc include='reference.RFC.6513.xml'?> <?rfc include='reference.RFC.6514.xml'?> <?rfc include='reference.I-D.ietf-bess-evpn-bum-procedure-updates.xml'?> </references> <references title="Informative References"> <?rfc include='reference.I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements.xml'?> <?rfc include='reference.I-D.ietf-bier-php.xml'?> <?rfc include='reference.RFC.7348.xml'?> <?rfc include='reference.RFC.7637.xml'?> <?rfc include='reference.RFC.4875.xml'?> <?rfc include='reference.RFC.6388.xml'?> </references><!--[rfced] We notice some hidden text in the XML file. Note that it will be deleted upon publication unless we hear otherwise from the authors. --> <!--[rfced] Throughout the text, "IP Multicast" and "IP multicast" appear to be used inconsistently. Please review these occurrences and let us know if/how they may be made consistent. --> <!--[rfced] Acronyms a) FYI - We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Provider Edge (PE) VPN Routing and Forwarding (VRF) b) Does the "x" in "x-PMSI" have an expansion? c) Should "LIR" be expanded as "Leaf Info Required" instead of "Leaf Info Required Bit (LIR)" to parallel "Leaf Info Required per Flow (LIR-pF)"? d) Can the description/expansion for "mLDP-P2MP" be updated to more closely match the acronym as shown below (option A)? Or if you want to retain the wording, should "MP2MP" be added to represent "Multipoint-to-Multipoint" (option B)? Original: mLDP-P2MP [RFC6388]: Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths. Perhaps: A) mLDP-P2MP: Multipoint Label Distribution Protocol extensions for Point-to-Multipoint LSPs [RFC6388]. or B) mLDP-P2MP-MP2MP: Multipoint Label Distribution Protocol extensions for Point-to-Multipoint and Multipoint-to-Multipoint LSPs [RFC6388]. e) To match the other documents in this cluster, may we update the expansion of "BUM" to use "or" instead of "and"? Original: broadcast, unknown unicast and multicast (BUM) Perhaps: Broadcast, Unknown Unicast, or Multicast (BUM) f) In RFC 9574, "VSID" is expanded as "Virtual Segment Identifier"; this document expands it as "Virtual Subnet IDentifier". Should this document be updated to match RFC 9574? g) Section 5. In the descriptions under the "Local Network Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24))" and "Link-Local Scope Multicast Addresses" registries, we expanded "NVO" as "Network Virtualization Overlay" as shown below. If there are no objections, we will ask IANA to update their registries accordingly. Current: Address(es): 224.0.0.122 Description: Network Virtualization Overlay (NVO) BUM Traffic Reference: RFC 9624 Address(es): FF02:0:0:0:0:0:0:14 Description: Network Virtualization Overlay (NVO) BUM Traffic Reference: RFC 9624 h) May we update all instances of "broadcast domain" to "BD" after this acronym has been expanded at its first occurrence? --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <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. --> </back> </rfc>